How to Delete Unused Pagefile.sys in Windows 7

Do not delete a PAGEFILE. Let windows do that. From start and type <pagefile> in the search. Follow that to change the size or location.

I always leave mine on c: and let windows manage or set to a fixed size of twice the size of the RAM.

HTH,
Ken

I thought I'd made that clear. The FIRST thing I did was to let Windows delete the file in the VMM. It failed...

This may be a little unorthadox but if you have 12GB RAM you have no need for a page file.  I have no page file w/4GB and works fine.  Set all drives to "no paging file" then you can delete the page file.  You may need to take ownership to do that.

@kpmartin

tried that. In fact, I'm in that mode as we speak. ALL drives ARE currently set to "None". The pagefile.sys on the C drive is still there, still cannot be deleted and is still, apparently NOT there as well!

Anyone know of a way to test if the system is actually using a non existent but visible swap file?

came across a few other refs to not being able to delete the swap file eg http://www.tomshardware.com/reviews/vista-workshop,1775-6.html where they mention, as a result, that you should set it to the minimum before disabling it. It also mentions the windows warning about not being able to do a system dump if you reduce the swap file size below 400 (the warning I got was actually 800).

I thought, what the hell, I'll settle for that (a smaller non existent pagefile.sys) as preferable to one I can't get rid of at all. So I tried changing it to 800 mb just so that windoze would not complain about anything. And rebooted with the now newly activated swap file. Guess what size it rebooted with. You got it; still at the 12 Gb it originally set...

This is clearly a bug in the OS which should have been detected before now, but be that as it may, I'm still in the market for a solution...

oh, and did try "taking ownership" to see if that would let me delete the inactive file. Nada...

and I would urge MAJOR CAUTION against "taking ownership" in a Windoze 7 system. It produces all sorts of weird behaviour (like infinitely nested appdata folders) which can cause serious problems.

Fortunately, one of the benefits of EazFix is that you can perform experiments like that, then revert to the previous state absolutely confident that you're back to square one, but without a safety net like that I would generally warn against it... (a system restore will NOT reverse the FULL effects of taking full ownership of your system drive [even though Microsoft may tell you it does/should])

Just for grins I set and changed swap on 2-3 drives on 2 different systems and each time after reboot the pagefile was either gone or had switched drives.  When I set none on all drives, it's gone without manual delete as expected.  There must be something specific to your setup; weird.  I'll keep looking...

hmmm... are they 64 bit systems?

1-33 & 1 64 bit

Fat finger 32 obviously.  That system had 2 drives so just swapped between drives a couple times with pos. results.  Th 64 has 5 drives so tried several combo's incl 2 swap files and 0 swap.  All were correct after reboot.

and did this include behaviour of the system drive?

I ask because on all other drives, I too get the behaviour as advertised. The only one that refuses to either change size or disappear is the one on the system drive (which, of course, is the only one that matters...)

Closed, I wouldn't object to, but I don't think it should be deleted because it is an important issue and others may benefit at least to the extent of learning that no one has found a  solution. That can at least stop the frustrated searcher banging their heads against the wall...

Sorry, didn't mean to give up on this issue.  To answer your last question, yes it is the system drive.  Since this thread started I've installed a new HD and reinstalled Win7.  Now have 4 drives and I set all for no paging file; rebooted and pagefile.sys is gone.  Seems like it must be a permission issue and I would look in that direction.

In addition, open the performance monitor from control panel and add paging file to the counters to see if it is actually using it.  Mine shows no instances and actually won't add the counter.

I'm sure you're right about it being a permissions issue but it's not obvious what other permissions I need. I'm already admin and already "own" the system drive.

Even without the Performance monitor, I know it's NOT using the redundant file on the system drive and IS using the one I've set up on the E drive because the modified datetime stamp is current on E and still set to November on C...

When you used Bart's PE, was it the Linux version or windows?  I use the UBCD, linux ver and it should allow you to delete the file.  But first I would set to no paging file anywhere.  Also, open regedit and go tp: Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management and see what the settings are.  All mine are zero but you might want to set ClearPageFileAtShutdown to "1", reboot and see if that works.
Also, try using Explorer w/elevated privileges.
Check to see if in advanced properties for the system drives that all the perms and ownership seem to be correct.
I'm assuming you have a login password and not sure if this is pertinent but I do recall in some past win vers that some functions wouldn't take if you didn't have a password set for the system.
Hope this helps!  kevin

