A blue screen is Windows refusing to keep running because something in kernel mode did something it should not. It is dramatic, but it is also one of the more honest failures: the stop code and the crash dump usually point straight at the driver or the hardware responsible.
The mistake helpdesks make is to reboot, see it come back, and reimage. Take five minutes to read the dump first. Half the time it names a driver you can update, and the other half it tells you the hardware is failing, which a reimage will not fix.
Capture the stop code and what failed
Ask the user to photograph the blue screen next time. Two things on it matter: the stop code, such as IRQL_NOT_LESS_OR_EQUAL or DPC_WATCHDOG_VIOLATION, and the line What failed, which names a driver file when Windows knows it. A photo saves you from guessing.
If nobody caught it, Event Viewer has the record. In the System log, Event ID 1001 from source BugCheck lists the stop code and its parameters and the path to the dump file. Event ID 41 from Kernel-Power means the machine restarted without a clean shutdown, which includes blue screens but also power loss and hard resets; on its own it is not proof of a crash. Reliability Monitor (type reliability in Start) shows the same crashes on a timeline next to installed updates and drivers, which is often enough to spot the cause.
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WER-SystemErrorReporting'} -MaxEvents 10 | Format-List TimeCreated, MessageRead the minidump
Windows writes a small dump to C:\Windows\Minidump on every crash, as long as the page file is on the system drive and the setting has not been turned off under System Properties > Advanced > Startup and Recovery. Copy the newest .dmp file to your machine and open it in WinDbg, which is a free install from the Microsoft Store. Set the symbol path to the Microsoft public symbol server the first time, then run the analysis command below.
The output is long. Look for three lines: MODULE_NAME, IMAGE_NAME and the stack trace under STACK_TEXT. If the image name is a third-party driver, such as a VPN filter, an antivirus driver, a storage controller or a graphics driver, you have your suspect. If it is a Windows component like ntoskrnl.exe with nothing else in the stack, suspect memory or another hardware fault rather than Windows itself.
!analyze -vCommon stop codes and what they usually mean
These are the patterns that hold up across most fleets. Treat them as a starting point, not a verdict.
- IRQL_NOT_LESS_OR_EQUAL and KMODE_EXCEPTION_NOT_HANDLED: a driver did something wrong. Check What failed and the dump for the module.
- PAGE_FAULT_IN_NONPAGED_AREA: a bad driver or, if it recurs with different modules, failing RAM.
- SYSTEM_SERVICE_EXCEPTION: often a driver, sometimes a corrupt system file. Run DISM and SFC.
- DPC_WATCHDOG_VIOLATION: storage driver or firmware, often an SSD that needs a firmware update or an outdated storage controller driver.
- CRITICAL_PROCESS_DIED: a core Windows process crashed, frequently a sign of disk corruption or a broken update.
- VIDEO_TDR_FAILURE: the graphics driver stopped responding. Update or roll back the GPU driver, and check the docking station if it is a laptop.
- WHEA_UNCORRECTABLE_ERROR and MACHINE_CHECK_EXCEPTION: hardware. CPU, memory, motherboard, overheating or a failing power supply.
Hardware checks
When the dump points at hardware or keeps naming different modules, test the hardware before you reinstall anything. Run Windows Memory Diagnostic (mdsched.exe) with a reboot, and for a suspected memory fault run the longer test overnight. Check the drive with chkdsk and read its SMART health from the vendor's tool or the firmware diagnostics. Most business laptops have a built-in hardware test in the firmware boot menu, and it is worth running because it tests things Windows cannot.
Heat causes crashes too. A laptop that blue screens under load with a fan running flat out and a hot underside needs cleaning or a new thermal paste job. And update the firmware and the storage controller driver from the vendor; both fix crashes that look like software problems.
chkdsk C: /scanFix, roll back or reimage
If the dump named a driver, update it from the vendor or roll it back in Device Manager if it started after an update. If the crash began after a Windows update, Settings > Windows Update > Update history > Uninstall updates removes it, and you can pause updates for a few weeks while the vendor fixes the driver. Safe Mode with Networking is your friend when the machine will not stay up long enough to do any of this.
Reimage when the software is clearly damaged and the hardware tests clean, or when the dump analysis takes longer than a fresh image would. Do not reimage a machine with a failing drive or bad RAM. Write the stop code, the named module and the outcome into the ticket, because the same crash on the same laptop model across the fleet is a driver problem to fix once, not ten times.
Frequently asked questions
Why is there no minidump file after the crash?
The dump setting is turned off, the page file is disabled or on another drive, or the crash happened during boot before the dump could be written. Check Startup and Recovery under System Properties and make sure the page file lives on the system drive.
One blue screen in a year: is that worth investigating?
Note the stop code and move on. Investigate when it repeats, when it starts after a change, or when several machines of the same model show the same code.
Takeaway
Get the stop code and the failed module, open the minidump, and let the analysis name the driver or point at hardware. That five minutes is the difference between updating one driver and rebuilding a laptop that will crash again with a fresh image. Log the code and the cause so patterns across the fleet are visible.