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”
|!analyze -v||Analyze the crash event in verbose mode||Describe the state of the system when it crashed, the fault encountered and identify the likely culprit|
|Lmvm [module name]||Load module data in verbose mode||Display metadata for the module named after the command|
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.
Is Windows guilty?
Probably not. For many years, many people have been quick to blame the Windows OS for system crashes when, in fact, it rarely is. Often, when Windows code is named as the culprit, it is typically that some other driver made a request for a Windows component to perform an operation and passed a bad instruction, such as telling it to write to non-existent memory. In cases like this, the OS is often seen as the guy holding the smoking gun, but he did what he was told to do, making identification of the initiator of the request often a difficult task.
What about antivirus, backup and other utilities? It is common to see drivers like those used for antivirus or backup utilities named as the culprit. However, they might not be the bad guy. Such utilities must be active because they have to keep an eye on file change activities meaning that, regardless of what else is going on, they will often be found on the stack.
Regardless of whether you find a viable culprit named, use Google; whatever problem you are experiencing has probably been experienced by others and there are myriad places on the Internet with helpful information.
The time it takes you to read this article and to set up WinDbg will be well compensated when you find that you’ll be able to resolve most BSODs in less than a minute without help and for free. And remember that a careful study of Windows Internalswill extend your new-found skills dramatically.
Dirk Smith is a freelance writer. He can be reached at firstname.lastname@example.org.