I've got a secondary harddrive (a separate physical device, not a logical partition) specifically dedicated for the Virtual Memory paging file. The drive is 3.5x larger than my RAM, so it's plenty large.
When I configure Windows 7's virtual memory to put the paging file on this second harddrive and not the same drive as the operating system, I'm warned,
If you disable the paging file or set the initial size to less than 800 megabytes and a system error occurs, Windows might not record details that could help identify the problem. Do you want to continue?
So in other words, if I get a Blue Screen of Death, I won't be able to investigate why, just because I put my paging file at a more efficient location.
The best explanation I can find from searching the web is that Windows just doesn't want to make error dumps on a drive separate from the operating system location. Can anybody give me a less nonsense explanation for this?
I don't want to have to tell Windows, "Sure, go ahead and continue managing a paging file on the primary drive," just so I can get a debug dump, as that totally defeats the purpose of a physically separated paging file. Is there a workaround to having my paging file on a separate drive and still get error dumps?
Answer
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.
No comments:
Post a Comment