The machine bluescreened and there is no dump file: Windows Error Reporting, dump types, and the settings that quietly threw your evidence away

A laptop blue screens in the middle of a client call. The user reboots, gets back to work, and raises a ticket. You remote on twenty minutes later, open C:\Windows\MEMORY.DMP, and the file is not there. The Minidump folder is empty too. The one artefact that would have named the guilty driver in about ninety seconds never survived, and you are left guessing from a stop code the user half-remembers.

This is not a rare failure. On a default Windows 11 device, a memory dump has to clear five independent hurdles before you get to read it. Any one of them quietly loses the evidence, and Windows does not go out of its way to tell you which one. This post walks the whole chain, from the bug check to the file on disk, and shows you how to configure a fleet so the next crash is diagnosable.

The problem: the machine crashed and the evidence is gone

Let us define the words first, because two of them get mixed up constantly.

A bug check is what Microsoft calls a kernel-mode crash. You know it as the blue screen, or a Stop error. When it happens, the kernel stops scheduling anything else and tries to write the contents of memory to disk before the machine restarts.

A memory dump is the file that write produces. It is a snapshot of memory at the instant of the crash. Loaded into a debugger, it will normally tell you which driver was on the stack when things went wrong. Without it you have a stop code and a shrug.

A Windows Error Reporting (WER) report is a different thing again. It is a small folder of metadata and log files that Windows queues up to send to Microsoft. It is not a memory dump, though it can contain one.

The failure mode this post is about looks like this. The device restarts. Somebody notices. You go looking, and one of the following is true:

• C:\Windows\MEMORY.DMP does not exist, and C:\Windows\Minidump is empty.
• A dump existed yesterday and is gone today.
• The System log has a bug check entry that says a dump was not saved.
• An application crashed repeatedly and there is no .dmp for it anywhere.

Why it happens: five hurdles between the bug check and the file

Here is the chain, in order, from the moment a driver faults to the moment you have a file to open.

1. ntoskrnl.exe, the Windows kernel, detects an unrecoverable fault and raises a bug check.
2. The kernel reads its crash settings, which were cached at boot from HKLM\SYSTEM\CurrentControlSet\Control\CrashControl.
3. The crash dump write path takes over, filtered through any dump filter drivers listed in the DumpFilters value - on a BitLocker-encrypted device that includes dumpfve.sys, which encrypts the dump as it is written.
4. Memory is written into the backing store: the page file on the boot volume, or the file named by DedicatedDumpFile.
5. The machine restarts. Early in the next boot, Windows converts the raw data into the file named by DumpFile, and writes a minidump copy into the folder named by MinidumpDir.
6. WerFault.exe raises a report, and the System event log gets a bug check event.
7. A retention decision is made. If it goes against you, the dump you just created is deleted.

Every numbered step above can fail independently. Let us take the five that actually bite.

Hurdle one: the dump type

Microsoft documents five kinds of kernel dump. They differ in what memory they capture, which decides both how big the file is and what questions it can answer.

All five are selected by one REG_DWORD value called CrashDumpEnabled, with a second value, FilterPages, distinguishing the active dump from the complete dump.

Hurdle two: the page file requirement

This is the one that silently kills dumps in the field. Microsoft is explicit: if you want a crash dump file to be created during a system crash, a page file or a dedicated dump file must exist and be large enough to back up the system crash dump setting. Otherwise, a system memory dump file isn't created.

Read that last row twice. With the dump type set to Automatic and the page file set to System managed size, Microsoft documents that Windows can set the size of the paging file to less than the size of RAM, sized so that a kernel dump can be captured most of the time. If the machine crashes and the page file was not large enough, Windows grows the page file to at least the size of RAM and records the time in HKLM\SYSTEM\CurrentControlSet\Control\CrashControl\LastCrashTime. The larger page file stays for four weeks, then shrinks back.

Hurdle three: the destination has to be writable at boot

The conversion from page-file blocks to MEMORY.DMP happens early in the next boot. If the path in DumpFile points at a volume that is not mounted yet, or a folder whose access control list (ACL) does not grant write to SYSTEM, or a volume with less free space than the finished dump needs, you get nothing. Microsoft explicitly supports redirecting the path - the Startup and Recovery dialog lets you change it from %SystemRoot%\Memory.dmp to something like E:\Memory.dmp - which is exactly how people accidentally point it at a drive that is not there at boot.

