Configuring WinDbg Correlating a Windows dump file with the appropriate symbol files is not merely a matter of knowing which version number of the OS was running. There are myriad variants to the OS, a fact that is not obvious. The only way to be sure which file is correct is to let SymServ find it for you.
Setting the symbol file path There are a huge number of symbol table files for Windows because every build, every update, every patch and the myriad one-off variants each result in a new file. And using the wrong symbols to evaluate a dump file would be like using a map for Boston to navigate San Francisco.
Enter the following path: srv*c:\cache*http://msdl.microsoft.com/download/symbols
In place of *c:\cache*, be sure to insert what location you want to store symbols.
In this case, c:\symbols was used. Then select OK.
Note: be sure that your firewall allows access to msdl.microsoft.com not just www.microsoft.com.
What if you don’t have a memory dump to look at? No worries. You can generate one yourself. Yes, you can cause your system to crash and do so safely. There are different ways to do it but the best way is to use a cool tool called NotMyFault created by Russinovich.
Download NotMyFault To get NotMyFault, go to the Windows Internals Book page at SysInternals and scroll down to the Book Tools section where you will see a link to download it. The tool includes a selection of options that load a misbehaving driver (which requires administrative privileges). After downloading, I created a shortcut from the desktop to simplify access.
Note that Chapter 14 (Part Two of the book) thoroughly covers the use of NotMyFault and, more importantly, crash dump analysis.
WARNING: Using NotMyFault will create a system crash and while I’ve never seen a problem using the tool, there are no guarantees in life, especially in computers. So, prepare your system and have anyone who needs access to it log off for a few minutes. Save any files that contain information that you might otherwise lose and close all applications. Properly prepared, the machine should go down, reboot and both a minidump and a kernel (or whatever size you select) dump should be created.
Opening a dump file
Locating a dump file Dump files in Windows systems are located in two places, depending upon which type you open:
- All dump files except minidumps: c:\Windows\MEMORY.DMP
- Minidumps: c:\Windows\Minidump\[Minidump names vary]
Note that, unlike the other dump files that are named MEMORY.DMP, minidumps are automatically individually named so that previous files are not overwritten, which is fine since they are so small.
Open a dump file To open the file you’ve selected, go to
Select File | Open Crash Dump
If you see the following, STOP:
*** WARNING: Unable to verify timestamp for ntoskrnl.exe *** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe This is important. When you see these two messages near the beginning of the output from WinDbg, it means that you will not get the analysis that you need. This is confirmed after the “Bugcheck Analysis” is automatically run, and the message below is displayed.
***** Kernel symbols are WRONG. Please fix symbols to do analysis
Likely causes follow:
- No path/wrong path; a path to the symbol files has not been set or the path is incorrect (look for typos such as a blank white space). Check the Symbol Path (see Setting symbol file path above.)
- Failed connection; check your internet connection to make sure it is working properly.
- Access blocked; a firewall blocked access to the symbol files or the files were damaged during retrieval. See that that no firewall is blocking access to msdl.microsoft.com (it may only be allowing access to www.microsoft.com).
Note that if a firewall initially blocks WinDbg from downloading a symbol table, it can result in a corrupted file. If unblocking the firewall and attempting to download the symbol file again does not work; the file remains damaged. The quickest fix is to close WinDbg, delete the symbols folder (which you most likely set at c:\symbols), and unblock the firewall. Next, reopen WinDbg and a dump file. The debugger will recreate the folder and re-download the symbols. Do not go further with your analysis until this is corrected.
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.