Blue Screen With No Error Code — How to Find What Crashed
Short answer
Windows saves a crash dump to C:\Windows\Minidump every time it blue-screens, regardless of what the screen displayed. Open the most recent .dmp file with the free WinDbg from the Microsoft Store and run !analyze -v — it names the module that caused the fault, which is a driver file in the great majority of cases. Event Viewer's Event 41 entries confirm the date and time of each crash.
On this page
A blue screen that shows a progress percentage, a sad face and nothing else is infuriating, and the useful information is not gone. Windows writes a crash dump to disk every time, and that file names the module that caused the fault.
Reading it is easier than its reputation suggests. You need one free tool and one command.
Confirm it crashed, and when
Before opening anything, establish the pattern. Press Win+X and choose Event Viewer, then navigate to Windows Logs → System.
Click Filter Current Log in the right-hand pane and enter 41 in the event
ID box. Each result is a Kernel-Power critical event, logged when the system
restarted without shutting down cleanly.
This tells you how often it happens and at what times. It does not tell you why — Event 41 is a record of the symptom. People spend a lot of time staring at it expecting more.
Also worth filtering for Event ID 1001 from BugCheck, which does record the stop code and the dump file path when Windows managed to write one. If that event exists, you have the stop code the screen did not show you.
While you are in System, scan the few minutes before each crash for red Error entries. A storage controller error or a repeated driver warning immediately before every crash is a strong lead.
Read the minidump
This is the step that actually names the cause.
Check the dumps exist. Open C:\Windows\Minidump. You should see .dmp
files named by date. If the folder is empty or missing, dump writing is
disabled — see the next section.
Install WinDbg. The current version is free in the Microsoft Store, listed as WinDbg. It is Microsoft’s own debugger and it replaces the older standalone tools people still link to.
Open the dump and analyse it:
- Launch WinDbg, choose File → Open dump file, and select the most recent
.dmp. - Wait while it downloads symbol files. The first run takes a few minutes.
- In the command box at the bottom, type
!analyze -vand press Enter.
The output is long. Three lines matter:
MODULE_NAME— the component blamed.IMAGE_NAME— the actual file, such asnvlddmkm.sysorrtwlane.sys.- The bug check name, for example
DRIVER_IRQL_NOT_LESS_OR_EQUAL.
A .sys file in IMAGE_NAME is a driver, and searching that filename
identifies which device it belongs to. nvlddmkm.sys is NVIDIA graphics,
rt640x64.sys is a Realtek network adapter, and so on.
When it blames ntoskrnl.exe or hal.dll, that is Windows’ own kernel and
it is almost never the real cause. It means the fault was detected in the kernel
after something else corrupted memory or returned bad data. Treat it as
inconclusive and look at the pattern across several dumps instead, or move
straight to hardware testing.
Turn dump writing back on if it is off
System Properties → Advanced → Startup and Recovery → Settings. Under System failure:
- Tick Write an event to the system log.
- Set Write debugging information to Small memory dump (256 KB).
- Untick Automatically restart while you are diagnosing, so the blue screen stays visible long enough to photograph.
Reach System Properties by searching Start for View advanced system settings. Dump writing also silently fails if the page file is disabled or too small, which is one more reason not to turn it off.
Interpret the pattern
| Pattern across several dumps | Likely cause |
|---|---|
Same .sys file each time |
That driver. Update or roll back. |
| Different module each time | Memory or storage fault |
| Only during gaming or heavy load | Graphics driver, power supply, or heat |
| Started after an update | Driver replaced by Windows Update |
ntoskrnl.exe every time |
Inconclusive; test hardware |
The second row is the one people chase wrongly for weeks. Faulty RAM corrupts whatever happens to be in memory, so each crash blames a different innocent module. If your dumps disagree with each other, stop chasing drivers and test memory.
Fix the named driver
Once a driver is identified:
Update it from the vendor, not Windows Update. Graphics drivers from NVIDIA, AMD or Intel directly; network and chipset drivers from your laptop manufacturer’s support page for the exact model number. Windows Update ships conservative generic versions that are frequently the problem rather than the fix.
Or roll it back, if crashes started after an update. Device Manager → right-click the device → Properties → Driver tab → Roll Back Driver. The button is greyed out if no previous version is retained.
Uninstall cleanly for graphics drivers. NVIDIA’s installer has a Custom option with Perform a clean installation; AMD’s has a factory reset option. Installing over the top of a damaged driver carries the damage forward.
Test the hardware
Where the dumps disagree or blame the kernel, move to hardware.
Memory. Search Start for Windows Memory Diagnostic and let it restart and test. A pass is reassuring rather than conclusive — MemTest86 from a USB stick, run for several passes over a few hours, is the thorough version. Test one module at a time if you have more than one.
Storage. Open Terminal (Admin) and run:
chkdsk C: /scanThis scans without taking the volume offline. Separately, CrystalDiskInfo reads the drive’s SMART data; anything other than a Good health status on the system drive deserves immediate attention and a backup.
Heat and power. Crashes only under load point at thermal throttling failing or a power supply that cannot sustain peak draw. Check temperatures during a game. A PSU several years old driving a newer graphics card is a classic cause of load-only crashes that no driver update resolves.
Overclocks and XMP. Any memory or CPU overclock, including an XMP or EXPO memory profile, should be set back to defaults while diagnosing. An almost-stable memory profile produces exactly this pattern of random, varied crashes.
Repair Windows itself
If the hardware tests clean and no single driver is implicated, repair the system files. In Terminal (Admin):
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealthAllow 10–30 minutes and restart afterwards.
If crashes began on a date you can identify, System Restore rewinds drivers and system settings without touching your files — choosing between System Restore and a reset covers which is appropriate and what each one costs you.
What does not help
- Searching the stop code alone.
DRIVER_IRQL_NOT_LESS_OR_EQUALdescribes the category of fault, not the culprit. The module name is the information. - Driver updater utilities. They install generic packages from aggregated repositories, and they are a well-known source of new crashes.
- Registry cleaners. No relationship to kernel faults.
- Reinstalling Windows before testing hardware. A failing memory module crashes a fresh installation just as reliably.
- Disabling automatic restart and then stopping there. It makes the screen readable; the dump is still where the answer lives.
Realistic expectations
Reading one minidump typically names the failing driver within ten minutes including the tool install, and updating or rolling back that driver resolves the majority of cases.
Where the dumps disagree with one another, budget a few hours rather than minutes: memory testing is slow and has to run long enough to be meaningful. That time is still better spent than on another round of driver updates.
The honest limit is intermittent hardware. A memory module that fails once a week under a specific access pattern can pass an overnight test, and a marginal power supply shows nothing at all in software. If crashes persist after clean drivers, clean system files and a clean memory test, swapping components one at a time is the remaining method, and it is a slow one.