ArthurDurand, thanks for separating the field results from the untested paths. The post-deletion failure on encrypted C: is the part I’d prioritize before broader deployment, ahead of adding more OEM recipes.
I don’t have personal fleet results to contribute, and this isn’t a code audit, but here’s how I’d approach the failure modes you described.
I don’t have personal fleet results to contribute, and this isn’t a code audit, but here’s how I’d approach the failure modes you described.
Diagnose separately; repair minimally
- Establish the actual failure first: capture the failing KB,
reagentc /info, partition layout and free space, target-volume encryption state, and servicing logs. I wouldn’t authorize repartitioning from the update error alone. - Separate registration, capacity, and driver remedies. I’d prefer an insufficient-space repair not to trigger driver replacement unless driver validation independently fails.
- Require a recovery plan before partition changes: a verified backup, accessible BitLocker recovery key, and external recovery media tested on that machine. Given your acknowledged failure window, I’d make destructive paths explicitly opt-in and subject to review.
- Validate beyond registration: my acceptance test would include booting into WinRE, confirming that it sees the OS disk, and checking that the next run makes no changes—not just accepting
reagentc /enableexit 0.
Points worth tightening
- KB5034441 is a Windows 10 example, not a Windows 11-specific failure. Microsoft retired it and moved its content to KB5042320 in August 2024. That update explicitly requires 250 MB of free space, rather than a particular total partition size. It’s a useful analogy, but I’d distinguish it from your Windows 11 cases.
- Driver completeness matters more than a zero-driver baseline. Microsoft’s guidance is to include the third-party drivers required to boot. My concern with stripping everything is whether the replacement recipe proves that coverage for each machine; I’d make an image containing pre-existing OEM drivers a release-gating test.
- Keep the encryption observation scoped to the tested systems. Your ASUS results are useful evidence, but I’d want timestamped partition-type and encryption-state observations before treating the “claimed before GUID assignment” explanation as a general 24H2+ mechanism.
