memory dump showing incomplete stack after BSOD

Question

memory dump showing incomplete stack after BSOD

Aisyah 25

can anyone please help with this!! one user PC just BSOD-ed, but the memory dump isn't showing which exact driver caused the crash, just generic kernel stuff. Do you reckon the dump setting is just set to pagefile too small, or a driver corrupted the memory pool earlier before it actually crashed? Thanks ah!

0 comments

2 answers

Your answer

Answer 1

Hi Aisyah,

If the dump only shows generic kernel components, it doesn't necessarily mean the dump configuration is incorrect. A driver may have corrupted memory earlier, making it difficult to identify the actual culprit at the time of the crash.

I'd first check the dump configuration under System Properties > Advanced > Startup and Recovery and ensure the pagefile on the OS drive is large enough for the selected dump type. Then, analyze the dump using WinDbg with !analyze -v, !pool, and !verifier where applicable.

If pool corruption is suspected, enable Driver Verifier selectively for non-Microsoft drivers using verifier.exe, but be careful on production machines as it can trigger additional BSODs. Also, check Event Viewer for recurring driver or hardware errors around the crash time.

Hope this helps narrow down the root cause!
Harry P.

Answer 2

A generic kernel-only stack does not by itself prove that the page file was too small or that a driver corrupted memory earlier; first verify that the dump completed successfully and that WinDbg loaded matching symbols.

1. Determine whether the dump is incomplete

In WinDbg, open the dump and run:

.symfix
.reload /f
!analyze -v
.bugcheck
lml

WinDbg normally starts crash analysis with !analyze; .bugcheck displays the stop code and parameters, while lml shows loaded modules and their symbol status.^1^

Check the output for:

Symbol warnings or unloaded/mismatched symbols. Incorrect symbols can produce missing functions or an apparently wrong stack. If present, correct the symbol path and reload before interpreting the stack.^2^
Dump type and completion attributes. A small or kernel-generated triage dump naturally contains less context than a kernel or complete dump. A line such as Dump completed successfully indicates that capture completed; it does not guarantee that the responsible driver remains identifiable.
Event Viewer → Windows Logs → System → Event ID 1001, source BugCheck. This records the bug-check parameters and the path of the saved dump.^3^

If symbols are valid, the dump completed, and !analyze -v still points only to ntkrnlmp.exe, nt!KeBugCheckEx, or another generic kernel routine, do not treat that routine as the faulty component. It may simply be where Windows detected the invalid state.

2. Check dump and page-file configuration

A page file that is too small normally prevents Windows from producing the selected dump type; it does not ordinarily explain a successfully completed dump whose stack lacks the original corruptor.

Check:

HKLM\SYSTEM\CurrentControlSet\Control\CrashControl

For an endpoint where another crash can be collected:

Up to 32 GB RAM: Microsoft recommends a complete dump, CrashDumpEnabled=1, with a boot-volume page file sized to RAM + 300 MB.
Over 32 GB RAM: use an automatic dump, CrashDumpEnabled=7, and a system-managed page file.
Ensure enough free space exists for both the page file and Memory.dmp.^4^

Windows writes crash data through the page file or a dedicated dump file. A complete dump requires approximately RAM + 257 MB; kernel and automatic dump requirements depend on kernel virtual-memory use.^5^

Changing this configuration improves the next capture; it cannot add missing data to the existing dump.

3. If crashes recur, test for earlier driver corruption

Delayed corruption is plausible because a driver error can occur well before Windows detects it. Driver Verifier’s Special Pool is designed to detect use-after-free and buffer overrun/underrun errors closer to the offending operation.^6^

Driver Verifier can intentionally crash or prevent startup, so create a restore point and use it only during a controlled maintenance window. Prefer suspected third-party .sys drivers rather than every driver; Special Pool is more effective when focused on one driver at a time.^7^

From an elevated Command Prompt:

verifier /standard /driver SuspectedDriver.sys
verifier /querysettings

Restart, reproduce the workload, and collect the new dump. Then disable Verifier:

verifier /reset

If Windows cannot boot, enter Windows Recovery Environment, start Safe Mode or Command Prompt, run verifier /reset, and restart. The reset command clears current Driver Verifier settings.^8^

A Verifier-triggered dump such as Special Pool corruption or access to freed Special Pool is much more likely to identify the driver at the point of misuse.

If this was a single occurrence, preserve the dump and monitor. If recurring, compare all dumps for a common stop code, third-party module, device stack, or driver/update installed shortly before the first crash.

References