How to use the Windows debugger to repair crashes
The WinDbg (Windows Debugger) tool exists and helps users diagnose their BSOD and individual programs have been crashing since the days of Windows 7 and Windows Server 2008 R2. But learning WinDbg requires climbing a learning curve, and it takes a bit of time to figure out how things work. Ditto for learning to control its heavy command interface. However, Microsoft has come up with an alternative UWP-based version that is more automated and much, much easier to learn and use.
UWP WinDbg will help you with all the different types of dump files that Windows creates to capture error information, and it makes viewing and reviewing their content simple and straightforward. Before explaining where and how to get WinDbg Preview, let me explain a bit more about what it does, starting with the dump files.
An Anatomy of Core Dump File Types
You can read more about this topic in the MS Docs item “Overview of Core Dump File Options for Windows. According to this reference, Windows can create any of these types of core dump files when a causing error occurs (cited verbatim):
- Complete memory dump: Captures the entire contents of system memory when a Stop error (BSOD) occurs. It includes data from processes that were running when the dump was collected. To use the full memory dump option, your paging file must be configured on the boot volume to be 1MB larger than the physical RAM installed (on my PC, for example, with 16GB or 16384MB, which means 16,385 MB). I rarely bother with this type of dump file because it takes up a lot of space on the boot / system drive, and my desktop doesn’t do as much paging activity anyway. The conventional wisdom is that you can configure this if you need a full core dump if Microsoft or a third-party vendor asks you to. Otherwise, they consume too much space.
- Dump kernel memory: Records only kernel memory, which is memory allocated to the operating system kernel and hardware abstraction layer (HAL), as well as kernel-mode drivers and other kernel-mode programs. As MS itself says, “this dump file is the most useful.”
- Small memory dump (64 KB): captures minimal information about an error. For stop errors, for example, it retrieves the stop message along with its associated parameters and data. It also retrieves a list of loaded drivers, processor content block for the processor that stopped, kernel information and context for both the stopped process (EPROCESS) and the stopped execution thread (ETHREAD). ). Finally, it also recovers the kernel-mode call stack for the thread that has terminated. By default, small memory dump files reside in the% SystemRoot% Minidump folder.
- Automatic memory emptying: contains the same information as a kernel core dump, but is created when Windows manages the size of the paging file (i.e. the paging file is set to the size managed by the system) . Windows can control the size of the paging file if a crash occurs and the paging file cannot capture all of the information needed to get a full snapshot of the kernel memory dump. See this Docs item for more details: Automatic memory clearing.
The 10,000 foot view of what WinDbg and WinDbg Preview do is to open Windows files that end with the dumpfile .dmp extension. Both tools will allow you to explore these files in depth. WinDbg Preview is preferable because it makes the exploration work much easier. But first, here’s how to grab and install a copy of WinDbg Preview.
Download and install WinDbg Preview
Like most UWP programs, WinDbg Preview is available in the Windows Store. So you can search for “WinDbg Preview” in the store, or just follow this connect. Either way, you will see the following information appear in the Windows Store on your PC as shown below.
To download the program, click the Download button. Once the download is complete, an Install button will appear. Click the Install button to install it on your PC. Once this happens, you can launch the program through the Start menu by typing “WinDbg Preview”. This brings up the information displayed in the intro graphic for that story. Click on this icon and the program will load.
Finding .DMP Files on Your PC
You might be surprised at how many .dmp files reside on your Windows 10 or 11 PC. You can use Explorer to scan them for you. I prefer Void Tools All, a free and very fast file indexing and search tool.
When I used Voidtools Everything, the app instantly came up with 82 such files on my C: drive; it took Explorer almost 3 minutes to come up with the same list. Once you have such a list, you can prepare to plug a specific .dmp file into WinDbg Preview by right-clicking on a filename while holding the Left Shift key. This adds the “Copy as path” line to the context menu, which you want to do so that you can tell WinDbg Preview exactly where to find the .dmp file you want to take a closer look at.
For the purposes of this story, I chose a File Explorer dump file out of curiosity. I chose the file named explorer.exe.9736.dmp with a full path specification of “C: ProgramData Norton LocalDumps explorer.exe.9736.dmp” (the quotes are automatically included when you make the selection from the Copy as path contextual menu).
Plug in a DMP file in WinDbg Preview
Open the program and you will see a generic layout appear.
So far there is really nothing to see or do as of yet. Then click on the File menu at the top left (already highlighted in blue). This produces the file option menus, as shown below. Here you will select the item that reads “Open Dump File” (fourth from the top, under the Start Debugging heading).
If you entered the full path specification as I explained in the previous section, you can paste it into the File name box and it will take you there. If so, remove the quotation marks (“) at the beginning and end of the string, as shown. Or, you can browse to a dump file of your choice. Choose such a file and it will appear in the File name field. :.
Click the Open button and WinDbg Preview will load the file and all the supported DLL and symbol files it needs to make sense of its contents. It may take a while, around 1 to 2 minutes. Then a display like the one shown below appears. This is where the magic happens, where you have to click on the link in the center of the middle pane titled! Analyze -v. (Note: I had used the old WinDbg tool and tried entering the command myself manually, but it didn’t work. The link, however, works fine. Click on it!)
The scanning process also takes some time and will show countless progress bars as the program loads and links to various symbol tables (pdb files), dll, etc. Once it’s done, you see the text results in the middle pane and a list of related discussion threads in the lower right pane.
Decoding Exception Analysis
The text at the top of the center pane contains a line that says “This dump file contains an exception of interest.” This is your clue that the analysis might reveal something interesting. Once you click on the! Analyze v option, the program will perform an analysis and write its results to this same central pane.
I will now reproduce a key section of this central pane to illustrate what WinDbg Preview has found. It occurs in the EXCEPTION RECORD information for the explorer.exe process.
This information tells us that Explorer.exe attempted to access an invalid or inaccessible memory location. So, we are looking at some kind of programming or data access error in the application itself. This does not indicate any user or system caused issues so all one can do is accept the error and hope MS will manage to fix what caused it.
Note: When you are finished using WinDbg Preview, click File, then click Exit. If you don’t exit the program, you will pick up where you left off the next time you open it. Good Housekeeping!
Mozilla / Firefox crash report
Next, I loaded a file from the Firefox “Crash Reports” folder to see what it might tell me. It’s more or less certain to include information about a Firefox problem. This time, the initial inspection reports that “The dump file contains a breakpoint exception.
The! Analyze -v function has little to say about it. Likewise to click on the exception record itself (! .Exr -1). Lesson learned here: Not all .dmp files have useful things to tell PC users. This is only sensitive to Firefox developers. I wonder why, however, a production browser contains functional breakpoints.
Partition Assistant DMP File
I found a mysterious .dmp file at the root level of my C: drive, named pw10-debug.dmp. As soon as I opened it and ran the scan I saw partitionwizard.exe appear as the failing process. It shows almost identical memory access error as explorer.exe earlier. Very useful in showing me that this is old news, and something that I no longer need to carry with me.
Do your own explorations
Once you’ve run WinDbg Preview on your PC, you can point it to any .dmp files you might find. This should at least allow you to determine where a .dmp file came from and whether or not there is cause for concern. WinDbg Preview has just been promoted to the top of my list of error scanning tools. Count on me to start including information gleaned from the tool in my upcoming and ongoing BSOD story series. Stay tuned!