Hurdle four: retention - Windows deletes dumps

Here is the part almost nobody knows. Microsoft published the retention algorithm, and it is a decision tree evaluated after the crash is reported:

1. Report the kernel fault to the online crash analysis service.
2. If AlwaysKeepMemoryDump is set to 1, keep the dump.
3. Otherwise, if the machine is a Windows Server SKU, keep the dump.
4. Otherwise, if the machine is joined to a domain, keep the dump.
5. Otherwise, keep the dump only if free disk space is 25 GB or more. Below that, delete it.

When the deletion happens, Windows logs it. The event text is The dump file at location: %1 was deleted because the disk volume had less than %2 GB free space - event ID 1018 in the System log. So the file is not mysteriously missing; there is a receipt.

There is a second, entirely separate deletion path: disk cleanup. Windows registers cleanup handlers that target dump files by name. On a Windows 11 Enterprise 26200 device these three exist under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches:

Those are the checkboxes a well-meaning technician ticks in Disk Cleanup while "freeing up space" on the ticket before yours. They are observed on a live device; Microsoft does not publish a reference page listing them, so verify them on your own build rather than hard-coding the strings into tooling.

Hurdle five: user-mode crashes get nothing by default

Everything above is about kernel crashes. When an ordinary application crashes, a different mechanism applies, and Microsoft is blunt about the default: WER can be configured to collect full user-mode dumps locally, but this feature is not enabled by default. If you have never created the LocalDumps key, there is no application crash dump on that device. Full stop. The Application log will have a faulting-module line and nothing to debug.

The registry surface, in full

Kernel dump behaviour. Shared parent key:

User-mode crash dumps and error reporting. Shared parent key:

System files in the flow

Where the files land

Report.wer is the file worth knowing about. It is plain text. It carries an EventType, a set of Sig[n].Name and Sig[n].Value pairs identifying the failure, and DynamicSig entries with the OS version and a report identifier. You can read it with Get-Content and learn what failed without any debugger at all.

Service and scheduled task

How to verify: read the configuration, then read the log

Verification splits in two. First, what will happen at the next crash. Second, what did happen at the last one.

Step one: read the crash configuration

This command reads every value under the CrashControl key and prints them. It changes nothing.

Read it like this. CrashDumpEnabled tells you the type. Cross-check FilterPages before you call a 1 a complete dump. A missing AlwaysKeepMemoryDump is not an error, but it does mean retention is out of your hands.

The same thing through Registry Editor, which is what you will actually be staring at on a user's machine:

Step two: check the page file against the requirement

This is arithmetic, not a setting you can eyeball. The command below reads total RAM, the allocated page file size, and whether the page file is system-managed, then does the comparison for a complete or active dump.

Step three: what WMI will and will not tell you

The WMI class Win32_OSRecoveryConfiguration is the classic way to read crash settings, and it is genuinely useful. It maps directly onto the registry: DebugFilePath to DumpFile, MiniDumpDirectory to MinidumpDir, OverwriteExistingDebugFile to Overwrite, AutoReboot and WriteToSystemLog to LogEvent.

Step four: read the event log

This is where the topic gets genuinely satisfying, because Windows records every one of these failures with a distinct event ID. The provider is Microsoft-Windows-WER-SystemErrorReporting and the channel is:

Three more events, from different providers in the same System log, complete the picture:

Step five: reading the dump without installing a debugger

You often do not need a debugger at all, and it is worth knowing how far you can get without one.

• The stop code and its four parameters are in the text of event 1001. Convert the code against Microsoft's Bug Check Code Reference and you frequently have your answer.
• A named suspect driver comes free with event 1019 when Windows can identify one.
• The decimal bug check code is in the event data of Kernel-Power 41, in the BugcheckCode field. Microsoft documents the decimal-to-hexadecimal conversion because this catches people out.
• The WER report in ReportQueue or ReportArchive contains Report.wer, a plain-text file with the event type and the problem signature. Get-Content is your debugger.
• Reliability Monitor (perfmon /rel) presents the same critical events on a timeline, which is faster than filtering the log when you want to know "what else broke that morning".

The fix: registry, Startup and Recovery, Group Policy and Intune

Now the configuration. I will give you the local dialog, the registry, Group Policy and Intune, and be honest about which surfaces genuinely do not exist.

Fix one: set the dump type in Startup and Recovery

The supported user-interface route, per Microsoft's own steps:

