Skip to content
littleden.blogEvidence-led Windows troubleshooting, without the guesswork
FixesError codesComponentsCommandsWindows updatesWindows 11
Research statusMethodology
Diagnostics & reliability · reviewed troubleshooting

No memory dump after a Windows blue screen: verify capture settings before blaming the crash

A missing MEMORY.DMP or Minidump can reflect dump configuration, paging-file requirements, disk space or an incomplete write—not proof that no bugcheck occurred.

Applies to: Windows 11 / supported Windows clientChange risk: Low to mediumReviewed: 2026-09-17
Do this first
  1. Confirm whether the incident was a real bugcheck by checking the stop code and matching Event ID 1001 when available.
  2. Check both C:\Windows\Minidump and C:\Windows\MEMORY.DMP.
  3. Open Startup and Recovery and record the selected Write debugging information type.
  4. Check that the OS volume has adequate free space and that paging-file configuration has not been disabled or moved in a way that prevents the chosen dump type.

What this problem usually means

Microsoft documents that Windows dump capture depends on the configured debugging-information type and paging-file/storage requirements. Small dumps normally use the Minidump folder, while kernel/automatic/complete dumps commonly use MEMORY.DMP. Automatic and larger dump types rely on suitable paging-file and disk conditions.

Diagnostic state

What is known, and what is not proven yet

Keep observation, evidence and conclusion separate before making a higher-impact change.

Observed fact

A real bugcheck/restart occurred but the expected crash dump is missing.

Windows evidence

Stop code, Event ID 1001, Startup and Recovery settings, CrashControl values, page-file placement and disk space.

Likely subsystem

Crash-capture configuration/storage path rather than the original crash cause.

Evidence still needed

Proof that a bugcheck occurred and the chosen dump type had the resources required to write.

Safe next action

Correct capture prerequisites first, then wait for the next natural/reproducible crash.

Handoff boundary

Microsoft/OEM/IT debugging support if configured capture repeatedly fails.

Ordered repair path

Work from the narrowest fix to the broader one.

1

Verify the configured dump type and destination

Low risk

Why this belongs here: Looking only for MEMORY.DMP can miss a system configured for small dumps, while selecting none prevents crash-dump output.

  1. Open Advanced system settings > Startup and Recovery > Settings.
  2. Record the Write debugging information selection and dump path.
  3. If Small memory dump is selected, use the Minidump directory; for kernel/automatic/complete dump types, verify the configured dump file path.
2

Verify paging-file and free-space requirements

Medium risk

Why this belongs here: Microsoft notes that system crash dump capture depends on a suitable paging file on the boot/OS volume and enough storage for the resulting file.

  1. Prefer a system-managed paging file unless a documented support procedure requires another configuration.
  2. Confirm adequate free space exists for the page file and dump.
  3. Restart after changing dump/page-file settings before judging the next crash.
3

Preserve the next crash and correlate it with Event ID 1001

Low risk

Why this belongs here: The next incident should be matched to its stop code and dump timestamp instead of mixing evidence from different crashes.

  1. After a new stop error, note the stop code and time.
  2. Check Event Viewer for WER-SystemErrorReporting Event ID 1001.
  3. Match the event to the newest dump file and preserve both for analysis.
Stop condition

When this guide stops being the right path

Do not deliberately force a crash on a normal production PC simply to test dump capture unless a controlled support procedure requires it. Registry edits to CrashControl should not be the first step when the GUI settings are sufficient.

If the problem is still not fixed

If dump capture remains absent after a real repeatable bugcheck with supported configuration, move to Microsoft, OEM or experienced debugging support with the event timeline and current CrashControl/page-file settings.

Evidence

Sources reviewed for this page

Primary technical guidance is preferred. A source supports the scope stated here; it does not imply that every possible cause is covered.

Related authority records

Continue with the same failing system

These links share the same component or repair context; they are not generic keyword suggestions.

GuideFind Windows crash dump files: Minidump vs MEMORY.DMP and what each tells you

Locate the dump that matches a Windows stop error and verify dump configuration before assuming Windows failed to capture the crash.

CommandPowerShell — read CrashControl settings

Read the main Windows crash-dump configuration values without changing them, useful when a real bugcheck is not producing the expected dump file.

CommandWindows Memory Diagnostic

Schedule the built-in Windows memory test, which restarts the PC and tests system memory before Windows loads normally again.

GuideWindows Memory Diagnostic: when to run it and how to read the result

Use the built-in memory test when repeated stop errors or instability make RAM plausible, then read the recorded result instead of assuming a clean test proves all hardware is healthy.

ErrorEvent ID 1001 — WER-SystemErrorReporting bugcheck: preserve the stop code and dump path

When Event ID 1001 says the computer rebooted from a bugcheck, the useful evidence is the exact bugcheck code, parameters and saved dump.

GuideCapture a user-mode app dump with Task Manager in Windows 11

Preserve a crashing or hung application state for vendor or debugger analysis without crashing the whole PC.