Why won't Windows 7 record crash details when the paging file is separated from the operating systems drive, and can I do something about this?

Solution 1:

This answer is for the second part of the OP's question - "can I do something about this?" Yes!

Windows Vista and later allow you to specify something called a "Dedicated Dump File". (I'll use DDF for short.)

Think of it like a pagefile, but the OS has been told to never use it for a pagefile (thus keeping your actual pagefile I/O on your paging drive). But because it's "like a pagefile" the OS can use it for temporary storage of the dump information at BSOD time. After the reboot it will be copied to the dump file that you specified in the normal way.

What's more, the DDF doesn't even have to be on your boot partition! It can be on "any local volume that can support a pagefile". (This eliminates removable drives, such as anything on USB, and Windows clustered storage.)

Setting it up is easy, but there is no UI, so it does require registry twiddling.

In the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl , create a value called DedicatedDumpFile of type REG_SZ. Set the string to the full path to where you want the DDF to be. You do not have to pre-create the file yourself. For example, C:\DUMPTEMP.SYS

By default the OS will set its size to RAM + 256 MB. You can specify the size manually with another registry value under the same key: Value name DumpFileSize, type REG_DWORD, value = the size you want in megabytes. And those would be Microsoft-style "binary megabytes". So if you want it to be "4 GB", really "4 GiB", you should use 1024 for the value here.

More information is in this MSDN article.

While I'm here, though, I would feel remiss if I did not point out that "a physically separated paging file" usually makes little difference unless you're accessing it a lot... and if you are, it would be much more effective to add RAM.

All the exe's, dll's, and other mapped files that all your processes are using? Those are, in effect, pagefiles too! So moving your pagefile to another drive only isolates paging I/O for that one file. Your system will still be paging from, and in some cases to, all of the other memory-mapped files on your OS drive.

Similarly, disabling your pagefile doesn't eliminate paging from disk (and certainly does not turn off virtual memory) - it only eliminates one out of typically several hundred files from which the OS pages.

Moving your one and only pagefile to a disk by itself does, however, allow you to use the Disk I/O performance counters for that drive to find out just how much pagefile I/O your system is really doing. There's no other way to do that, since the PerfMon counters like "Page read I/Os" do include the page read I/Os to all of those memory-mapped files like exe's and dll's.

Solution 2:

I believe the reason is to have a better chance of creating a reliable crash dump. At the time of the BSOD the system is in an unstable state and it is unknown as to the root cause or it's full implications. The system is of course not in a position to make such judgements for the same reason that a psychiatrist could not be trusted to make a judgement of his own mental state.

Thus, when making a crash dump it is important to keep things as simple as possible. After all, the root cause of the BSOD might be in the file system itself. For that reason the crash dump is written to the pagefile on the system drive instead of to a newly created file. I believe this is done bypassing the file system. Writing to a pagefile on another drive would complicate this. If anything were to go wrong other files or the file system itself could be corrupted and making the problem worse.

During the reboot following the BSOD the system is presumed to be in a stable state and the crash dump is copied from the pagefile to it's final destination. The pagefile can then resume it's normal function.