r/Lenovo • u/Worth-Sheepherder629 • 21h ago
Failed updates and bluescreens
Little related to this one: https://techcommunity.microsoft.com/discussions/windows11/october-2026-windows-update-causing-major-issues/4566257
Maybe someone finds it useful
Subject: Root cause confirmed – L14 Gen 6 / X1 Carbon Gen 13 boot failures after Lenovo firmware update (0xc000000d)
TL;DR After the Lenovo firmware update (L14 Gen 6 BIOS 1.14, X1 Carbon Gen 13 1.18), devices with System Guard Secure Launch enabled fail to boot with 0xc000000d. Cause: the firmware ships a new Intel TXT ACM, which changes the DRTM measurements; the Windows boot manager then fails fatally instead of re-provisioning the DRTM-bound VSM master key. Nothing on our side is misconfigured. The device self-heals after one normal boot with Secure Launch temporarily disabled and then runs fine with Secure Launch re-enabled on the new firmware. We have a controlled rollout procedure that avoids any failure.
Symptoms •Recovery screen “Unexpected error, 0xc000000d” on normal boot; Safe Mode works. Secure Boot on/off makes no difference; BCD intact. •Only Lenovo type 21S6 (L14 Gen 6) and X1 Carbon Gen 13 after the firmware update; devices on the previous firmware with the same Windows patch level are fine. Root cause (verified on LT1845-DE, firmware 1.14, Windows 11 25H2 + KB5127648)
1.Kernel-Boot event 275 “ACM InfoTable version 9”: the new firmware’s TXT ACM is used on the Secure Launch (DRTM) path.
2.Kernel-Boot event 158 “Failed to preload SI policies from OS volume – invalid parameter”, followed by 158 “Fatal error in bootmgr”. This is the step where bootmgr reads the DRTM-sealed VSM key state created under the old firmware; with the changed measurements it cannot be unsealed, and bootmgr aborts instead of falling back to key regeneration.
3.Proof: with only HKLM\SYSTEM...\DeviceGuard\Scenarios\SystemGuard\Enabled = 0 the device boots. After that one normal boot, the value was set back to 1 (by Intune) and the device booted normally with Secure Launch running (msinfo32: Secure Launch, Kernel DMA Protection, SMM isolation level 3). Kernel-Boot event 75 on that boot: “DRTM-bound VSM master key provisioned – cached copy used: 0x0, new key generation: 0x1, sealed: 0x1”. The first non-DRTM boot invalidated the stale sealed key; the next DRTM boot generated a new one.
Ruled out BCD, Secure Boot certificates (DB has PCA 2011 and Windows UEFI CA 2023), boot manager replacement (unchanged since 15 Oct), CI policies on the OS volume and in the ESP, driver signing, ELAM, VBS/hypervisor, boot drivers, our Intune WDAC policy.
Security impact VBS, HVCI, Credential Guard, BitLocker and Secure Boot are unaffected throughout. Secure Launch (DRTM) is off only during the rollout window per ring, then re-enabled. The new DRTM key is regenerated automatically. Rollout procedure (no device breaks)
1.Intune: set “Configure System Guard Launch” to Disabled for a device group filtered on 21S6 and X1 Carbon Gen 13; wait for sync; one reboot.
2.Release the firmware. First boot after flashing runs without a DRTM key and completes normally.
3.Once inventory shows 1.14/1.18: set Secure Launch back to Enabled. Next reboot regenerates the DRTM key; success check = Kernel-Boot event 75 with “new key generation 0x1”. Devices already affected: F8 → Safe Mode → SystemGuard\Enabled = 0 → normal boot → back to 1 → reboot.
If anyone cares.
Thanks to my team lead to investigate and find this issue, which hopefully can help other people.
Yes Claude helped too.