1. Open Control Panel and select System and Security, then System.
2. Select Advanced system settings, then the Advanced tab.
3. Under Startup and Recovery, select Settings.
4. Under Writing Debugging Information, choose Kernel memory dump, Active memory dump, Automatic memory dump or Complete memory dump. Do not leave it on (none).
5. Check Overwrite any existing file unless you have a specific reason to keep the first dump.
6. Leave the Dump file path at %SystemRoot%\MEMORY.DMP unless you have a genuinely larger local volume. Never point it at removable or network storage.
7. Select OK, then restart the computer. Microsoft is explicit that the change does not take effect until you do.

Fix two: size the backing store

Two options, and the second is the one most people forget exists.

Option A - a big enough page file. Leave the page file system-managed and accept that Windows sizes it for your chosen dump type at startup, assuming enough free disk space exists. If you set it manually, size it to the requirement from the table above plus your peak system commit charge.

Option B - a dedicated dump file. A dedicated dump file is a page file that is never used for paging; it exists purely to back the dump. Microsoft recommends it when you want a crash dump but do not want a large page file, and it can live on any volume that could host a page file. Two registry values under CrashControl: DedicatedDumpFile as a REG_SZ full path such as D:\dedicateddumpfile.sys, and DumpFileSize as a REG_DWORD in megabytes.

Fix three: stop Windows deleting the dump

One value, and it short-circuits the entire retention algorithm.

Read the output line by line. Each New-ItemProperty prints the value it created. Then reboot - the kernel caches these settings at boot, so an unrebooted change is a change that has not happened yet.

Fix four: Group Policy

Here is where you need the honest answer. Group Policy covers Windows Error Reporting. It does not cover the crash dump type.

1. Open the Group Policy Management Editor on a policy linked to your device organisational unit, or gpedit.msc for a local test.
2. Expand Computer Configuration, then Administrative Templates, then Windows Components, then Windows Error Reporting.
3. Set Disable Windows Error Reporting to Disabled if you want reporting to keep working. It writes Disabled under SOFTWARE\Policies\Microsoft\Windows\Windows Error Reporting.
4. Set Prevent display of the user interface for critical errors according to taste. It writes DontShowUI to the same key.
5. Set Do not send additional data to Disabled if you want second-level data to flow. It writes DontSendAdditionalData.
6. Under the Consent sub-folder, use Customize consent settings to set per-event-type consent from 0 (send nothing) to 4 (send all data). It writes under the Consent sub-key.
7. For a corporate WER server, populate CorporateWERServer, CorporateWERDirectory, CorporateWERPortNumber and the SSL and authentication values.
8. Run gpupdate /target:computer /force and confirm the values landed under the Policies key.

There is a second, older location that takes precedence in some combinations: Computer Configuration > Administrative Templates > System > Internet Communication Management > Internet Communication settings > Turn off Windows Error Reporting. Microsoft documents that if the newer setting is disabled or not configured, this one wins. Check both before concluding a policy is not applying.

Fix five: Intune

Same split. The Windows Error Reporting administrative template settings are in the Settings Catalog because they are administrative-template-backed policies in the ErrorReporting area of the Policy configuration service provider (CSP). The crash dump settings are not, because no CSP exposes them.

1. Sign in to the Microsoft Intune admin center at intune.microsoft.com.
2. Go to Devices, then Configuration, then Create, then New policy.
3. Platform Windows 10 and later, profile type Settings catalog, then Create.
4. Name it something like WIN-Error-Reporting-Baseline and select Next.
5. Select Add settings and search the picker for Windows Error Reporting. The category is Administrative Templates > Windows Components > Windows Error Reporting.
6. Select Disable Windows Error Reporting, Do not send additional data, Display Error Notification and Prevent display of the user interface for critical errors as your baseline requires, then close the picker and set each value.
7. Assign to a device group, review and create.
8. For the dump settings, go to Devices then Scripts and remediations and deploy the registry configuration as a platform script or a remediation script, running in the system context.

Defender and security policy: what actually applies

Being straight about this: no Microsoft Defender Antivirus setting, attack surface reduction rule, exploit protection option, Windows Defender Application Control policy or firewall rule governs whether a kernel crash dump is written. The crash dump path runs in the kernel before any of that is in play. If you were expecting an Endpoint Security profile here, there is not one, and saying so is more useful than inventing one.

