Kmode exception not handled: the stop code and what to do

What the stop code says

Microsoft’s documentation gives the bug check a value, 0x0000001E, and one sentence of meaning: it “indicates that a kernel-mode program generated an exception that the error handler didn’t catch”. The page is written for programmers, and says so: a customer whose computer shows a blue screen is sent to its separate guide on blue screen errors.

The bug check carries four parameters. The first is the exception code that was not handled, the second the address where the exception occurred, and the other two exception information. Microsoft lists three common exception codes, in the figure below, and says that for 0xC0000005, a memory access violation, the fourth parameter is the address the driver tried to reach. For a person without a debugger these numbers are mostly useful to someone else: Microsoft says the exception address, parameter 2, should identify the driver or function that caused the problem.

PC Gamer explains the error in other terms, as a case of “applications overwrite each other’s memory”. Microsoft’s page does not describe it that way. Its wording is an exception that was not caught, and only one of the three codes it lists is about memory access.

What usually causes it, in Microsoft’s numbers

For this code Microsoft says that a faulty device driver or system service might cause the error, and that hardware issues such as BIOS incompatibilities, memory conflicts and IRQ conflicts can also produce it. Another Microsoft article, on stop errors in general, puts numbers on where such crashes come from, shown in the figure below: “70% are caused by third-party driver code.” Hardware is 10%, Microsoft’s own code 5%, and 15% remain unknown because the memory is too corrupted to analyse. These shares are for stop errors as a group, not for this code alone.

The same article gives a second figure in its section on Driver Verifier: “We estimate that about 75 percent of all stop errors are caused by faulty drivers.” It is a different count from the first, and read together they suggest looking at the drivers before the RAM.

In Microsoft’s order

Microsoft’s support page says that in most cases of an unexpected restart “the problem is resolved by the restart and no further action is needed”, and that if the same stop code returns, you should remove new hardware, start in safe mode if the PC will not restart, check Device Manager for devices marked with an exclamation point, update their driver or disable or uninstall the device, keep 10% to 15% of the drive free, install the latest Windows updates and, last, restore Windows from a restore point or another recovery option.

For this code the Learn pages add the specific steps in the table above. To use safe mode when Windows restarts before you can do anything, Microsoft gives this route: Settings, Update & security, Recovery, and under Advanced startup choose Restart now; after the Choose an option screen, Troubleshoot, Advanced options, Startup Settings, Restart; then press 4 or F4 for safe mode, or 5 or F5 for safe mode with networking. Microsoft says the safe-mode route can disable the driver in Device Manager if the system partition uses NTFS.

Finding the driver: the dump file

Windows can write a record of the crash. In Microsoft’s steps, type Advanced system settings in the taskbar search, open Settings under Startup and Recovery on the Advanced tab, choose Automatic memory dump under Write debugging information, select OK and restart. The small memory dump, 256 KB, is saved in %SystemRoot%\Minidump, and the larger ones in %SystemRoot%\MEMORY.DMP, as in the figure below. Microsoft also offers DumpChk to check that a dump file is not corrupted.

Reading a dump needs a debugger, and Microsoft’s page for programmers describes a procedure with commands such as kb, .trap and .cxr. A thread in Microsoft’s community shows what an analysis can find. A user sent the minidumps of repeated Kmode exception crashes, and the person who read them wrote that they mentioned no driver, only memory corruption. The user then planned to update the BIOS and to turn off AMD EXPO, the only overclocking on the machine. Those are users’ answers, not Microsoft’s documentation.

Driver Verifier, with care

When the drivers are the suspects and nothing names one, Microsoft’s stop-code article points to Driver Verifier. It warns that the tool uses a lot of CPU and can slow the computer down, can cause additional crashes and creates several dump files. Its rules are to test suspicious drivers, such as those just updated; “Don’t try to verify all the drivers at one time”; and to verify groups of 10 to 20 drivers if the crashes cannot be analysed. If the computer cannot reach the desktop because of the tool, Microsoft says to start in safe mode, where it cannot run.

What the guides add, and where they are weaker

Three of the guides we read name Fast Startup. PC Gamer says its recovery from hibernation can reload driver problems that were already there. Puget Systems says that Fast Startup is a hybrid between shutdown and hibernation and that loading drivers is one of its problems, and tells you to uncheck Turn on fast start-up; its guide is from 12 June 2019, with a note that some of it may be out of date. The third is a blog of IObit, the company that sells a driver updater, which names that product fourteen times. None of Microsoft’s pages that we read mentions Fast Startup in connection with this stop code, so treat it as a user’s remedy, not as Microsoft’s.

Puget Systems also suggests Windows Memory Diagnostic: search for Memory Diagnostic, choose to restart and check, and, if hard errors appear, reseat the RAM and replace the stick if that fails. Microsoft’s page for this code says the same in other words, to run the hardware diagnostics supplied by the maker, memory scanner first. The user in the Microsoft thread above ran the Windows Memory Diagnostic and saw no errors, and the reply that read the dumps still found memory corruption: one user’s case, not a rule.