Rolling back drivers and uninstalling updates on a hunch can turn one problem into two. This page gives you the three checks that separate a genuinely update-caused IRQL crash from a coincidence - in about ten minutes, with nothing changed on the PC.
Most post-update blue screens really are the update's fault, but most is not all. RAM that was borderline for months often picks the week of an update to finally fail, simply because the update made the PC work harder. The difference matters: an update problem is cured by undoing a change, while a hardware problem is only hidden by that - briefly. So gather the evidence first. You need three things: when the crashes started, what the crash record says, and which driver the record names.
Windows logs every blue screen. That log is your timeline's anchor.
eventvwr.msc, open Windows Logs, System0x0000000a - and the date and time of each crashIf no 1001 entries exist, check Reliability Monitor instead: type perfmon /rel in the Run box for a day-by-day stability chart with red crash markers.
Now get the other half of the timeline.
Read the result honestly. Crashes starting the same day or the day after an install is strong evidence. Crashes that began a week before the update clear the update completely - uninstalling it would achieve nothing. Crashes starting two or three weeks later are weak evidence; keep investigating before you undo anything.
Timing shows opportunity; the dump shows the act. Windows saves small crash records in C:\Windows\Minidump. A free viewer such as BlueScreenView opens them and shows two things that matter here: the stop code, and the file named in the crash stack - often a driver file ending in .sys.
.sys file, search the file name to learn which product owns it - graphics, network, storage and antivirus drivers are the regulars for this stop codeThis page only reads the headline of the dump. The full dump-reading workflow lives in the master blue-screen guide in this series.
One more piece of evidence, often the decisive one in this pattern. Windows Update frequently installs drivers without any announcement.
You can also review Update history, Driver Updates directly - Windows lists them there even though it never prompted you.
Now combine the three checks into one of three verdicts. Proven update problem: crashes began within 48 hours of an install, and either a driver date matches or the dump names an updated component - proceed to rollback or uninstall with confidence. Possible: timing matches but the dump names nothing useful - try the rollback anyway, it is reversible. Not the update: crashes predate the update, or every dump names a different file - go to memory and hardware testing instead, and leave the updates alone. Writing the verdict down, even in one line, stops the most common failure in this work: changing five things, fixing it, and never knowing which change mattered - so it cannot be repeated or undone.
The video shows this crash pattern on a real machine after an update - a good companion once your evidence points at the update.
Watch Full VideoSmall minidumps are saved in C:\Windows\Minidump when the system is set to write them, and a full memory dump as C:\Windows\MEMORY.DMP. If the folder is empty, check Settings, System, About, Advanced system settings, Startup and Recovery - a dump type must be selected there. Note that disabling the paging file also disables dump writing.
Almost never. ntoskrnl.exe is the Windows kernel, and it is the file in charge when the crash is discovered - like a referee who blows the whistle. Look deeper in the stack for a third-party .sys file, and if none appears consistently across dumps, test the RAM. A kernel-only pattern is a classic memory-fault signature.
Yes - boot into Safe Mode or the recovery environment and read the same logs from there; Event Viewer works in Safe Mode. If even Safe Mode crashes, that itself is evidence: Safe Mode loads almost no third-party drivers, so crashes there point away from a replaced driver and towards hardware or core damage.