This also means that a conventional keyboard is required. It won't work with an USB keyboard.

While the right Ctrl key is held down, press ScrollLock twice. This makes the keyboard driver generate a STOP-Error 0x000000E2. Thus forced to crash, the operating system will create a crash dump.

Only the full dump contains all the information needed. The other two dump formats provide only information about the kernel or the crashing application, respective.

In order to create a full dump Windows needs a swap file which has to be at least 1 MiB larger than the physical memory. In addition, this swap file has to be located on the system volume, that is the volume holding the active \WINNT or \WINDOWS directory.

The reason is obvious: Usually the operating system creates a crash dump if a fatal error has occured. In that situation the system is instable. In the case of forensic imaging there's a similiar situation. Of course the system is stable here, but we want to preserve as much state information as possible. Both situations can be handled well if one relies upon as few functions as possible. That means no disc cache, no NTFS, even no FAT32. Only the miniport driver (a copy of it, to be exact) will be used to write the dump.

Without any filesystem drivers there are no objects like "directories" and "files" either. As a last resort the system will be able to write to a predetermined location of the disk, where the swap file resides. But why is there real dump file after the forced crash and the subsequent reboot?

During the reboot Windows (SMSS to be exact) detects that a crash dump has been written into the swap file. Therefore it locks the swap file and prevents any access by memory management. At a later stage Winlogon also checks the swap file and finds the dump. It then starts savedump.exe, which finally copies the preserved data from the swap into an ordinary file.

This also explains while it takes a while to log in for the first time after a (forced) crash.