Alex Necula : 24 September 2025 07:07
I have been working for several years as a System Engineer, and one of the tasks I handled was managing Citrix PVS. One of the issues with PVS was investigating dump files. The only way to generate a complete dump file was by using the DedicatedDumpFile option, which is available as a registry key under HKLMSYSTEMCurrentControlSetControlCrashControl.
A significant obstacle when the DedicatedDumpFile is enabled and configured is deleting it, because it is always in use by a process. The crash dump is created by the Windows kernel (ntoskrnl.exe) in cooperation with the Crashdmp.sys driver. To guarantee that the file is always contiguous, non-fragmented, and available at crash time, the kernel keeps that file opened and reserved while the system is running.
Now, what happens if the value of the DedicatedDumpFile registry key is not a .dmp file? By design, Windows does not verify whether the key value points to a .dmp file. If we put the path of an .exe file (e.g., EDR.exe) in the DedicatedDumpFile key, Windows will open the file at boot, causing the .exe to be in use.
Can this cause a protected process, such as an EDR, to crash? Yes, of course.
I made a simple PowerShell script that adds the DedicatedDumpFile key with the value of an .exe path (EDRService.exe).
Press enter or click to view image in full size
Powershell to add key
As you can see in the image below the key is successfully added.
Key Added
Of course, a reboot is required because the key was added under HKLM.
After the reboot, as mentioned above, the EDR process cannot start because the service is in use. Now we are able to perform the desired actions without the EDR’s interactions.
Press enter or click to view image in full size
This technique was tested against eight EDRs, and only one of them blocked it – not because of the DedicatedDumpFile, but because it checks whether a registry key is written with its name.