Two adjacent things are worth knowing, though. Reading process memory to produce a dump is exactly the behaviour that credential-theft protections are designed to block, so if you configure LocalDumps for a protected process such as the Local Security Authority Subsystem Service, expect it to be blocked or to require WerFaultSecure.exe. And a full dump is a memory disclosure risk in its own right, which is the security argument for restricting dump folder ACLs rather than the argument for a Defender setting.

Proof it worked: a real readiness report

The companion script for this post is Get-CrashDumpReadiness.ps1. It is read-only. It answers one question: if this device bug checks tonight, will there be a usable dump in the morning? It reads the CrashControl values, resolves the dump type including the active-dump case WMI cannot see, computes the page-file requirement, inspects the destination ACLs, lists every dump already on disk with size and date, counts the WER report queues, and pulls the crash and dump-failure events. It never writes a setting and never deletes a dump.

The output below is a genuine run on the Windows 11 Enterprise build 26200 device used for this post, with the machine name and paths left intact but user-identifying strings replaced.

Three things in that output are worth spelling out, because they are the whole point of the post.

First, the dump type is an active memory dump, resolved from CrashDumpEnabled = 1 plus FilterPages = 1. Anything that reads Win32_OSRecoveryConfiguration.DebugInfoType on this device gets 1 and reports "complete memory dump", which is wrong. If your compliance reporting says complete and your registry says active, your reporting is the thing that is broken.

One honest caveat on that arithmetic. Microsoft's page-file requirement table lists small, kernel, complete and automatic dumps - it does not publish a figure for the active dump. Because an active dump is a filtered complete dump, the script applies the complete-dump rule of RAM plus 257 MB as a conservative estimate and says so in its output. Do not quote 31659 MB as a documented active-dump requirement; it is an upper bound, not a published number.

Second, the page file clears the requirement by 85 MB. That is not comfort, that is luck. Any policy that caps the page file, or any RAM upgrade without a page file review, flips this device from "captures a dump" to "captures nothing", with no warning and no error until the day it crashes.

Third, look at section 5 again. There is no kernel dump and the minidump folder is empty, which on a naive check reads as "this device has never had a problem". It has had plenty. There is a 1.33 GB watchdog live kernel report from a hung driver and a steady drip of full user-mode dumps from a crashing updater. Absence of MEMORY.DMP means "no bug check", not "no problems" - and this is exactly why the script separates "read failed" from "genuinely absent" and refuses to print a clean result after a failed read.

References

• Overview of memory dump file options for Windows - the dump types, and the CrashControl registry values with their documented meanings.
• How to determine the appropriate page file size for 64-bit versions of Windows - the crash dump setting versus minimum page file size table, and dedicated dump files.
• Automatic Memory Dump and Active Memory Dump - the page-file sizing behaviour, LastCrashTime, and what the active dump filters out.
• Collecting User-Mode Dumps - the LocalDumps key, all four values, defaults, and per-application overrides.
• WER Settings - the full Windows Error Reporting registry surface, including the live kernel report values.
• ErrorReporting Policy CSP - the five administrative-template-backed settings, their Group Policy paths and the registry values they write.
• Troubleshooting a Failover Cluster using Windows Error Reporting - the ReportQueue and ReportArchive paths under %ProgramData% and the Report.wer file.
• Event ID 41: The system has rebooted without cleanly shutting down first - Kernel-Power 41, the decimal bug check code, and the volmgr 46 cross-reference.
• Event ID 46 when you start a computer - "Crash dump initialization failed!" and its documented cause.
• Win32_OSRecoveryConfiguration class - the property-to-registry mapping and the four documented DebugInfoType values.
• Configure memory dump files for Server Core installation - DedicatedDumpFile, DumpFileSize and dumpchk.exe.
• Install WinDbg - the Windows Package Manager install, and the entry point for !analyze -v.
• Kernel dump storage and clean up behavior - the retention algorithm, the 25 GB threshold, AlwaysKeepMemoryDump and MinidumpsCount. Archived content; the behaviour still matches what Windows 11 logs as event 1018.

Two notes on sourcing. The full Microsoft-Windows-WER-SystemErrorReporting event catalogue above was read from the provider manifest on a live Windows 11 Enterprise build 26200 device, because Microsoft does not publish a single reference page listing events 1000 through 1019. The Disk Cleanup handler names were read from the same device. Both are accurate on that build, but they are observed rather than documented, so confirm them on your own image before you build tooling that depends on the exact strings.