If you see the following error, no worries:
*** WARNING: Unable to verify timestamp for myfault.sys *** ERROR: Module load completed but symbols could not be loaded for myfault.sys
This means that the debugger was looking for information on myfault.sys. However, since it is a third-party driver there are no symbols for it because Microsoft does not store all of the third-party drivers (OK, myfault.sys is made by SysInternals, which is owned by Microsoft, but it is certainly not a regular Microsoft product and, for our purposes, it represents a third-party driver). The point is that you can ignore this error message. Vendors do not typically ship drivers with symbol files and they aren't necessary to your work; you can pinpoint the problem driver without them.
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”
|!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.
Sign up for Computerworld eNewsletters.