Solved Random Page File Errors

[seekermeister]

I'm having a problem with the error shown below reoccurring on random boots. I had the same type of errors showing up just before I put together my new rig, and since I did a clean install, I can't think of any hardware or software that would be common between them, that should have any relationship to the problem.

I thought that it might be due to the fact that my page file partition was set too small for the size set for the page files, but I increased that so that there should be about 2GBs of extra space.

When this error occurs, I check the page file partition and find no page file there, but I do find it back on C: at a size smaller than I set it. I'm quite puzzled about this, would anyone have an idea that would make sense of this?

 

[cluberti]

Not readily, but I'm wondering if it's having any issues writing to the original paging file, and thus creating one on C: (where it knows it can access it, as it's probably the \Windows volume). Is there anything special about where you're putting your paging file on your PCs? Is it on a separate partition on the same drive as C, or is it on another disk? Is the disk on a different controller? Etc.

 

[seekermeister]

Different partition on the same drive as W7, thus the same controller.

 

[cluberti]

Interesting. Can you take a screenshot of your (working) pagefile settings from sysdm.cpl, and another screenshot of your disk configuration via diskmgmt.msc and post them here? I'd like to see what you're working with.

 

[seekermeister]

Interesting. Can you take a screenshot of your (working) pagefile settings from sysdm.cpl, and another screenshot of your disk configuration via diskmgmt.msc and post them here? I'd like to see what you're working with.

Here they are, for what they are worth:

 

[cluberti]

You say it happens not every time? It might be useful to set your system to have no paging file at all and reboot. Then, delete pagefile.sys from the G: drive (you will have to do this from an elevated cmd prompt), then reboot again. Recreate the paging file on G: again, and reboot one more time. It should be contiguous at this point (you can look to see with most defrag applications).

The only thing I can think of off of the top of my head so far would be some problems with the system volume information on the G: drive regarding the paging file, and deleting/recreating it would fix that if that's what it is. Otherwise, let me know if the problem continues after deletion/recreation of the paging file.

 

[seekermeister]

I set it for no page file, but there is nothing in either C: or G: as far as the page file is concerned after doing so, so there is nothing to delete. After Windows made the page file in C:, there was no page file in G: either. I have no reset the page file for G:, but will have to wait a couple of boots to see what happens...I expect the same as before.

 

[stormy13]

Different partition on the same drive as W7,

Might as well leave it at default if you're going to do that. There is zero benefit to have the page file on a partition on the same drive as Windows is installed too, and can actually hamper performance if the pagefile is required at the same time as something is being read from the Windows partition.

If you're going to move to move the page, set it on another drive completely. And if you do set the pagefile partition as the first partition on the drive so that it can take advantage of being on the fastest part of the drive.

 

[seekermeister]

Thanks, seems as though I vaguely recall hearing that before. I moved the page file to another drive, but I can't make it the first partition yet, because the drive is where my old W7 installation resides, and I want to make sure that I don't need anything from it, before deleting it. When I do, I'll move the page partition forward.

EDIT: No, it was a good guess, but even with the page partition on a different drive, the problem continues.

 

[cluberti]

Note that even after you set the paging file to nothing, pagefile.sys can still exist. It's system+hidden, so you'll only see it from an elevated command prompt via "dir /a".

 

[seekermeister]

I have it set to show hidden files, and the pagefile.sys does appear where it is set to be located. Are you saying that there is another level of "hidden" that would possibly make it not appear, when disabled?

 

[cluberti]

No, it would just be marked system and hidden. If it deleted it, great . It just doesn't always do so, and it's good to make sure it does for certain before re-enabling a paging file on that volume.

 

[seekermeister]

Okay, understood. However, since the page file does not continue to exist where it is set, when this problem occurs, that can't be the cause for this issue to continue. Obviously, there is a real problem somewhere that is making this happen, and that is what I'm searching for. I have not yet proven it, but I have a hunch that there is some kind of problem either with my RAM, or in the manner in which my motherboard is using it. If there is, it seems likely that this may be the reason for the mislocated page file, but that is only a guess. I'm going to run Memtest86 and see what it says.

 

[cluberti]

Always a good idea. You can also try doing boot traces using Process Monitor in the hopes it catches it as well, and if so saving off that log file and analyzing it to see what happened.

 

[seekermeister]

I ran Memtest-86 last night. and it found no errors after 6 passes. I have no idea of how Process Monitor would relate to this problem, or how to use it for that purpose?

 

[cluberti]

A boot trace would capture all file, process, and registry activity on the system. If something happened and a new paging file was created, procmon would at least capture that, and potentially the why as well.

 

[seekermeister]

I still fail to understand, I have scoured the menu options for Process Monitor, and found nothing that appeared to offer the possibility of performing a boot trace as you described. Process Monitor is just the replacement for FileMon, which only displays file activity while it is open.

EDIT: Forget what I said, I didn't scour as deeply as I thought. I found the option and enabled it, then rebooted, and when opening Process Monitor again, it offered to save the logs. I directed it to desktop, where it created 4 logs, but when I attempt to open them, Windows says that it is unable to open them for reading.

 

[seekermeister]

I'm not certain that it is caused by the same problem, but on random boots, I get a variety of error dialogs, some of which are shown below. When they do occur, it will usually take 5-6 minutes for the boot to finish and the system to become usable. The boot time is quick and normal until reaching desktop, it is from then on that the problem starts happening. Even after it finally finishes, probably only half of the programs that should be running in the System Tray are, yet UltraMon, which usually is included the the alerts does continue to operate as it should, even though sometimes it says that it run into a problem and has to exit. After a boot such as this, the next one may be perfectly normal, without a squawk. If this is the result of a faulty startup program installation, I would think that the problem would be consistent...it's not. Is there anything else that I can check?

 

[seekermeister]

I believe that I found the culprit...Outpost Security Suite. I uninstalled it, then ran 12 consecutive boots without any page file or error windows appearing. I then reinstalled OSS, and on the first boot, the page file error popped. I'm a bit surprised, because this problem didn't happen with this version of OSS before doing a clean install of the OS for the new hardware build, but I guess it is time to start shopping for a new security suite to replace it.