I've adjusted some settings as a result of a more detailed procedural understanding as below, so we'll see what happens.
Crash dump generation
Phase 1 of the system boot process allows the I/O manager to check the configured crash dump options
by reading the HKLM\SYSTEM\CurrentControlSet\Control\CrashControl registry key. If a dump
is configured, the I/O manager loads the crash dump driver (Crashdmp.sys) and calls its entry point.
The entry point transfers back to the I/O manager a table of control functions, which are used by the
I/O manager for interacting with the crash dump driver. The I/O manager also initializes the secure
encryption needed by the Secure Kernel to store the encrypted pages in the dump. One of the control
functions in the table initializes the global crash dump system. It gets the physical sectors (file extent)
where the page file is stored and the volume device object associated with it.
The global crash dump initialization function obtains the miniport driver that manages the physical
disk in which the page file is stored. It then uses the MmLoadSystemImageEx routine to make a copy
of the crash dump driver and the disk miniport driver, giving them their original names prefixed by the
dump_ string. Note that this implies also creating a copy of all the drivers imported by the miniport
driver.
The system also queries the DumpFilters value for any filter drivers that are required for writing to
the volume, an example being Dumpfve.sys, the BitLocker Drive Encryption Crashdump Filter driver. It
also collects information related to the components involved with writing a crash dump—including the
name of the disk miniport driver, the I/O manager structures that are necessary to write the dump, and
the map of where the paging file is on disk—and saves two copies of the data in dump-context structures.
The system is ready to generate and write a dump using a safe, noncorrupted path.
Indeed, when the system crashes, the crash dump driver (%SystemRoot%\System32\Drivers\
Crashdmp.sys) verifies the integrity of the two dump-context structures obtained at boot by performing
a memory comparison. If there’s not a match, it does not write a crash dump because doing so
would likely fail or corrupt the disk. Upon a successful verification match, Crashdmp.sys, with support
from the copied disk miniport driver and any required filter drivers, writes the dump information
directly to the sectors on disk occupied by the paging file, bypassing the file system driver and storage
driver stack (which might be corrupted or even have caused the crash).
During the boot process, the Session Manager (Smss.exe) checks the registry value HKLM\SYSTEM\
CurrentControlSet\Control\Session Manager\Memory Management\ExistingPageFiles for a list of existing
page files from the previous boot. It then cycles through the list, calling the function SmpCheckForCrashDump on each file present, looking
to see whether it contains crash dump data. It checks by searching the header at the top of each paging
file for the signature PAGEDUMP or PAGEDU64 on 32-bit or 64-bit systems, respectively. (A match indicates
that the paging file contains crash dump information.) If crash dump data is present, the Session
Manager then reads a set of crash parameters from the HKLM\SYSTEM\CurrentControlSet\Control\
CrashControl registry key, including the DumpFile value that contains the name of the target dump file
(typically %SystemRoot%\Memory.dmp, unless configured otherwise).
Smss.exe then checks whether the target dump file is on a different volume than the paging file.
If so, it checks whether the target volume has enough free disk space (the size required for the crash
dump is stored in the dump header of the page file) before truncating the paging file to the size of the
crash data and renaming it to a temporary dump file name. (A new page file will be created later when
the Session Manager calls the NtCreatePagingFile function.) The temporary dump file name takes the
format DUMPxxxx.tmp, where xxxx is the current low-word value of the system’s tick count (The system
attempts 100 times to find a nonconflicting value.) After renaming the page file, the system removes
both the hidden and system attributes from the file and sets the appropriate security descriptors to
secure the crash dump.
Next, the Session Manager creates the volatile registry key HKLM\SYSTEM\CurrentControlSet\
Control\CrashControl\MachineCrash and stores the temporary dump file name in the value DumpFile.
It then writes a DWORD to the TempDestination value indicating whether the dump file location is only
a temporary destination. If the paging file is on the same volume as the destination dump file, a temporary
dump file isn’t used because the paging file is truncated and directly renamed to the target dump
file name. In this case, the DumpFile value will be that of the target dump file, and TempDestination
will be 0.
Later in the boot, Wininit checks for the presence of the MachineCrash key, and if it exists, launches
the Windows Fault Reporting process (Werfault.exe) with the -k -c command-line switches (the k
flag indicates kernel error reporting, and the c flag indicates that the full or kernel dump should
be converted to a minidump). WerFault reads the TempDestination and DumpFile values. If the
TempDestination value is set to 1, which indicates a temporary file was used, WerFault moves the
temporary file to its target location and secures the target file by allowing only the System account
and the local Administrators group access. WerFault then writes the final dump file name to the
FinalDumpFileLocation value in the MachineCrash key.
It then writes a DWORD to the TempDestination value indicating whether the dump file location is only
a temporary destination. If the paging file is on the same volume as the destination dump file, a temporary
dump file isn’t used because the paging file is truncated and directly renamed to the target dump
file name. In this case, the DumpFile value will be that of the target dump file, and TempDestination
will be 0.
Later in the boot, Wininit checks for the presence of the MachineCrash key, and if it exists, launches
the Windows Fault Reporting process (Werfault.exe) with the -k -c command-line switches (the k
flag indicates kernel error reporting, and the c flag indicates that the full or kernel dump should
be converted to a minidump). WerFault reads the TempDestination and DumpFile values. If the
TempDestination value is set to 1, which indicates a temporary file was used, WerFault moves the
temporary file to its target location and secures the target file by allowing only the System account
and the local Administrators group access. WerFault then writes the final dump file name to the
FinalDumpFileLocation value in the MachineCrash key.
Courtesy Windows Internal Vol 2
Obviously more than just checking the basics...