Bart PE Windows version.

the Reg shows what the current settings are (c set to min 800mb, e set to 18Gb) which is all I want to achieve. The problem is, of course, that despite those settings, the actual size of the c pagefile is still 12Gb.

My original motivation for losing the pagefile on the system drive was to avoid wasting unnecessary space in my Eaz Fix snapshots. That issue evaporated after clarification from Eaz Fix who reassured me that their software ignores the pagefile anyway. So the remaining issue is an irritant rather than critical. i.e. why can't we - even as owners and admins - get proper control over the windows system?

On the permissions front, I've explicitly avoided taking full ownership of the system drive (because of the horrendous issus that has caused in the past)  and tried to limit it only to the pagefile but that clearly hasn't worked so I'm going to try the full ownership route again - just to see what effect it has on the pagefile and, if it works, drop the full ownership after success (or failure).

I'll feedback the results...

Gotcha.  Still a shame to waste that much space.  If you use a linux boot disk; I recommend the Ultimate Boot CD (UBCD), it will allow you to delete the pagefile.  The only reason you should even need one is for crash dumps.  The rest of the time it's going to use your RAM since you have so much.

No joy. Tried the above. Still no progress.

Well, I guess if you don't want to try the ownership route and if that has caused you problems in the past then it's understandable, I think you'll have to live with it as is unless someone else has a different direction.

Pagefile on system drive is used for crash dumps.

yes, we know about the crash dump requirement, but microsoft themselves indicate that this requirement is met with a pagefile of less than a Gb, not the 12Gb that it is using now...

