Windows 10: Install and Configure WinDBG for BSOD Analysis

How to: Install and Configure WinDBG for BSOD Analysis

How to Install and Configure WinDBG for BSOD Analysis


Information WinDBG (Windows DeBuGger) is a Microsoft software tool that is needed to load and analyse the .dmp files that are created when a system BSOD's. The latest version of WinDBG allows debugging of Windows 10, Windows 8.x, Windows 7, and Windows Vista.

This tutorial will show you how to download, install, configure and test WinDBG in preparation for analysing BSOD's.



Note WinDBG requires .NET Framework 4.6 in order to run. If it's not installed, download it from this location, and install it before downloading and installing WinDBG.

Dumps from C:\Windows and C:\Windows\Minidump cannot be opened unless you move them to another location first.




Step 1 [/i] Downloading and Installing WinDBG
1. Download the WinDBG sdksetup.exe setup file.

2. Run sdksetup.exe, and specify the installation location (this example uses the default location):





3. Once you have accepted the licence agreement, you will be prompted to select the features to install. Select only the Debugging Tools for Windows option, as shown. Proceed with installation.




4. The debugging tools will be downloaded and installed.








Step 2 [/i] Associate .dmp files with WinDBG
If configured correctly, Windows will write information to a .dmp file when the host system BSOD's. In order to read the information within the .dmp file, it needs to be associated with WinDBG.

1. Open an elevated command prompt by right-clicking on the Windows Start Button and selecting Command Prompt (Admin).



2. Copy the highlighted text below, and paste it into the command prompt window using Ctrl+V and hit enter to change directory to the installation location path.

cd\Program Files (x86)\Windows Kits\10\Debuggers\x64\
3. Now copy this highlighted text, paste it into the command prompt window, and hit enter to make the association.

windbg.exe -IA
4. This is how it looks when executed in the command prompt window.




If done correctly, a new blank instance of WinDBG will open with a confirmation box. WinDBG can now be closed.






Step 3 [/i] Configuring the WinDBG Symbol Path
The symbol path is the location in which WinDBG searches for symbols each time it reads a binary in the BSOD .dmp file. It is critical to get this step correct.

You can specify any location to create a cache/store of downloaded symbols, but I recommend using the default location (as used in this tutorial).

To create and set a symbol path, do the following.

1. Start a blank instance of WinDBG by going to:Start > All apps > Windows Kits > WinDbg (x64)
2. In the WinDBG panel, go to:File > Symbol File Path3. Copy the highlighted text below and paste it into the Symbol Search Path box, and click OK - there is no confirmation.

SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols




What that line means is :

• Create a folder called C:\SymCache
• Download new symbols from the msdl site and save them to C:\SymCache

You can specify any path you like, for example SRV*E:\My_Symbols*http://msdl.microsoft.com/download/symbols will also work.

4. Save the symbol path by going to:File > Save WorkSpace5. Close WinDBG.




Step 4 [/i] Testing the WinDBG Installation
1. Download this small zip file.
test.zip
2. Open it, and double click the .dmp file.

3 WinDBG should open automatically and you should see some text appearing in the workspace. Since this is the first .dmp file being read on your system, WinDBG appears to be slow do not interrupt it. What is happening is:

• A folder called Symcache is being created on C:
• Symbols are being downloaded and saved to C:\Symcache

The next time a .dmp is opened, it will be quicker since it already has some symbols. Over time the C:\Symcache folder will grow in size as more symbols are added. My current Symcache folder is 1.07GB in size.

You will know the reading of the .dmp file is complete when our output looks like this. Note the breakpoint that I have highlighted in bold text red - that means the .dmp file has been completely read.

Code:

To close WinDBG go to File > Exit

You are done. WinDBG has been installed, .dmp file associations created, and symbol path correctly setup.


Related Tutorials

• Basic WinDBG methods for debugging crash dumps in Windows 10

:)

 

BSOD - tcpip.sys failure - anybody smart enough to figure this out???

BugCheck D1, {3c, 2, 1, fffff80c51947705}

*** ERROR: Module load completed but symbols could not be loaded for FortiFilter.sys

*** ERROR: Module load completed but symbols could not be loaded for ipeaklwf.sys

Probably caused by : FortiFilter.sys ( FortiFilter+1ceb )

I think the BSOD issues is resolved.

Here is some article how to configure and analyze with the WinDBG

Install and Configure WinDBG for BSOD Analysis Windows 10 BSOD Tutorials

WinDBG - The Basics for Debugging Crash Dumps in Windows 10 Windows 10 BSOD Tutorials

Regards.

 

BSOD DRIVER_OVERRAN_STACK_BUFFER

The preferable tool to analyze a dump file is WinDbg (Windows Debugger):

Install and Configure WinDBG for BSOD Analysis

The minidump file you provided was Driver Verifier initiated.

Did you enable the Driver Verifier and, if so, why?

 

That's part of the test Doug, you passed. *Smile

 

*Cool Thanks Derek

 

I'm getting this error when trying to view a Windows 10 crash dump file:

Failure when opening dump file <path>, NTSTATUS 0xC000011E
It may be corrupt or in a format not understood by the debugger.

An attempt was made to map a file of size zero with the maximum size
specified as zero.

Currently researching, hoping I didn't miss anything.

 

Sounds like a zero byte dump file, (Corrupt) what size is it listed as?

Normally they run about 25-35 KB.

 

Ah, I overlooked that! Several are 0 bytes. *Sad

I finally found a recent one clocked in at 276 KB in size. This time I got a different error:
WinDbg: 10.0.10240.9 AMD64
Could not find the <path> Dump File, Win32 error 0n87

The parameter is incorrect.

I am using the Windows 10 WinDbg kit as well (used 8.1 earlier). I was also able to view the sample dump file in above instructions just fine, so it can't be a bad install/setup I assume.

I'm probably going to end up backing up files and doing a system reset instead of fighting with it. Probably malware. Of course it irks me not being able to see if there really is anything of worth in the generated Windows dump files. Thanks!

 

Zip that one up and attach it in your next post. Let's see if I get the same error.

Since you are in this tutorial I assume you followed all the steps to set associations?

 

110115-26921-01.zip

Correct, I set the association in Step 2. Would be interesting to see if you can check it out.

 

It's corrupt, I get the same thing,

 

My apologies for wasting your time. I chalk it up to this Windows 10 PC simply being that far gone and corrupt. Could I have done anything else to grab better dump files?

I'm doing a reset as I type this out on another PC tonight, already feeling exhausted and have to work tomorrow. *Cool

 

No problem, you didn't waste my time. *Smile

They are just getting corrupted somewhere, it happens.

 

Update:

WDK, HLK, ADK downloads - Windows 10 Hardware Dev Center

 

Ok just installed the kit onto my 10 machine but it will not open that test BSOD file. What now??