Analyze Minidump Logs with WinDbg in Windows 11

When Windows 11 encounters a Blue Screen of Death (BSOD), it creates a minidump (.dmp) file containing critical memory state details from the moment of the crash. This guide outlines how to use Microsoft WinDbg to load these minidump files, execute the automated crash analysis command, identify the specific third-party driver causing the system failure, and inspect driver details to resolve the issue.


Step 1: Install WinDbg

  1. Open the Microsoft Store in Windows 11.
  2. Search for WinDbg (or WinDbg Preview) published by Microsoft Corporation.
  3. Click Install to download and set up the tool.

Step 2: Locate and Copy the Minidump File

Windows stores crash dump files in system-protected directories.

  1. Open File Explorer and navigate to:

    C:\Windows\Minidump
  2. Identify the most recent .dmp file (named by date and sequence, e.g., 051224-12345-01.dmp).

  3. Copy the .dmp file and paste it into an accessible folder, such as your Desktop or Documents folder. Working directly with files inside the C:\Windows\Minidump directory can cause permission errors in WinDbg.


Step 3: Open the Minidump in WinDbg

  1. Search for WinDbg in the Windows Start menu.
  2. Right-click the app icon and select Run as administrator.
  3. Click File in the top-left menu and select Open dump file (or press Ctrl + D).
  4. Browse to the copied .dmp file on your Desktop and select Open.

Step 4: Run the Automated Analysis

Once the dump file is loaded, WinDbg establishes a connection to the Microsoft Public Symbol Server to match memory addresses with readable debugging symbols.

  1. Look at the command prompt bar at the bottom of the WinDbg window.

  2. Click the blue link in the text window that says !analyze -v, or manually type the following command into the prompt and press Enter:

    !analyze -v
  3. Allow the analysis process to complete. It may take a minute or two while symbols are downloaded.


Step 5: Read the Output to Pinpoint the Faulty Driver

Scroll through the generated bugcheck report to locate the root cause. Focus on these specific fields:

Identifying False Positives

If the IMAGE_NAME points to a core Windows component—such as ntoskrnl.exe, hal.dll, or win32k.sys—the core operating system is usually not the root cause. Instead, a third-party driver likely corrupted system memory, causing the Windows kernel to crash. In this case: 1. Review the STACK_TEXT section in the report. 2. Read the stack from top to bottom to find the last third-party .sys driver called before the crash occurred.


Step 6: Inspect the Problematic Driver

To verify the driver’s provider, version, and compile date, run the loaded module command in the WinDbg command bar:

lmvm <driver_name>

(Replace <driver_name> with the name found in IMAGE_NAME, excluding the .sys extension—for example: lmvm nvlddmkm)

Review the resulting output: * Image path: Shows where the file resides on disk. * Image name: Displays the full filename. * Timestamp: Reveals the age of the driver. Outdated drivers are common sources of incompatibility in Windows 11.


Step 7: Take Corrective Action

Once the faulty .sys file is identified:

  1. Search the driver file name online to confirm the associated hardware (e.g., GPU, Wi-Fi card, Bluetooth adapter, anti-cheat engine, or peripheral).
  2. Open Device Manager in Windows 11, locate the corresponding hardware device, and update the driver to the latest release from the manufacturer’s official support page.
  3. If the crash started occurring immediately after an update, right-click the device in Device Manager, select Properties, go to the Driver tab, and click Roll Back Driver.
  4. If the file belongs to third-party software (such as an antivirus, VPN, or hardware monitoring utility), uninstall or update the software to resolve the conflict.