Having read all this (whew), I see two unconsidered possibilities:
Is there any chance you are launching a VM (Virtual Machine or XP Mode)?
If not, I think you need to run TDSSKiller to check for TDSS/Aleurion ( http://support.kaspersky.com/viruses/solutions?qid=208280684 )

Open an Administer cmd prompt

takeown /f C:\pagefile.sys
cacls C:\pagefile.sys /G youruserid:F
attrib -r -s c:\pagefile.sys
del /F C:\pagefile.sys

Good Luck

Of course you should make sure that C: is set to no paging file in advanced system settings before trying the above.

You can use "pendmoves" from sysinternals to delete or move away any file when system boots.
in case pagefile.sys is needed it is re-created.

@DavisMcCarn
That's an interesting question. As it happens I have SINCE the problem arose and AFTER the first batch of discussion (November) installed a VM in December. Are you suggesting it may now be preventing resolution of the problem? Before answering that, you should know that its own virtual drive is on my K drive - not the System drive (C:) and, as far as I can tell, the Virtual XP system is entirely unaware of and unconnected to anything on the Win 7 system drive.

@bgoering
We've moved on from mere deletion. I'm no longer intent on deleting the pagefile - because the consensus (and microsoft's own advice re Win 7) is that there must be a pagefile of 4-800mb on the system drive to cope with crash dumps. I can live with that. The problem now is, despite the system setting already setting it as an 800mb file, it doesn't actually change from the 12gb.

Yes; but, the real question is what the pagefile settings are for the VM, huh?

I regularly set and defrag the pagefile on at least 10 systems per week and have never had your problem (unless the machine was infected).  Did you try TDSSKiller?  It doesn't do anything unless it finds the Trojan.

The VMXP pagefile is a 1.6gb file right where I'd expect it to be - on its own C drive which is a reserved section of my K drive.

I did run TDSSKiller and it found no infection though, intriguingly, it reported 13 "forged files" in my sys32\drivers folder which weren't there!

There should be no folder named sys32
What are the names of "forged" files?
Is the result of spyware scan same in safe mode?

TDSSKiller created a report file.  Can you post it as an attachment, please?

Also post a hijackthis (http://free.antivirus.com/hijackthis/) report from SAFE MODE

don't panic: the "sys32" was merely my abbreviation for system32!

the tdss log is attached. I'll get around to hijackthis later...

oh, and in addition to the alleged forged but absent files, you'll note right at the top that tdsskiller thinks I have 8 processors running. Last time I looked, my i7930 only had 4. So I'm not entirely convinced that tdss is accurately reading anything on my system...
TDSSKiller.2.4.16.0-02.02.2011-0.txt

It might be helpful to point out that infection, though not impossible, is extremely unlikely. I run behind hardware and software firewalls, with updated antivirus (avast free) and clamwin (inspecting all my downloads). I browse using latest firefox with noscript and adblock plus all inside a sandbox(sandboxie). All my passwords are secure, independent and managed by Roboform offline.

Furthermore, whenever I come across anything remotely suspicious, I tend to use Eaz Fix to restore my machine to before any infection could have taken place.

The cause of this problem is far more likely to be me tweaking the wrong things or the right things in the wrong order! That has been my experience in the past (eg the horrendous problems I caused myself when I insisted on taking full ownership of every part of the system)

and just for fun, here's the hijackthis file. Can't say anything unusual leapt out at me. It reports the usual batch of "missing files" but that's perfectly normal under 64 bit windoze. Other than that, looks healthy enough to me.
hijackthis.log

ah, didn't run hijack from Safe Mode. Can't do that right now, cos I'm recording an HD documentary on Iplayer. Will give that a whirl this evening...

managed to run the hijackthis in safe mode. Can't spot any obvious differences but here's the log anyway...
hijackthis.log

I hate to say it; but you are definitely infected and the proff is in your earlier statement!
If you can't even see that TCPIP.SYS,  KSECPKG.SYS, and MRXSMB.SYS (not to mention most of the others) are in the SYSTEM32\DRIVERS folder, you have a rootkit which is hiding the malware and is why that pagefile keeps coming back as it is launching another, hidden account.  Except for the two ATI files at the top; Windows wouldn't work if the others are missing.
Given your timeline, try this WIN32/MEBROOT tool: http://kb.eset.com/esetkb/index?page=content&id=SOLN2372

system.ini entry for userinit.exe is obsolete

1) system.ini was used for Windows until ME
2) it was not used by NT and followers where userinit.exe is present.

Actual entry is in registry

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"Userinit"="C:\\Windows\\system32\\userinit.exe,%windir%\\system32\\userinit.exe,"

Please edit system.ini and recover registry entry all from Safe Mode.

Since there is two of us seeing rootkit around, i would recommend that you use other clean system to acquire spybot and its update signatures file, and install tem in safe mode from CD-R(W) media (you may try safe mode with network and download signatures as installing but given TCPIP driver looks backdoored it might simply waste your good effort), then run full immunization, restart in safe mode again, run a full scan and cleanup , then check if you have sneaky driver files still around, if so

post the list of the directories with sneaky files from normal session and form safe mode (or compare them yourself)

at least one of them is BAD FILESYSTEM FILTER to delete
most likely it is not signed by microsoft, that you can check with sigverif.exe inluded in your system from safe mode.

good luck, see you here soon.

Gentlemen, did you follow the link I posted re Hijack This NOT seeing files in Win7/64 bit environment?

Now, I don't claim expertise in this area, which is why I'm here, asking for help. But I can tell you the following:

1 The "missing files" (with 2 trivial exceptions) are all actually there and visible in explorer
2 I've run Hijack This on 3 other 64 bit Win 7 systems (two of which I built but 1 of which I've never touched) to compare results and they're identical.

So unless we're all infected, none of us are (at least not with the same thing!)

Furthermore, the pagefile problem doesn't affect any of those other machines.

Nevertheless, just in case, I have spent most of the past 24 hours booting from cds and running a variety of further checks including Sophos Anti Root Kit, Spybot Search and Destroy and Clamwin Portable. The Sophos is running as we speak and is likely to take another few hours but, so far, nothing to report.

Finally, I believe the only 64 bit rootkit currently capable of attacking Win 7/64 is the TDL/Alureon/TDSS which would have been identified - hopefully - by the TDSS Killer which you (DM) advised me to run earlier; and, as you can see from the log, it didn't find it.

So I'm fairly confident that, whatever else may be wrong with my system, a 64 bit rootkit isn't the probable cause.

My last post was from your TDSS log and the forged MD5 hashes listed.  With a rootkit, you will be able to see the driver which is controlling; but, it willl intercept and mask all processes, files, and registry entries it was designed to hide.
What are the two "trivial" missing files?

yeah, the TDSS log worried me more than the Hijack log. Mind you I gave you a bum steer when I said they weren't even there. I was not looking with admin rights. They were there and the hashes were as advertised in the log, so what I did was uploaded them one at a time to Virus Total and on each of the half dozen I uploaded, a) the files were all recognised, telling us that someone else has trodden this path before me, and b) all 41 AV packages gave all the files a clean bill of health. I must confess I didn't bother uploading the rest because the pattern was pretty clear.

