Weird DedicatedDumpFile Side Effect
In writing an Admin Toolkit item today for Win10.Guru, I stumbled across something weird and unexpected on my working file drive (F:\). I can only describe it as a weird DedicatedDumpFile side effect. It produces a locked file on that drive that I cannot delete, nor attribute to a running process in Windows 10. I was profiling that drive in WirDirStat, and noticed a 32GB (!) file taking around half of the space consumed on that drive. At first, I couldn’t figure out where it was coming from. Nor could I understand and why a new version appeared with each system reboot. Eventually, I searched the registry for the filename in question — F:\ZZDump\dumpfile.sys. Thankfully, it popped up in the CrashControl key (HKLM\SYSTEM\ControlSet001\Control\CrashControl ). A little subsequent Googling and voila! it started making some kind of sense. Here’s what set me off this morning:
Try as I might, I couldn’t delete this file inside the OS. Why was it locked?
[Click image for full-sized view.]
What Causes This Weird DedicatedDumpFile Side Effect?
Creating the DedicatedDumpFile sub-key inside the CrashControl environment targets a specific file system location for a complete dumpfile. I was fooling around with this on my PC, after reading an MS DOCS article earlier this year. Specifically, it describes how to target a different drive from the system/boot drive for a full-size memory dump. What I didn’t realize was that it would write such a dump each time I restarted my system. Nor did I stop to consider that the impact of a complete memory dump from a machine equipped with 32 GB of RAM is substantial. Compound all that by targeting a smaller SSD with 111 GB of usable capacity (of which it is nearly 29% of the entire drive) and you’ve got something definitely noticeable.
The following screencap shows the values for the CrashControl key on the affected system (left) and on another system with only default settings (right, from Insider Preview). The simple presence of the DedicatedDumpFile seems to cause a memory dump at each reboot. Only if I set CrashDumpEnabled to zero (0) — or delete the DedicatedDumpFile subkey — does this behavior stop.
My extended definitions from the production PC left, a default setup on an Insider Preview PC right.
[Click image for full-sized view.]
Another interesting Windows mystery unraveled, with a couple of possible fixes. Glad to have sussed it out, and to understand that using a dedicated dump file comes with certain (hidden) costs.