0x00000090 Windows BSOD Fixes, Checks, and Recovery
0x00000090 is the PP1_INITIALIZATION_FAILED bug check, which means the Plug and Play (PnP) manager could not be initialized. An error occurred during Phase 1 initialization of the kernel-mode PnP manager. Start by checking the crash pattern, the minidump, and any recent driver or device changes before you make broader repairs. Guessing can waste time and send you toward the wrong fix.
This guide is part of our Windows BSOD stop codes: full list and fixes series.
What 0x00000090 means on Windows

0x00000090 is associated with the PP1_INITIALIZATION_FAILED bug check. In plain language, Windows hit a problem while initializing the kernel-mode Plug and Play manager during early startup. That makes the crash timing important: a failure during boot or immediately after a device change can help narrow down the trigger.
The crash timing is an early clue. A failure during boot points toward a driver or startup-related problem. A crash after sleep, resume, or plugging in hardware may point toward a device stack issue. An idle crash can still be driver related, but the dump usually gives a better answer than guessing.
Triage checklist: symptom, timing, likely fault, first test
| Visible symptom or crash timing | Most likely fault domain | First test to run | Next escalation step |
|---|---|---|---|
| Crash during startup or before sign-in | Driver or Windows startup problem | Safe Mode boot | Minidump review |
| Crash right after sleep or resume | Device driver or power-state issue | Device Manager for recent driver changes | Rollback or update the suspect driver |
| Crash after opening a specific app or attaching hardware | Device stack or third-party filter | Disconnect the device or remove the related software | Clean boot, then re-test |
| Crash at random idle times | Driver or Windows file damage | Review the latest minidump | SFC and DISM |
What the minidump file tells you

