What WinDbg shows you about a crash

WinDbg is a debugger that reads crash dump files — the snapshots Windows creates when a program stops working. When you open a dump file in WinDbg, it shows you the exact line of code where the crash happened, what was in memory at that moment, and the chain of function calls that led there. This information tells you whether the crash was caused by bad code, a missing file, corrupted memory, or something else entirely.

A crash dump file has a .dmp extension and is usually found in C:\Windows\Minidump on Windows machines, or you can generate one manually if a program is still running. WinDbg reads these files and displays them in a format that shows the problem clearly — but only if you know which commands to run and how to read the output.

Key Takeaways

  • Open a crash dump in WinDbg by going to File > Open Crash Dump, then run the !analyze -v command to get an automatic summary of what went wrong.
  • The faulting module name tells you which program or driver caused the crash; the exception code tells you what type of error it was.
  • The call stack shows the path of function calls that led to the crash, read from bottom to top to understand what the program was doing when it failed.
  • If the crash points to a third-party driver or extension, that is usually the culprit, even if the crash happened inside Windows code.

Opening a dump file and running the automatic analysis

Start WinDbg and go to File > Open Crash Dump. Navigate to your .dmp file — usually in C:\Windows\Minidump — and open it. WinDbg will load the dump and show you some basic information at the bottom of the screen, including the processor architecture and the time the crash occurred.

Type !analyze -v into the command window at the bottom and press Enter. This command tells WinDbg to examine the dump automatically and print a human-readable summary. Wait a few seconds for it to finish. The output will include the exception code (like 0xc0000374 for heap corruption), the faulting module (the program or driver that crashed), and the instruction that failed.

Read the line that says "Faulting module" — this is usually the cause. If it says ntdll.dll or kernel32.dll, the crash happened inside Windows itself, which means a third-party program or driver probably corrupted something. If it names a specific application or driver, that is the most likely culprit.

Understanding exception codes and what they mean

The exception code is a hexadecimal number that describes the type of error. Common codes include:

  • 0xc0000374 — Heap corruption. A program wrote to memory it did not own, breaking the memory manager.
  • 0xc0000005 — Access violation. A program tried to read or write to memory it does not have permission to access.
  • 0xc000007b — Invalid image format. A .dll or .exe file is corrupted or was compiled for a different processor type.
  • 0x80000003 — Breakpoint hit. Usually means a debugger breakpoint was triggered, often by intentional code or a driver.
  • 0xdeadbeef — Driver irql not less or equal. A driver tried to do something it is not allowed to do at the current processor level.

If you see 0xc0000005 (access violation), the crash happened because a program tried to use memory incorrectly. If you see 0xc0000374 (heap corruption), something corrupted the memory heap before the crash actually occurred — the real problem may have happened much earlier. Write down the exception code; it narrows down what went wrong.

Reading the call stack to trace what the program was doing

The call stack is a list of function names showing the path the program took before it crashed. In WinDbg, type k or kb to display it. The stack is read from bottom to top — the bottom function called the one above it, which called the one above that, until the top function crashed.

Look for function names you recognize. If you see a function from your own application, that is where your code failed. If you see only Windows functions or third-party library functions, trace upward until you find something that belongs to the program you are debugging. The function at the very top of the stack is where the crash happened; the functions below it show what called it.

If the stack shows a loop — the same function calling itself over and over — the program probably ran out of stack space or got stuck in infinite recursion. If the stack shows a jump from your code into a third-party .dll, and the crash happens inside that .dll, the third-party code is likely the problem, or your code passed it invalid data.

Finding the exact line of code that failed

If you have the source code and symbol files (.pdb files) for the program that crashed, WinDbg can show you the exact line. Symbol files are debugging information that map memory addresses back to line numbers and variable names. Without them, you only see memory addresses and function names.

To load symbols, go to File > Symbol File Path and add the folder where your .pdb files are stored. Then run !analyze -v again. If symbols load successfully, the output will show the source file name and line number where the crash occurred.

If you do not have symbols, you can still see the assembly code by typing u followed by the address shown in the crash output. This shows the machine instructions that were running, but reading assembly requires more expertise. For most crashes, the faulting module name and exception code are enough to identify the problem.

Checking for third-party drivers and extensions

Third-party drivers and browser extensions are common crash causes because they run at a low level with broad access to system memory. If the automatic analysis points to a Windows file like ntdll.dll or kernel32.dll, look at the call stack to see which driver or extension called into Windows code.

Type lm to list all loaded modules (programs and drivers). Look for anything unfamiliar — antivirus software, graphics drivers, browser extensions, or system utilities. If you recently installed or updated one of these, it is a likely suspect. Disable or uninstall it and see if the crashes stop.

Some crashes are caused by driver conflicts — two drivers trying to use the same memory or hardware resource. If you see multiple third-party drivers in the call stack, try disabling them one at a time to isolate which one is causing the problem.

Common reasons crashes are hard to diagnose

Some crashes leave little information in the dump file. If the crash happened in a driver running at a very low level, the dump may not capture enough context to see what went wrong. If memory was severely corrupted before the crash, the call stack may be unreadable.

Crashes that happen only under specific conditions — like when a certain file is opened or a network connection is made — are harder to reproduce and debug. If you can reproduce the crash, create a new dump file each time and compare them to see what is different. If the crash is random, collect several dumps and look for patterns in which modules or functions appear in each one.

If WinDbg shows "Unable to load image" for a module, that .dll or .exe file may be missing or corrupted. This often points to a broken installation or a file that was deleted or replaced by malware.

Frequently Asked Questions

Where do I find crash dump files on my computer?

Windows stores small crash dumps in C:\Windows\Minidump by default. You can also check C:\Windows\LiveKernelReports for recent kernel crashes. If a program crashes and you want to save the dump, right-click the error dialog and look for an option to save or report the crash — some applications let you choose where to save the dump file.

What if WinDbg says "Unable to load image" for every module?

This usually means symbol files are missing or in the wrong location. Go to File > Symbol File Path and add the folder containing your .pdb files. If you do not have symbol files, you can still see the faulting module name and exception code from the automatic analysis, which is often enough to identify the problem.

Can I tell if a crash was caused by malware?

Malware crashes often show unusual module names or drivers you do not recognize. Look at the list of loaded modules with the lm command and search for anything unfamiliar. If a crash points to a driver or .dll in a temporary folder or with a random name, that is a red flag. Run a full antivirus scan to be sure.

What does it mean if the crash points to a .dll I did not write?

It means that .dll was running when the crash happened, but it may not be the root cause. Look at the call stack to see what called that .dll. If your code called it with invalid data, your code is the problem. If the .dll called itself or called Windows code that failed, the .dll or Windows is the problem.

How do I know if a crash is caused by a driver?

Drivers often appear near the bottom of the call stack. If you see a driver name in the faulting module or in the call stack, and the crash happens inside that driver, the driver is the likely cause. Try disabling or updating the driver. If the crashes stop, the driver was the problem.