Content

• To step
• Method 1 of 2: Using BlueScreenView
• Method 2 of 2: With WinDBG

When a Windows application crashes or stops unexpectedly, a "crash dump file" is generated to store system information from just before the failure. Reading small memory dump files can help resolve the cause of the error. With the freeware program "BlueScreenView" you can quickly learn what went wrong, or use the Windows Debugger tools for more detailed information.

To step

Method 1 of 2: Using BlueScreenView

1. Use BlueScreenView if you only want to see what caused the crash. Most users only need crash dump files to determine what could be the cause of a system crash or BSoD (Blue Screen of Death). BlueScreenView is a freeware program from NirSoft that analyzes dump files and can tell you which driver or other factor caused the crash.
   • The dumps created during a system crash are called "minidumps".
2. Download BlueScreenView. You can download BlueScreenView directly from NirSoft at nirsoft.net/utils/blue_screen_view.html.
   • You can download the program as a standalone version (delivered in ZIP format). This allows you to run it without installation. Once you have finished downloading the ZIP file, right click and select "Extract" to create a new folder with BlueScreenView.
3. Start BlueScreenView. After extracting BlueScreenView from the ZIP file, run the program. You will receive a notification from Windows asking if you want to continue.
4. Find the crash dump file you want to analyze. When your computer crashes, a file called "minidump" is created in the Windows directory. These files have the extension "dmp" and BlueScreenView can read them and tell you what happened. Minidump files can be found in C: Windows Minidump. If you don't see the files, you may need to make hidden files visible:
   • In Windows 10 and 8, click the "View" tab in Windows Explorer and check the "Hidden items" check box.
   • In Windows 7 and earlier, open Folder Options in Control Panel, then click the "View" tab and select "Show hidden files, folders, and drives".
5. Drag it dmp file in the BlueScreenView window. The fastest way to open .dmp files is to drag and drop them into the BlueScreenView window. The file will not be moved from its original location. The bottom half of the BlueScreenView window will be filled with data after dragging the file into the window.
6. Go to the column "Caused By Driver" in the top section. You may need to scroll slightly to the right to see it. This column shows which driver caused the system crash.
   • It may also be the case that the problematic driver is highlighted in red in the lower part of the window. Double-click this highlighted item for more details, such as the product name, description, and file path.
7. Use this information to find the problem. Now that you know which driver caused the crash, you can start troubleshooting. Start with an online investigation of "driver name" and "crash" to see if others have experienced the same problem.

Method 2 of 2: With WinDBG

1. Use this method for a more advanced analysis. Most users do not need to use the Windows Debugger program to open MEMORY.DMP files and examine code dumped from memory due to a crash. If you want more information about how Windows uses drivers and memory, or if you need to analyze dump files for software development, Windows Debugger can provide you with a lot of information.
2. Download the Windows Software Development Kit (WDK). This program contains the WinDBG program that you use to open the dump files. You can download the WDK installer here.
3. Double click on sdksetup.exe. This will start the installer. Go through the first few screens, leaving the defaults untouched.
4. Deselect everything except "Debugging Tools for Windows". You can deselect all other options as they are not used for opening dump files. Deselecting it will speed up the installation and save space on your hard drive.
5. Wait while the files are downloaded and installed. This may take several minutes.
6. Open the command window as an administrator. You need to open the command window as administrator to associate dmp files with WinDBG so that the program can analyze them. Open the command window in the "system32" folder.
   • Windows 10 and 8 - Right-click the Windows button and select "Command Promt (Admin)".
   • Windows 7 - Open the Start menu and type cmd. Press Ctrl+⇧ Shift+↵ Enter.
7. Go to the directory of the debugger. Run the following command to change to the correct directory. If you are using Windows 10, you can just copy and paste. With earlier versions you will have to type the command:
   • cd Program Files (x86) Windows Kits 8.1 Debuggers x64
8. Enter the command to mount the dump files. Type the following command to associate WinDBG with DMP files. Windows 10 users can copy and paste this command:
   • windbg.exe -IA
   • If you entered the command correctly, an empty WinDBG window will appear that you can close.
9. Start WinDBG. You will need to configure WinDBG to load the correct files so that the Microsoft dmp files can be opened. You do this within WinDBG.
   • The fastest way to start the program is to press ⊞ Win and type "windbg".
10. Click on "File" and select "Symbol File Path ". A new window will open.
11. Copy and paste the following address. This path will tell WinDBG to download and store the necessary symbols directly from Microsoft in C: SymCache:
    • SRV * C: SymCache * http: //msdl.microsoft.com/download/symbols
    • The map C: SymCache will grow over time as you open more debug files and download additional symbols from Microsoft.
12. Find the crash dump file you want to analyze. Dump files (.dmp) are generated when your system crashes. By default you would put the dump file in the directory C: Windows Minidump after a crash recovery. The file can also be in C: Windows MEMORY. DMP stand. If you can't find the files, you may need to unhide hidden files:
    • In Windows 10 and 8, click the "View" tab in Windows Explorer and check the "Hidden items" check box.
    • In Windows 7 and earlier, open Folder Options in Control Panel, then click the "View" tab and select "Show hidden files, folders, and drives.
13. Double-click the dump file. As long as WinDBG is properly configured, WinDBG should start and begin processing the file.
14. Wait while the dump file is loaded. The first time you open a dump file, you have to wait while the symbols are downloaded from Microsoft. Do not interrupt the WinDBG program while loading the file.
    • The crash dump file will load much faster next time, since you already have the symbols in the folder C: SymCache have standing.
    • You will know the dump file has finished loading when your Followup: MachineOwner at the bottom of the file.
15. Look for the line "Probably caused by". This is the fastest way to get an idea of ​​the cause of the crash. WinDBG will analyze the dump file and report which process or driver is likely to cause the problem. You can use this information for further troubleshooting and research.
16. Find the BugCheck codes. The dump file will return codes for specific errors that occurred during the crash. Look directly above the line "Probably caused by". You will likely see a two-character code, such as "9F".
    • Go to the Microsoft Bug Check Code Reference. Find the code that matches your BugCode by looking at the last two characters in each entry.