求助：如何解读Windows Minidump文件及dumpchk.exe输出内容

Got it, let's walk through how to turn that raw dumpchk output into clear, actionable info for your app—plus cover that NirSoft tool you mentioned.

1. 先抓最核心的错误标识：Bugcheck Code #

From your sample output, the line Bugcheck code 0000009F is the goldmine. Each Bugcheck code maps to a specific Windows kernel error, which you can translate directly into user-friendly language:

• 0x9F: This is DRIVER_POWER_STATE_FAILURE—it almost always means a driver got stuck during a power state change (like waking from sleep or hibernation).
• Other common codes to memorize:
  • 0x1E → MEMORY_MANAGEMENT: Issues with system memory (could be faulty RAM or bad driver interactions)
  • 0x3B → SYSTEM_SERVICE_EXCEPTION: A system-level service crashed, often tied to recent updates or software installs
  • 0x7E → SYSTEM_THREAD_EXCEPTION_NOT_HANDLED: A system thread threw an uncaught exception, usually from a misbehaving driver

The Arguments that follow the code add context. For 0x9F specifically:

• First argument (0x0 in your sample): Indicates the failure type—here, it means the driver was in an invalid power state
• You don’t need to expose raw hex values to users; instead, frame it as "The crash happened during a power management operation"

2. Fix the Symbol Path to Get Real Context #

The line Symbol search path is: Invalid is a critical warning. Without symbols, dumpchk can only show you raw memory addresses—not the actual driver or process that caused the crash. Here’s how to fix that:

• First, set the symbol path in your command prompt (replace C:\Symbols with a folder on your system):

  set _NT_SYMBOL_PATH=srv*C:\Symbols*https://msdl.microsoft.com/download/symbols
  

• Re-run your dumpchk command:

  dumpchk C:\Windows\Minidump\DumpFile.dmp | clip
  

• Now the output will include specific filenames (like ntoskrnl.exe or a third-party driver mydriver.sys), which are the actual culprits you can flag to users.

3. Translate to App-Friendly Content #

Build a simple lookup table in your app to map Bugcheck codes to plain-language explanations. For example:

• 0x9F → "A driver failed to respond during a power state change (e.g., waking from sleep). Check recently installed hardware drivers (like graphics or network adapters) for updates."
• If symbols are loaded and you have a driver name: "The crash was caused by the driver mydriver.sys. Try updating this driver or uninstalling the associated hardware/software."

4. Using NirSoft’s BlueScreenView #

You’re right—this tool is a huge time-saver. It automates the entire Minidump parsing process and presents:

• Exact crash timestamp
• Bugcheck code and human-readable description
• A list of drivers running at crash time (with the likely faulty driver highlighted)
• Simplified call stack info

If your app doesn’t need to parse dumps programmatically, you can guide users to this tool for quick self-diagnosis. If you do need programmatic parsing, you can replicate its core logic (pull Bugcheck code, resolve symbols to driver names) using Windows Debugger APIs or open-source parsing libraries.

Pro Tip #

Minidumps are lightweight and only contain core crash data. For deeper dives (like analyzing process memory or thread states), you’d need a full memory dump and WinDbg—but for most app use cases, dumpchk with symbols is more than enough to identify common crashes.

内容的提问来源于stack exchange，提问作者Leo