1. Corrupted Driver Cache (DriverStore) — the real culprit 90% of the time
What's actually happening here is that Windows keeps a local copy of every driver you've ever installed inside C:\Windows\System32\DriverStore\FileRepository. When that cache gets a single corrupt file — maybe from a failed update or a forced shutdown — the system can't read the driver database next time it boots. You see the 0X0000028C error.
This usually happens after you install a new GPU driver or a Windows update that interrupted halfway. The exact scenario: you're installing NVIDIA driver 546.17, the power dies, and next boot shows a blue screen with this error.
The fix is to delete the corrupted driver cache and let Windows rebuild it. Here's how:
- Boot into Safe Mode. Hold Shift while clicking Restart, then go to Troubleshoot > Advanced options > Startup Settings > Restart. Press 4 for Safe Mode.
- Open Command Prompt as Administrator (right-click Start).
- Run this command to see what's in the driver store:
pnputil /enum-drivers - Look for any driver marked "Published" with a date right before the crash. Note its oemXX.inf number.
- Delete the offending driver package:
Replace oemXX.inf with the actual number.pnputil /delete-driver oemXX.inf - If you can't find a specific one, nuke the whole cache (last resort):
del /f /s /q C:\Windows\System32\DriverStore\FileRepository\*.* - Reboot normally. Windows will rebuild the driver store from the built-in drivers.
Why step 6 works: Deleting theFileRepositoryfolder forces Windows to regenerate the database from the original driver packages stored inC:\Windows\System32\DriverStore\. It's safe because Windows keeps a backup. But you'll lose any manufacturer-specific drivers (like from Dell or Lenovo) — you'll need to reinstall those.
2. Corrupted System Files (SFC / DISM) — the second biggest cause
Sometimes the driver database itself isn't broken — it's the system files that manage the database. A damaged drvmain.sdb or driver.stl file can cause the same error. This happens after a Windows update that didn't finish properly, or if you used a system cleaner that deleted something it shouldn't.
The fix here is to repair the system image first, then scan system files. This order matters — don't skip it.
- Boot into Safe Mode again (same steps as above).
- Open Command Prompt as Administrator.
- First, repair the Windows image (this fixes the source files that SFC uses):
Let it run — it takes 10-20 minutes. It downloads fresh files from Windows Update.DISM /Online /Cleanup-Image /RestoreHealth - After it finishes, run the System File Checker:
sfc /scannow - If SFC finds corrupt files it can't fix, run DISM again with a local source:
You need a Windows installation media (USB or ISO) mounted asDISM /Online /Cleanup-Image /RestoreHealth /Source:C:\RepairSource\Windows /LimitAccessC:\RepairSource. If you don't have one, skip this — try the first fix again. - Reboot.
Why DISM before SFC: SFC needs clean source files to replace corrupted ones. If the component store (WinSxS) is damaged, SFC will fail or make things worse. DISM repairs that store first.
3. Manual driver rollback from Windows Recovery — when you can't even boot to Safe Mode
If the error shows up immediately and you can't reach Safe Mode, you're stuck at the blue screen. This usually happens when a driver update applied during the last shutdown got corrupted. The system tries to load it, fails, and crashes before you can do anything.
The fix: use the Windows Recovery Environment (WinRE) to roll back the driver.
- Force shutdown your PC three times: hold the power button down until it turns off, turn it on, and when you see the spinning dots, hold the power button again. Do this three times. On the fourth boot, WinRE should appear.
- Go to Troubleshoot > Advanced options > Command Prompt.
- Find the offending driver:
Look for drivers added recently (check the date column).pnputil /enum-drivers - Roll back by deleting the driver package:
pnputil /delete-driver oemXX.inf /uninstall - If you don't know which one, disable driver signing enforcement temporarily:
Then reboot. This lets Windows ignore driver signature checks, which sometimes bypasses the corruption. After booting, run DISM and SFC from normal Windows.bcdedit /set {default} testsigning on - Once you're in Windows, don't forget to turn off test signing:
bcdedit /set {default} testsigning off
Why test signing works: Driver database corruption often shows up as a signature validation failure. Test signing mode skips that check entirely. It's a band-aid, not a fix — use it only to get back into Windows.
Quick-reference summary table
| Cause | Fix | When to use |
|---|---|---|
| Corrupted driver cache | Delete FileRepository folder or specific OEM driver | After failed driver install or power loss |
| Corrupted system files | DISM then SFC (in that order) | After bad Windows update or system cleaner |
| Can't boot to Safe Mode | WinRE > pnputil delete driver or enable testsigning | Immediate crash on boot, no recovery options |
Most people I've helped fix this with step 1 — clearing the driver cache. It's fast, it's safe, and it solves the root cause. Don't waste time reinstalling Windows until you've tried these three things.