As Windows users eagerly installed the latest May 2025 Patch Tuesday updates, many found themselves caught in a frustrating cycle: devices unexpectedly booting into BitLocker recovery, or worse, endlessly rebooting in a relentless loop. The culprit, as Microsoft has since acknowledged, isn’t just a problematic update—it's an intricate clash between the Windows operating system, BitLocker disk encryption, and a hardware security feature present in millions of Intel-powered computers. The drama surrounding the KB5058379 update provides a cautionary tale about the complexity of modern PC security, the unintended consequences of rapid patch deployment, and the ongoing challenge of keeping millions—if not billions—of devices both secure and operational.
It started as most Windows Patch Tuesday incidents do: with initial reports on community forums and tech news sites that a new cumulative update—in this case, KB5058379 for Windows 10 22H2—was sending affected PCs into BitLocker recovery at boot, or even trapping them in a continuous automatic repair cycle. By mid-May, Windows forums and Twitter were awash with users documenting their plight: after the patch installed, their systems would either halt for BitLocker recovery keys or fail to proceed past perpetual restart attempts .
Initial speculation centered on the update itself, but Microsoft's preliminary investigation revealed a subtler cause. The common thread among most impacted users? Systems running on Intel hardware with Trusted Execution Technology (TXT) enabled in the BIOS.
By leveraging Intel TXT, security-conscious organizations—governments, large enterprises, and privacy-focused individuals—can lock down critical software environments, thwarting sophisticated threats that might otherwise compromise security during system initialization or OS boot. TXT is especially useful in virtualized environments and where strong compliance requirements exist.
The technical result is two-fold:
BitLocker’s operation relies heavily on trusted hardware elements—including the TPM and, when available, Intel TXT. It authenticates the precise system state at boot, ensuring that nothing has been altered or compromised before unlocking the encryption keys that allow the system to proceed.
When LSASS unexpectedly terminates because of a faulty interaction between Windows code and Intel TXT, BitLocker “panics” as a precaution, assuming the system’s state may have been tampered with. It then demands manual input of the recovery key—or simply fails to proceed—triggering the endless reboot or repair cycle observed.
For users who don’t routinely back up their BitLocker recovery keys, or who are unaware they even exist (since Windows may enable BitLocker by default on some systems), the experience is particularly alarming.
The suggested workaround, until a permanent fix can be released, is straightforward:
Microsoft has also committed to issuing an out-of-band update—similar to what was previously deployed for analogous issues on Windows 11 24H2. This forthcoming patch is promised on an “urgent” timeline, according to the company’s Health Dashboard posting.
This incident isn’t the first time that OS updates have exposed just how brittle these dependencies can be:
As the peril of this update revealed, a user suddenly prompted for a BitLocker recovery key they never knew existed faces real risk of data loss, lost productivity, or even the loss of irreplaceable personal files.
Potential risks and challenges include:
Several industry experts have recommended:
Automated compatibility checks within Windows Update, more accessible technical documentation, and empowering end-users with clear information about the state of their device security are all expected to play a greater role in the years ahead.
For now, the KB5058379 saga remains a potent reminder: In the quest for digital security, complexity can be both a shield and a sword. When the balance tips, even a routine software update can ignite a crisis. By learning from these episodes, all parties involved can hope the ride becomes a little less bumpy with every cycle—and that, next time, recovery is swifter, easier, and less traumatic for everyone caught in the loop.
Source: Neowin Microsoft blames Intel as KB5058379 takes Windows PCs on a BitLocker recovery reboot ride
An Unexpected Reboot Frenzy: What Happened with KB5058379?
It started as most Windows Patch Tuesday incidents do: with initial reports on community forums and tech news sites that a new cumulative update—in this case, KB5058379 for Windows 10 22H2—was sending affected PCs into BitLocker recovery at boot, or even trapping them in a continuous automatic repair cycle. By mid-May, Windows forums and Twitter were awash with users documenting their plight: after the patch installed, their systems would either halt for BitLocker recovery keys or fail to proceed past perpetual restart attempts .Initial speculation centered on the update itself, but Microsoft's preliminary investigation revealed a subtler cause. The common thread among most impacted users? Systems running on Intel hardware with Trusted Execution Technology (TXT) enabled in the BIOS.
Understanding the Technology: What Is Intel TXT?
Intel Trusted Execution Technology, or TXT, is an advanced security feature embedded in many Intel processors and chipsets. TXT is designed to establish a “root of trust” during system startup, creating a secure environment where sensitive operations and cryptographic tasks can occur without fear of tampering. The technology works hand-in-hand with the system’s TPM (Trusted Platform Module), sometimes referred to as Intel PTT when implemented in firmware, alongside Secure Boot.By leveraging Intel TXT, security-conscious organizations—governments, large enterprises, and privacy-focused individuals—can lock down critical software environments, thwarting sophisticated threats that might otherwise compromise security during system initialization or OS boot. TXT is especially useful in virtualized environments and where strong compliance requirements exist.
Where the Wheels Fell Off: TXT, LSASS, and BitLocker
Microsoft’s full post-mortem clarified the chain reaction behind the chaos. The updated Windows codebase in KB5058379 apparently includes changes that, when interacting with Intel TXT, destabilize core Windows security processes. Specifically, the Local Security Authority Subsystem Service (LSASS)—which manages user authentication and enforces local security policies—fails unexpectedly when TXT is enabled.The technical result is two-fold:
- If the system handles the error gracefully, Startup Repair may automatically roll back the faulty update, returning the PC to a prior, functional state after a few failed boot attempts.
- In less fortunate cases, the device enters a boot loop; each restart triggers BitLocker recovery or automatic repair, leaving users either stranded or at risk of data loss.
- Event ID 20: "Installation Failure: Windows failed to install the following update with error 0x800F0845: 2025-05 Cumulative Update for Windows 10 22H2 for x64-based Systems (KB5058379)."
- Event ID 1074: "The system process 'C:\WINDOWS\system32\’ terminated unexpectedly with status code -1073740791."
BitLocker Caught in the Crossfire
BitLocker, Microsoft’s built-in full disk encryption technology, has long been heralded as an essential line of defense for enterprise and personal PCs alike. It protects data from theft or exposure when a device is lost or stolen, turning sensitive files into unreadable gibberish without the correct recovery key or authentication.BitLocker’s operation relies heavily on trusted hardware elements—including the TPM and, when available, Intel TXT. It authenticates the precise system state at boot, ensuring that nothing has been altered or compromised before unlocking the encryption keys that allow the system to proceed.
When LSASS unexpectedly terminates because of a faulty interaction between Windows code and Intel TXT, BitLocker “panics” as a precaution, assuming the system’s state may have been tampered with. It then demands manual input of the recovery key—or simply fails to proceed—triggering the endless reboot or repair cycle observed.
For users who don’t routinely back up their BitLocker recovery keys, or who are unaware they even exist (since Windows may enable BitLocker by default on some systems), the experience is particularly alarming.
Microsoft Responds: Diagnosis and Workarounds
As frustration mounted, Microsoft moved quickly to diagnose and communicate the issue both internally and to customers. Their Windows Health Dashboard and official support channels have been continuously updated as the company’s engineering teams traced the problem back to the conflict between Intel TXT and the KB5058379 update .The suggested workaround, until a permanent fix can be released, is straightforward:
- Enter the BIOS/UEFI Setup on the affected PC at startup.
- Disable Intel Trusted Execution Technology (TXT).
- Save changes and reboot.
Microsoft has also committed to issuing an out-of-band update—similar to what was previously deployed for analogous issues on Windows 11 24H2. This forthcoming patch is promised on an “urgent” timeline, according to the company’s Health Dashboard posting.
The Broader Security Implications
The unexpected interaction between an OS update, BitLocker, and hardware security features like Intel TXT underscores how deeply intertwined security has become at every layer of modern computing. Each element—firmware, operating system, hardware, and applications—assumes the reliability and compatibility of the others. When any component changes, especially in the security domain, even minor incompatibilities can have dramatic, widespread impact.This incident isn’t the first time that OS updates have exposed just how brittle these dependencies can be:
- In past years, firmware and driver bugs following Windows updates have occasionally rendered biometric authentication inoperable, disabled network access, or caused system crashes.
- In 2023, a flawed update briefly caused BitLocker to misidentify device states, triggering unnecessary recovery scenarios even without hardware changes .
- Similar conflicts between Secure Boot implementations and third-party security software have repeatedly tripped systems into recovery or unusable states.
Are Default Encryption Settings to Blame?
Some analysts have pointed out that Windows’ practice in recent releases of enabling BitLocker by default—even for users who may not be aware they're relying on disk encryption—exacerbates such incidents. While the security benefits of always-on encryption are undeniable, the lack of user awareness (and, critically, poor backup habits for recovery keys) creates a recipe for distress if something goes wrong.As the peril of this update revealed, a user suddenly prompted for a BitLocker recovery key they never knew existed faces real risk of data loss, lost productivity, or even the loss of irreplaceable personal files.
Strengths Exposed: Microsoft’s Rapid Response and Transparency
Despite the frustration caused, Microsoft’s handling of the KB5058379 debacle has drawn some positive notes within the IT community. The company has:- Rapidly updated its Windows Health Dashboard and support documents to acknowledge the issue and provide clear workarounds.
- Committed to delivering a targeted, out-of-band fix rather than waiting for the next scheduled update—a crucial move for affected businesses and critical infrastructure.
- Provided detailed technical communication, including event log details and explicit instructions for IT professionals.
Risks and Ongoing Challenges
The broader risk laid bare by the KB5058379 episode is that as Windows security gets more robust—stacked with layers like Secure Boot, BitLocker, TPM, VBS, and hardware roots of trust—the attack surface for bugs and incompatibilities likewise multiplies.Potential risks and challenges include:
- Increased Support Overhead: Every new layer of security potentially increases support calls, particularly when changes are made at a rapid clip during Patch Tuesdays.
- Data Loss: As systems default to hardware-tied encryption, a single misstep can leave users locked out of their files—with recoveries dependent on keys that are easily forgotten or misplaced.
- Complex Rollbacks: Reversing firmware or security configuration changes to recover from update-induced failures can itself introduce new vulnerabilities—if, for example, users forget to re-enable TXT or other settings after a fix is applied.
- Enterprise Downtime: In large organizations, a blocking issue in a core security process like LSASS, tied to something as foundational as BitLocker, can take thousands of machines offline until a coordinated response is mounted.
Community and Industry Response
The level of community engagement—and, at times, confusion—seen in the wake of the update demonstrates both the reach of Windows platform changes and the ongoing role of user advocacy. Security professionals, system administrators, and privacy advocates have weighed in with both praise for Microsoft’s disclosure and calls for even more transparent testing around security feature interactions before deploying future patches.Several industry experts have recommended:
- Clearer Communication on Defaults: Ensuring users are notified when features like BitLocker are activated automatically, and are guided through saving their recovery keys in multiple secure locations.
- Automated Pre-Update Scans: Utilizing Windows Update or Endpoint Manager to automatically flag or warn on potential incompatibilities with known risky configurations (such as TXT-enabled, BitLocker-protected devices) before update application.
- Closer Vendor Collaboration: Microsoft and Intel working in lockstep to validate firmware, chipset, and OS interactions ahead of major update releases.
Lessons for Users and IT Departments
The KB5058379 incident, while deeply disruptive for a subset of users, offers several actionable takeaways:- Always Back Up Recovery Keys: Whether you’re a home user or an enterprise, always back up your BitLocker recovery key—and don’t trust a single storage location. OneDrive, paper copies, secured company directories, or a password manager vault are all better than relying on memory.
- Review BIOS Security Features: Familiarize yourself with hardware security options like Intel TXT, TPM, and Secure Boot. Know how to access and modify them, or at minimum, keep your PC’s manual or online support resources handy.
- Monitor Trusted Sources: Subscribe to Microsoft’s Windows Health Dashboard or equivalent channels for real-time alerts about emerging update issues and workarounds.
- Test Before Full Deployment: Enterprises should always preview updates on a selection of systems, especially those with nonstandard or advanced security settings, before rolling out broadly.
Looking Forward: Can Future Disasters Be Prevented?
Both Microsoft and Intel have pledged to work closely to head off similar issues in the future. The push for coordinated vulnerability disclosures and patch validation involving all stakeholders—OS vendors, hardware OEMs, enterprise customers, and the info-sec research community—continues to gain steam.Automated compatibility checks within Windows Update, more accessible technical documentation, and empowering end-users with clear information about the state of their device security are all expected to play a greater role in the years ahead.
For now, the KB5058379 saga remains a potent reminder: In the quest for digital security, complexity can be both a shield and a sword. When the balance tips, even a routine software update can ignite a crisis. By learning from these episodes, all parties involved can hope the ride becomes a little less bumpy with every cycle—and that, next time, recovery is swifter, easier, and less traumatic for everyone caught in the loop.
Source: Neowin Microsoft blames Intel as KB5058379 takes Windows PCs on a BitLocker recovery reboot ride