R. C. White said:
Hi, Jeff.
Yes, as Paul points out a few messages down, "Erasing the pagefile may
make you feel better but wont do a thing for security." On a hard disk,
nothing ever really gets erased. The best we can do, short of physical
destruction, is overwrite the disk space with zeroes, gibberish or some
other characters. And, as he also says, any of us with just moderate
computer skills could resurrect your "erased" data without too much
difficulty. (Even I could do it. <g>)
Note that the pagefile gets re-created each time the computer is
restarted. For those of us who shut down and restart daily, pagefile.sys
always has the timestamp for when we booted the machine this morning.
So, the entire contents of the page file are effectively "erased"
automatically each day. The data is still there, but unless we resort to
WinHex or some other disk editor, it is inaccessible. ("Delete" =
"erase". In fact, in MSDOS the "DEL" and "ERASE" commands are
interchangeable.)
My comments might not be technically correct; I'm an accountant, not a
techie of any kind. But I think they are close enough for the current
discussion.
RC
--
R. C. White, CPA
San Marcos, TX
(e-mail address removed)
Microsoft Windows MVP (2002-2010)
Windows Live Mail 2011 (Build 15.4.3555.0308) in Win7 Ultimate x64 SP1
If you wish to experiment with theories involving the pagefile,
you can use a utility called "nfi.exe". It works with NTFS file
systems. And lists just about everything that's on the partition.
This is the location of the pagefile, on my Windows 7 laptop. I
haven't checked to see if it's moved. The three listing files I've just
consulted, were created over a wide range of times. And since
I was experimenting with CHKDSK (the RAM buster), the pagefile
might have been affected by that at some point.
This one isn't fragmented.
File 6895
\pagefile.sys
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 39969968-45726687 (0x261e4b0-0x2b9bbdf)
I found another listing created by that tool, and it had this
strange entry in it. It's fragmented. And the implication is,
this is compressed. Why exactly, you'd see a compressed
pagefile, isn't clear to me. That's not an ideal way for an
OS to work. You want an uncompressed container for that,
for speed reasons. I don't see a reason for me to have
done this, and this is the only "pagefile" type entry
in the entire listing.
File 662
\pagefile.sys.gz
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$SECURITY_DESCRIPTOR (resident)
$DATA (nonresident)
logical sectors 19192336-19192463 (0x124da10-0x124da8f)
logical sectors 19398656-19407263 (0x1280000-0x128219f)
From another listing. Not sure of the dates of when these
files were created. One could be pre-SP1, the others post-SP1.
File 62717
\pagefile.sys
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 39969984-45726703 (0x261e4c0-0x2b9bbef)
Hmmm. I just noticed the "File number" is different, in listing #1
and listing #3, but the sectors occupied are the same.
What does that mean exactly ? Am I getting warmer ?
Without doing any controlled testing, it looks like that
pagefile has been around. In some sense.
If you use the registry setting "ClearPageFileAtShutdown"
though, you have nothing to worry about. As the file will
be zeroed, just before final shutdown. So even if it moves later
(on next boot), you're covered.
Paul