You rebooted for a BIOS update, Windows started, then crapped out with a blue screen reading ERROR_FIRMWARE_UPDATED. The stop code is 0x000002D8. I've seen this on Dell Latitudes, HP EliteBooks, and a pile of Surface devices. It's almost never the firmware itself that's broken — it's the handoff between the firmware capsule and the running OS that gets tangled.
Quick explanation of what the bugcheck means. Windows uses something called a firmware capsule to stage a UEFI or BIOS update. On reboot, the capsule gets applied, then the OS resumes. If the firmware changes memory mappings, ACPI tables, or secure boot state while Windows still has stale assumptions about them, the kernel trips this bugcheck on purpose. It's a guard rail, not a random crash.
Cause 1: A pending firmware capsule that got interrupted
This is the big one. Nine times out of ten, the culprit is a firmware update that didn't finish cleanly. Laptop lid got closed. Power button got held. Windows Fast Startup kicked in and skipped the firmware handoff. The capsule sits half-applied, and every boot after that is a coin flip.
First thing to do — check if there's a staged capsule waiting.
powershell Get-WindowsUpdateLog | Select-String "Firmware" | Select-Object -Last 40Also look in C:\Windows\Logs\CBS\CBS.log and C:\$WinREAgent\ — leftover capsule files often sit right there. If you see a UEFI capsule file that's days old, it never applied.
The fix:
- Disable Fast Startup. Go to Control Panel → Power Options → Choose what the power buttons do → uncheck "Turn on fast startup". Fast Startup is the enemy of firmware updates and I've seen it corrupt the capsule handoff more times than I can count.
- Reboot into UEFI/BIOS directly (hold Shift while clicking Restart → Troubleshoot → Advanced → UEFI Firmware Settings). Let the firmware finish whatever it was doing.
- Once inside BIOS, check the version string. If it shows an intermediate build (like "1.4.2-pending" on Dell or a weird HP build tag), manually reflash the same version from a USB key using the vendor's tool.
- Reboot back to Windows and let it settle for 5 minutes before doing anything.
Don't try to "roll back" a half-applied capsule from within Windows. You'll make it worse. Always re-flash forward from UEFI.
Cause 2: Hyper-V or Virtualization-Based Security locking ACPI tables
Second most common. If VBS, Credential Guard, Memory Integrity, or Hyper-V is enabled, the hypervisor grabs ACPI and memory map tables at boot. When firmware updates them, the hypervisor's cached view is stale, and Windows trips 0x2D8 trying to reconcile the two.
You'll see this most on domain-joined machines where IT turned on Credential Guard via Group Policy, then pushed a BIOS update through something like Dell Command Update. Update applies, machine blue screens on the first post-update boot, then either recovers or loops.
Check if VBS is on:
msinfo32Look for "Virtualization-based security" — if it says "Running", that's likely your trigger. Also check under Device Security → Core Isolation → Memory Integrity.
Fix path:
- Boot into Safe Mode (VBS is off in Safe Mode).
- Disable Memory Integrity first:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled /t REG_DWORD /d 0 /f - Disable VBS:
bcdedit /set hypervisorlaunchtype off - Reboot normally. Let the firmware settle.
- Re-enable VBS and Memory Integrity once you've confirmed the firmware version is stable. Don't leave them off long-term on a corporate box.
On Surface devices, there's a related trigger — the Surface UEFI and Windows Hello pieces don't always sync after a firmware update. Run SurfaceUEFIUpdater.exe from the Surface Platform Installer, then reboot twice before touching Hello.
Cause 3: Bad RAM or failing NVMe masking as firmware chaos
Less common, but I've caught it multiple times. When RAM is marginal, the firmware capsule write itself can corrupt — it's loaded into memory before flashing. Same for machines with a dying NVMe that host the capsule staging directory. You get a 0x2D8 and assume firmware, but the firmware is fine and the hardware isn't.
This shows up as: firmware update completes, machine boots once, blue screens on the second or third reboot with the same code, and the BIOS version actually did change.
Run memtest86 from a USB stick for at least four full passes — overnight if you can. One pass is worthless, it misses the intermittent stuff. Look for NVMe health with CrystalDiskInfo or the vendor tool. If you're on a Samsung 970 or 980 Pro with old firmware, there's a known bug where power-state transitions during a capsule write corrupt the staging file.
If RAM or the drive fails, replace it and reflash the BIOS from a clean USB. Don't waste time on Windows-side fixes.
Quick-reference summary
| Cause | Symptom | Fix |
|---|---|---|
| Interrupted firmware capsule | Loops on every other boot, stale capsule files in C:\$WinREAgent\ |
Disable Fast Startup, reflash from UEFI via USB |
| VBS / Memory Integrity / Hyper-V | Corp machine, Credential Guard on, first boot after BIOS push | Safe Mode → disable HVCIm and VBS → reboot → re-enable |
| Bad RAM or failing NVMe | BIOS version actually changed, crashes on 2nd or 3rd boot | memtest86 4+ passes, check NVMe health, replace hardware, reflash |
One last thing — after any 0x2D8, check C:\Windows\Minidump. The dump will tell you whether the crash was in ntoskrnl (points to firmware handoff) or in a storage or memory driver (points to hardware). Five minutes reading the dump saves an hour of guessing. Use WinDbg Preview with !analyze -v and look at the faulting module before you start swapping parts.