This blog is about a new kind of silent recovery built into Windows. It’s not about safe mode or startup repair but something more powerful! Something that can quietly bring your devices back when they no longer can boot to Windows. We’re diving into Quick Machine Recovery.
When Windows devices fail to boot
There’s a moment every IT admin fears: a fleet of Windows devices suddenly fails to boot. There is no clear error (only a stupid BSOD mentioning that your PC ran into a problem), no USB recovery media nearby (or a fleet of IT admins), and no way to intervene at scale.
This is exactly what happened during the infamous CrowdStrike update incident! Machines started to crash into blue screens of death across the globe. Recovery wasn’t just about fixing one device. It was about repairing thousands of them. That’s the kind of chaos Quick Machine Recovery is meant to deal with.
A New Kind of Cloud Recovery
Quick Machine Recovery, also known as Cloud Remediation (or RecoveryRobustness), is a feature built into the Windows Recovery Environment (WinRE).
Unlike traditional repair options that rely on user intervention, it activates automatically when the system detects failure. This is how it looks like when Quick Machine recovery kicks in and tries to find a solution for the issue (in this case the test mode was activated)
It’s driven by recovery settings in SrSettings.ini, evaluated by StartRep.exe (Executable responsible for the Quick Machine Recovery which is located in the winre: x:\sources\recovery )
The whole cloud remediation process is pretty straightforward: it checks if flags/settings like CloudRemediation, AutoRemediation, and optionally HeadlessMode are set. If the environment meets the conditions (such as an available network and required plugin), Windows silently initiates recovery.
How to Enable Quick Machine Recovery
QMR can be configured through the RemoteRemediation CSP in Intune. You can deploy this policy by defining the corrosponding CSP: ./Device/Vendor/MSFT/RemoteRemediation/CloudRemediationSettings
Once enabled, Cloud Recovery decisions become policy-driven rather than relying on manual intervention.
Please Note: Quick Machine Recovery is only available for Windows Insiders builds!Simulating a Failure
Microsoft includes a test pathway for Quick Machine Recovery, by calling the reagentc.exe /setrecoverytestmode (WinReSetRecoveryTestMode) function.
This will place a simulation file (RecoverySimulation.ini) in the system32\recovery folder. This file contains flags such as:
[Recovery]
- Active=Yes
- HeadlessMode=Yes
- AutoRemediation=Yes
- CloudRemediation=Yes
Besides the recovery file, it will also configure the RUN registry key inside the reliability\srt registry key.
Once this recovery file and the run key are created, the device will reboot into WinRE, triggering the logic that would typically run in a failure scenario.
Behind the Curtain: The Quick Machine Recovery Flow
When the recovery sequence starts, StartRep.exe begins parsing the configuration. The ReadRecoverySettings function determines whether CloudRemediation is allowed, whether AutoRemediation is on, and whether HeadlessMode is set. If all checks pass and a network-compatible plugin is present, recovery starts.
When looking under the hood, the plugin loaded at step 4 is the BootCriticalUpdatePlugin.dll. For now, it’s the only plugin that is loaded when the Quick Machine Recovery is initialzing
From there on, it leverages the BcuUsoHelper component to scan for, download, and apply the remediations defined in the remediations.ini.
If everything succeeds, the system will be rebooted, and your device will be up and running again! If you are interested in the detailed flow of how the first few steps behind this functionality work, you may want to take a look at the flow (based on the code of the startrep init function), You can download it here:
No UI Required: Headless Recovery
Headless Mode is another thing that caught my attention. We spotted this mode in the reagent log and the recovery settings config file.
While not really documented in Microsoft’s documentation, HeadlessMode is recognized internally and handled by the ReadRecoverySettings function. It’s part of the logic flow when the reagent checks all the settings.
When looking at the code… this is what it tells me
The Evidence is in the Logs
The remediation process leaves behind logs in the system32\logfiles\srt and reagent folder. If you inspect setupact.log, you’ll find all the information you need to know what happened:
- StarRep.exe is doing the work!
- AutoRemediation Setting = On
- Plugin initialized: BootCriticalUpdatePlugin.dll
- Scan, download, install result: success
As shown above, the log file captures every step that Cloud Remediation takes. (which made it way easier to find the corresponding code) But how could the device access my drive with Bitlocker enabled?
What About BitLocker?
While playing around with Quick Machine recovery, Bitlocker was enabled to protect my drive.
Somehow, Quick Machine Recovery could still access the local drive? As if BitLocker wasn’t even there. As shown below, the BootCriticalUpdatePlugin could still load the software/system registry hives from the local drive to inspect them.
This might seem strange at first, but it actually makes sense when you look at how BitLocker works behind the scenes. When the recovery environment (WinRE) is launched from the same internal disk, and nothing about the boot process has changed (like Secure Boot, the boot order, or firmware settings), the system still trusts the environment. Because of that, the TPM can unlock the drive automatically without asking for the BitLocker recovery key.
It uses something called PCR values (Platform Configuration Registers) to check if the system is in the same state it was when BitLocker was set up. If everything matches, it quietly unlocks the drive. So yeah, in this case, WinRE could access the encrypted disk just fine because everything looked normal and trusted from the TPM and BitLocker’s point of view.
Why It Matters
This is how Windows could recover on its own when issues are found. We no longer need USB or IT admins running from one computer to another and the next and the next. Just one Intune policy to enable Cloud Remediation. Quick Machine Recovery is a response to large-scale crises like CrowdStrike’s meltdown. It gives enterprises a fallback path when things go sideways.
In Closing
Quick Machine Recovery is a glimpse of modern, scalable remediation. If you manage Intune-enrolled devices, enabling this QMR feature could be the difference between a quick rebound and hours of lost productivity (AKA money). There is no UI, no panic, just silent cloud recovery in the background, which is exactly what we need when our devices are stuck on a BSOD!