The two triivial missing files, off the top of my head, were related to the fax service which I don't use and windows media player which I rarely use...

OK, I've surrendered to the inevitable.

I've wiped the partition (and the reserved partition) and reinstalled the entire system from scratch. My pagefile and hiberfil and now back under my control.

I tried using Eaz Fix to go all the way back to a point at which I still had control of the pagefile (and hiberfil) and eventually concluded that no such point existed. That does tell us something, viz it can't have been down to any specific software other than windows itself.

What I found on my first snapshot might be some kind of clue. I had obviously made what looked like a successful attempt to control the files because they were both set at 0 bytes - yet the clue to the problem still existing is the fact that both files were still on the disk. Set them "successfully" to zero in a "normal" system, and the files disappear.

I can only speculate that I did something to upset the system on day 1 and only the total reinstallation was ever going to fix it. Even after the reinstallation, although the pagefile immediately behaved as advertised (I've now set it to a token 1gb for the sake of the crash dump file), I did find it ludicrously difficult to remove the hibernation file. Merely changing the power settings to "Never" had no effect. Nor did going into safe mode and running "powercfg -h off". Nor did most methods of running a cmd window with elevated priveleges.

The only method that eventually worked was running elevated priveleges using the technique of entering CMD in the search box, then pressing SHIFT CONTROL ENTER. In the resulting window, "powercfg -h off" finally worked and the file at last disappeared. I have no idea why ONLY that route did the trick.

Nor do I have any idea how to close the question or what to do about the points. The problem remains unresolved in the sense that we have no better idea now about what was preventing control of the pagefile than when we started. Nor did anything in the discussion lead me to the fix (reinstallation). Nevertheless, I've learned a few new tricks in the process and am quite happy to award the points to those who contributed.  Thankyou for all your contributions. I shall ask the admins how to proceed with closing the question...

I did a bunch of searching and had not been able to find anything pertinent.  After the reload, did you see if those spoofed MD5's were gone by running TDSSKiller? (I would have)

excellent question, I did and I should have fed back the results. Absolutely no change. The same 13 files forged. So I then checked the md5 of the TCPIP.SYS (one of the "fakes") on the other 3 machines I mentioned above and - you guessed it - we're all identical.

To my astonishment, I discovered that you cannot find out from Microsoft what the correct md5 is for ANY of their files!! (unless, I suspect, you're prepared to pay for it)  So unless we organise a global hashing collective, I cannot obtain a definitive answer but I have to say I am highly confident we're talking about a false positive (or, rather, 13 false positives)

I do want to thank you for asking the question though because it spurred me into action with Kaspersky. I submitted the following through their FAQ feedback form related to the TDSSKiller. (They don't offer a direct email address and I couldn't be arsed to join one of their forums, so I doubt if I'll get a response but if I do, I'll post it back here.)

**********************MESSAGE TO KASPERSKY:
I believe you may have an error in your TDSSKiller detection routine. It has been finding no infection on my win 7 64 bit system consistently, but insists I have 13 forged files (md5s don't match your detection list)

This led me to reinstall my system from scratch on Tuesday. Reran the test and same files still came up as forged. I then tested the md5 of one of the files - TCPIP.SYS - on 3 other Win 7 64 bit systems (2 of which I built so might have "infected" the same way) and one which I've never touched and was only bought last week. All 4 machines return the same md5 values for the file. So unless we're all infected, I suspect none of us are.

I also submitted 7 of the allegedly forged files to Virus Total and all 41 of their online checkers gave all the files a clean bill of health (Including your own software) (at which point I realised we were obviously either dealing with a false positive or something beyond the reach of the online malware detectors and gave up) Furthermore, I was obviously following a well trodden trail as all the files had previously been uploaded by other punters who, presumably, were being frightened by the same reports. So I'm inclined not to believe TDSSKiller. (Or else the problem is far deeper and more widespread than anyone has so far noticed)

Can I suggest you recheck the 64 bit md5s and, if necessary, update TDSSKiller accordingly

Here is a sample line from the log.txt I've just rerun.

2011/02/10 22:38:49.0093 4816      Suspicious file (Forged): C:\Windows\system32\drivers\tcpip.sys. Real md5: 912107716bab424c7870e8e6af5e07e1, Fake md5: 90a2d722cf64d911879d6c4a4f802a4d

As I say, all 4 of the machines I've tested it on share that same "fake" md5 (1 running on Ultimate, 3 on Professional)

I'd appreciate it if you let me know the results of your investigations.

Thanks

(my email address)
 

And, yet again, "Thank you, Bill Gates"!
Because I have a separate drive expressly set for temporary files ( good kick in the butt for performance ), IE8 likes to screw up my cookies and history.
Why (this time); because I was at a site which gave me the MD5 for your files and now I can't (easilly) refind it.
MD5 hash' are supposed to be being replaced as they are (apparently) relatively easy to spoof. But; to find that M$ has screwed this up (too) is really disheartening.
My brother used to say " Microsoft wrote all the rules, they know exactly how to break them!" and I think we're in exactly that morass.
You said earlier that it isn't really affecting anything.  Close the question and ignore it.

ah now on the question of MD5s I do have some expertise. The hypothetical compromise you refer to has absolutely zero (practical) implications in the area of file verification.we're discussing here. Yes it is mathematically possible to create a "collision" (two or more digital sequences which hash to the same value) but its still difficult. (This is unrelated to the much simpler task of brute forcing short passwords to find a hash match - there the difficulty is limited by the length of the password and the range of characters it may contain. Choosing a "better" hashing algorithm (RIPEMD, SHA256 etc) wouldn't help.)

But the use of the compromise to create malware is utterly intractable and likely to remain so. What the author would have to achieve is not just finding an arbitrary collision, but one which also contains the digital sequence required to achieve their malicious aims in the right sequence a computer requires to be able to read the sequence as a valid instruction set. That task is still one which would take a quantum computer several universe lifetimes. And even if achieved, would be easy to defend against: just publish the length of the official file as well as its MD5 and now you've made the collision task even more ludicrously extreme. For which reason, even CRC matching (plus the file size) is more than enough to verify a file match.

Back on topic, I strongly suspect that Kaspersky's md5s are limited by some parameter they have assumed or ignored; like, for example, the region. Perhaps the UK versions of lsass.exe or tcpip.sys or whatever do hash to different values.

I invite anyone with a 64 bit Windoze 7 system to post their md5 hashes here. Actually it would be bloody good service for Experts Exchange to provide. A bit of crowd sourcing and we could post all versions of all important files - not just windoze - to the ""EE File Verification Library".

As to closing the question, I think I'll hang on a few more days to see if we do get a response from Kaspersky which is worth posting...

Actually, one of the developments, last May, was that the cybercriminals figured out how to insert their code into numerous .SYS drivers without adding to the size of the file which seriously complicated detection.  What has bugged me for years is why M$ can't protect by, at least, forcing the modified date to change.
Having had TDSS Killer identify and cure well over 200 systems; it's also going to be a major pain if M$ stops using valid MD5's in Windows 7.  You are the first person I have encountered who did not have an infection; though, I don't see many systems with Ultimate.

Microsoft uses digital signatures on system files.
Especially it uses signed sha1 hash as MD5 can be forged.

Differences in hashes come from different file being read using different read functions. It should never happen.

@DavisMcCarn
But they have no hope of maintaining the files size AND maintaining a valid hash. Hence the need for both to defeat both that attack and the hypothetical MD5 collision attempt. The modified date field would offer no protection as it is trivial to change that back to whatever date the original file had.

And I really don't think it's about Microsoft not using valid MD5s. Its about legitimate alternate versions being out there in the field and Kasperky not picking up the MD5s of those legit alternatives. (although I have to caution that I'm still speculating on that. Still no response from them)

The only thing (on this occasion) that we can blame Microsoft for, if my speculation is correct, is that - as the authors of the relevant files - they could trivially publish the legit MD5s of every (important) file they issue, which would make all our lives a lot easier.

@gheist
see my previous comment on hashes.

tdskiller used two different APIs to read the files and found different result

really your assumption is completely wrong - microsoft signs SHA1 checksum of every system file with their private key, there is no need to distribute anything, if you are really suspicious reload CA chain and reverify each signature...

it clearly shows that filesystem filter is active on particular system. it might be open file driver for backup software or antivirus, but most likely it is a trail of spyware.

Looks like we're not going to get an answer this time round, time to close the question...