How can I investigate a kernel memory dump when the analysis identifies an unknown driver as the possible cause of a crash?

Question

How can I investigate a kernel memory dump when the analysis identifies an unknown driver as the possible cause of a crash?

Lewis Hilton 0

0 comments

2 answers

Your answer

Answer 1

Use WinDbg to move beyond the initial “probably caused by” result and inspect the dump directly.

Open the kernel dump in WinDbg.
- Command line:
```
     windbg -y <SymbolPath> -i <ImagePath> -z <DumpFileName>
```
- Or in WinDbg, use File > Open Crash Dump.
- If the dump is a kernel memory dump, the default file location is %SystemRoot%\Memory.dmp.
Run automatic analysis first.
- Start with:
```
     !analyze
```
- Verbose analysis is also useful:
```
     !analyze -v
```
This often gives the bug check details, stack trace, and a first indication of the suspected component.
Check the bug check code and parameters.
- Run:
```
     .bugcheck
```
This shows the stop code and its parameters so the failure can be matched to the bug check reference.
Inspect loaded modules to identify the unknown driver.
- Run:
```
     lm
```
This lists loaded modules and helps correlate addresses or suspicious module names with the crash context.
Examine process context if needed.
- Run:
```
     !process 0 0
     !process 0 7
```
These commands help determine what process context was active when the crash occurred.
Check memory and system state if the cause is still unclear. Useful extensions include:
- !memusage
- !vm
- !errlog
- !kdext*.locks
If the dump is a kernel memory dump, account for missing user-mode images.
- Kernel dumps do not include user-mode application memory or user-mode executable images.
- If those executables matter to the investigation, set the executable image path.
- To suppress missing page errors while debugging a kernel memory dump, use:
```
     .ignore_missing_pages
```
If the suspected driver remains unknown, gather better evidence with Driver Verifier.
- Driver Verifier is built into Windows and can be started by entering Verifier at a command prompt.
- Verify the smallest number of drivers possible, because Driver Verifier adds overhead.
- This is useful because many stop code errors are caused by faulty drivers, and Driver Verifier can force exceptions that make the offending driver easier to identify.
Record the exact stop code text and the actions that reproduce the crash.
- For recurring crashes, capture the exact bug check text and note the steps leading to the failure. That makes it easier to correlate the dump analysis with the triggering scenario.

If the initial analysis names an unknown driver, the practical path is: open the dump, run !analyze -v, confirm the stop code with .bugcheck, inspect modules with lm, review process and memory state, and then use Driver Verifier on a small set of suspect drivers to force a more conclusive crash signature.

Answer 2

Hello Lewis,

I'd recommend starting with WinDbg and running !analyze -v to identify the bugcheck code, suspected module, and failure context. Don't assume the driver named in the stack is necessarily the root cause, as memory corruption can sometimes make an unrelated driver appear responsible.

You can use lmvm <drivername> to inspect the driver's timestamp, version, and image path, then verify its digital signature and provider using PowerShell or Device Manager. Also, check the System event log for related driver or hardware errors around the time of the crash.

If the driver cannot be identified, please share the bugcheck code, the MODULE_NAME and IMAGE_NAME fields, and the relevant !analyze -v output. These details will help narrow down whether we're dealing with a third-party driver, a corrupted driver image, or a deeper memory corruption issue.

Best regards,

Xuan Nhu.