5

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?

Improve this question
3
  • 1
    It may be because the system drive is the one that has the best chance of being present at the time of a crash (as per LMiller7's answer). You could try a manually controlled 800MB page file on your system drive and the rest on your swap disc.
    – AFH
    Commented Apr 1, 2017 at 19:52
  • @AFH If you have more than one pagefile, then each time Windows wants to write something to the pagefile, it will use the one on the disk that's been least busy recently. (This goes by the "average request queue depth", a rolling average that you can see in Performance Monitor.) So that usually works out well for this issue.
    – Jamie Hanrahan
    Commented Jun 20, 2017 at 1:09
  • @JamieHanrahan - Thanks for the insight, and for your answer.
    – AFH
    Commented Jun 20, 2017 at 10:45

4 Answers 4

Reset to default
7

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.

Improve this answer
5

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.

Improve this answer
8
  • 3
    "I believe this is done bypassing the file system". Correct. From Windows Internals, C14 "Crashdmp.sys, with support from the 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)."
    – DavidPostill ♦
    Commented Apr 1, 2017 at 20:04
  • This answer is wrong. It has no source and it is a personal opinion based on the incorrect information that the OP gave.
    – user477799
    Commented Apr 2, 2017 at 9:51
  • 1
    @FleetCommand It does have a source (see my comment above)
    – DavidPostill ♦
    Commented Apr 2, 2017 at 9:56
  • @DavidPostill It is a synth ... and did you read the second part of my comment? Let's keep this in the chatroom by the way.
    – user477799
    Commented Apr 2, 2017 at 10:00
  • This answer is correct. This isn't WIkipedia; some answers here ARE syntheses.
    – Jamie Hanrahan
    Commented Jun 20, 2017 at 1:00
0

You have woefully misinterpreted the error message. It says:

If you disable the paging file or set the initial size to less than 800 megabytes [~snip~]

...whereas you interpret it as:

If you put the page file on another drive [~snip~]

How did you get from the first to the second? Ask yourself this question: Are you disabling the page file or setting its size to less than 800 megabytes? The answer is: Hell, no! You are moving it to another drive.

Windows gives you this warning message, even if you set a paging file on another drive first, because you can always go back and undo it.

Improve this answer
1
  • Regardless, the OP's interpretation is correct. If you put your only pagefile on another drive - which the OP is trying to do - the OS will not be able to create memory dumps. I suppose the error message would be more clear if it said "If you disable the paging file that's on the OS partition, or set its initial size to less than 800 megabytes..." but regardless, not having a pagefile of adequate size on your OS partition (regardless of whether you have one elsehwere) will disable the system's ability to create memory dump files after a BSOD. (See my answer for a fix)
    – Jamie Hanrahan
    Commented Jun 20, 2017 at 1:53
-1

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.

This statement is incorrect.

You can configure the dump file location independently of the page file location.

  1. Start > "Control Panel" > "System".

  2. Click "Advanced system settings".

  3. Click the "Advanced" tab.

  4. In the "Startup and Recovery" section click "Settings".

  5. In the "Write debugging information" section, select the type of dump you want, and the "Dump file" location (which can be on any disk you choose.

    enter image description here

Notes:

  • Regardless of any page file or dump file settings basic BSOD information will be written to the System Event log (if configured to do so)

  • The dump file can be used to investigate the cause of the BSOD.

Further reading

Improve this answer
1
  • Sorry, but this doesn't do what the OP wants. It works for putting the "final" memory.dmp file elsewhere, but it doesn't eliminate the need to have a pagefile on the OS partition in order to write memory dumps! As explained in some of your links, the pagefile on the OS partition is used as temporary storage for the dump information. Unless you configure a "Dedicated Dump File" - see my answer.
    – Jamie Hanrahan
    Commented Jun 20, 2017 at 1:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .