How to solve Windows 10 crashes in less than a minute.

See why Windows 10 crashed

Assuming all went well, just opening the dump file caused WinDbg to identify the OS and binaries, locate the correct symbol table file, download the needed files and run a basic analysis. If this is the first time WinDbg has been run on this system or if you are looking at a dump file from another system you have not loaded files for before, this may take a moment. In subsequent sessions, the analysis will likely be faster because most or all of the symbols needed will already be on the hard drive.

The information presented ranges from things such as the version of WinDbg, the location and name of the dump file opened, the symbol search path being used and even a brief analysis as shown below.

The line “Probably caused by : myfault.sys“ we know to be true in this case since it is the name of the driver for NotMyFault.

Often, when diagnosing the cause of a Windows crash, more information is needed. For instance, you might recognize the driver but you might not be certain that it is the latest release; you might not recognize the driver or know who made it; or in other cases, the driver might actually be from Microsoft and be related to the OS kernel, which makes it a very unlikely suspect. To learn more, all you will typically need are two commands:

!analyze -v and lmvm

NOTE: The first command is pronounced “bang analyze dash vee”

Over the years, Microsoft has continued to grow and refine WinDbg. For instance, while the two commands listed above would normally be entered in the command window at the bottom of the WinDbg screen that displays a “kd>” prompt (which stands for kernel debugger), both commands can now be initiated by selecting a hot link in the WinDbg interface.

!analyze -v The output from selecting !analyze -v provides more detail about the system crash event. In this case, the analysis accurately describes the actions of the test driver (myfault.sys) which was instructed by the test program to access an address at an interrupt level that was too high.

Output from !Analyze -v DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses.

The important points are that the suspect module named by WinDbg is myfault and that, since we know that this is a third-party driver, he is very likely guilty.

To get a better picture of what was happening when the OS fell over, look at the stack.

Walking the stack It is always important to look at the stack output displayed by the debugger because it shows who was active and what he was doing leading up to the crash. When looking at the stack, always look at the far right end of the stack for any third-party drivers and always remember that the stack is displayed in reverse chronological order. Therefore, the sequence of events goes from the bottom to the top; as each new task is performed by the system it shows up at the top, pushing the previous actions down. In this stack you can see that NotMyFault/myfault was active. Following the last activity by the driver, Windows 10 declared a PageFault then a BugCheck which stopped the system (Blue Screened).

The metaphor that I have often used in technical sessions is to relate stack walking with stepping into the room where a murder just took place and finding a body on the floor and someone standing over it with a smoking gun in his hand; it does not mean that he is guilty but it surely makes him suspect No.1.

Assuming that we need more information about the suspect module, run lmvm.

lmvm [module name] Now that we have a suspect module to consider, it is important to learn more about it. The two key reasons for this are simply to ensure that it is indeed a third-party module and to determine if it is an out of date module. lmvm tells both and more as shown in the exhibit. For instance, we can see that the maker of the module is SysInternals and that it has a timestamp of April 2012.

Granted, we know that SysInternals has been absorbed into Microsoft. However, the module is hardly a kernel OS driver, so it serves our demonstration purposes of playing the role of a third-party driver. Also, it is unlikely that a 4-year-old driver is up to date. If this were a real situation and the driver named was, for example, a video driver, there would almost certainly be a newer driver with fixes incorporated. From lmvm you would know what vendor to turn to for updated information on the driver and, likely, an updated version to install.

While most BSODs causes are easily attributed to third party drivers, some are not so clear. In these cases, the cause can be anything from an overheated system resulting from a failing case fan to faulty memory modules.

Recurring crashes that have no clear or consistent cause will often be from memory issues. Two good ways to check memory are the Windows 10 Memory Diagnostics and Memtest86.