The minidump is the fastest way to confirm the failing module and the repeat trigger. Windows keeps small crash dumps that are often enough to show whether the same driver or kernel path failed each time.
Dump timing matters. If every dump appears after resume, that points away from a random crash and toward a power-state or driver branch. If the same module appears across several crashes, that is better evidence than a long list of symptoms.
How to open a dump in WinDbg
- Install WinDbg, then launch it as administrator.
- Open the newest crash dump file from the dump location on the affected PC.
- Use the debugger’s analysis command to inspect the bug check data and stack trace.
- Look for the module named in the failing stack, the “probably caused by” line, and any repeated driver name across crashes.
If the same third-party driver appears more than once, fix that branch first. If the dump points to Windows kernel code without a clear third-party module, move to driver, device, and Windows file checks next.
Is this a hardware or driver error?
Most often, this branch starts with a driver, especially if the crash follows sleep, resume, a new device, or a recent update. Use Device Manager to check for problem devices, recent changes, and whether a rollback is available. Hardware is still possible, but do not start there without dump evidence.
Driver branch: Device Manager first
- Open Device Manager.
- Check Display adapters, Storage controllers, Disk drives, Network adapters, and System devices for warning icons.
- Right-click the suspect device and open Properties > Driver.
- Choose Roll Back Driver if the crash started after an update.
- If rollback is unavailable, choose Update driver or Uninstall device, then reboot and retest.
After a feature update, also check recently changed storage, chipset, GPU, and network drivers.
How do I fix a 0x00000090 blue screen on Windows 11?
Start with the branch that matches the crash pattern: driver first if it follows an update or hardware action, then Windows repair commands. A simple reboot may not clear a bad driver path that stays active across restarts.
First-aid order for Windows 11
- Boot into Safe Mode and check if the stop code still appears.
- Open Settings > Windows Update and install any pending updates.
- Open Device Manager and roll back or update the suspect driver.
- Run
sfc /scannowin an elevated Command Prompt. - Run
DISM /Online /Cleanup-Image /RestoreHealth. - If the crash follows sleep or resume, disable Fast Startup in Control Panel > Power Options > Choose what the power buttons do.
If the stop code returns after those steps, use dump analysis before trying a repair install or Reset This PC.
Can bad RAM cause stop code 0x00000090?
Yes. Bad RAM can trigger this stop code, especially when crashes appear at random or during unrelated tasks. Memory faults can corrupt kernel structures before Windows finishes Plug and Play initialization, which can make the stop code look like a driver or OS problem until the memory test says otherwise.
RAM branch: Windows Memory Diagnostic
- Press Win + R, run mdsched.exe, and choose Restart now and check for problems.
- After the test, review the result in the notification area or Event Viewer.
- If errors appear, remove one memory module, then run the test again. Repeat with each module until you identify the failing stick.
- If the machine still crashes with known-good RAM, move back to the driver and Windows repair branches.
Memtest86 can be a better longer test when the built-in check is clean but suspicion remains. Use it when the crash pattern is hard to reproduce.
Does 0x00000090 indicate disk corruption or malware?
Disk corruption is a possibility when the crash appears during boot or alongside file errors; malware is much less likely unless the system also shows clear compromise signs. The useful question is whether Windows can read its own files and component store cleanly. That is where CHKDSK, SFC, and DISM fit.
Storage and Windows repair branch
- Open an elevated Command Prompt and run
chkdskC: /scan. - If
CHKDSKreports issues, schedule an offline repair withchkdskC: /f. - Run
sfc /scannowto repair protected system files. - Run
DISM /Online /Cleanup-Image /RestoreHealthif SFC cannot fix files or reports unrepaired damage. - If the crash began after a failed update or disk event, review Event Viewer > Windows Logs > System for disk, NTFS, or storage controller errors.
Persistent repair failures after DISM can point to deeper Windows damage or failing storage. That is the point where a repair install makes more sense than more guesswork.
How do I diagnose 0x00000090 from dump files?
Use WinDbg with symbols, then compare the same module across several dumps. One dump can mislead. Two or three dumps that blame the same driver, filter, or storage component are much better evidence. If the stack changes each time, suspect corruption, memory, or a broader Windows issue.
What to look for in WinDbg output
- Open the dump and run the debugger’s analysis command.
- Note the bugcheck line, stack trace, and any named module.
- Check whether the module is a GPU, Wi-Fi, storage, chipset, or virtualization driver.
- Compare the failing module against Driver Details in Device Manager.
- If the dump mentions only Windows kernel code, move to SFC, DISM,
CHKDSK, and memory testing.
A clean symbol path matters. Without it, the stack trace can be hard to trust and the wrong driver can get blamed.
What should I do if 0x00000090 keeps happening after reboot?

Repeated crashes after reboot, sleep, or resume usually mean the trigger is still present. At that point, treat the pattern as evidence. A failure that returns after sleep points to a power-state or device driver problem; a failure that returns only after a specific USB device or dock is attached points to that device path.
Repeat-failure isolation steps
- Boot into Safe Mode and confirm whether the crash stops.
- Open Event Viewer and Reliability Monitor to note the exact time and repeated device or driver events.
- Remove recent software, security tools, filter drivers, or peripheral utilities one at a time.
- Test after each removal, then make the next change only if the crash is still gone or still present.
- If the crash follows a firmware or BIOS change, restore stable settings and retest.
Prevention: after recovery, keep a copy of the newest minidump and the exact driver version that fixed the issue. That makes the next fault much easier to compare.
Frequently asked questions
Is 0x00000090 a hardware or driver error?
Either is possible, but drivers usually get checked first because they are easier to prove from dumps and device status. If WinDbg names a module or Device Manager shows a recent change, start there. If dumps are inconsistent, memory and Windows file checks move up the list.
Which driver updates help with 0x00000090 BSOD?
Focus on GPU, storage controller, chipset, Wi-Fi, and any virtualization-related driver that changed recently. In Device Manager, use Driver tab options to roll back the last update or uninstall the suspect device, then reboot and compare the next dump.






