Can't run PageDefrag in Windows 7

[Dave \Crash\ Dummy]

I am running 64 bit Windows 7 Ultimate, logged on with administrator
privileges. When I try to run pagedfrg.exe as administrator, I get this
error.

http://crash.thedatalist.com/temp/snapshot.htm

I have tried "Troubleshoot compatibility" to no avail.
I have the latest version of PageDefrag available on the Microsoft site,
version 2.32.

 

[Chuck]

I am running 64 bit Windows 7 Ultimate, logged on with administrator
privileges. When I try to run pagedfrg.exe as administrator, I get this
error.

http://crash.thedatalist.com/temp/snapshot.htm

I have tried "Troubleshoot compatibility" to no avail.
I have the latest version of PageDefrag available on the Microsoft site,
version 2.32.

I believe that your version runs on 32bit, not 64. At least that's what
the MS description indicates. I didn't see a version for 64bit.

 

[Dave \Crash\ Dummy]

I believe that your version runs on 32bit, not 64. At least that's
what the MS description indicates. I didn't see a version for 64bit.

Bummer. I thought the compatibility troubleshooter would fix that by
running it in XP mode. :-(

 

[Jeff Layman]

Bummer. I thought the compatibility troubleshooter would fix that by
running it in XP mode. :-(

Wouldn't you get more or less the same effect as defragging by setting the
pagefile size to a minimum (16Mb with my laptop), rebooting, then setting
the pagefile to the size you want, and rebooting again? I assume that Win7
would have to create space on the disk for the new pagefile, and that space
would be a completely defragmented pagefile.

 

[Ken Blake]

Wouldn't you get more or less the same effect as defragging by setting the
pagefile size to a minimum (16Mb with my laptop), rebooting, then setting
the pagefile to the size you want, and rebooting again? I assume that Win7
would have to create space on the disk for the new pagefile, and that space
would be a completely defragmented pagefile.

Fragmentation of the page file is really a non-issue. Since access to
the page file is random, it doesn't really matter at all if it's
fragmented.

 

[Mr2U]

Fragmentation of the page file is really a non-issue. Since access to
the page file is random, it doesn't really matter at all if it's
fragmented.

MS wrote a utilty to address a non-issue?

 

[Dave \Crash\ Dummy]

Fragmentation of the page file is really a non-issue. Since access to
the page file is random, it doesn't really matter at all if it's
fragmented.

I am more interested in defragging the registry than the pagefile.

 

[Ken Blake]

I am more interested in defragging the registry than the pagefile.

Same thing. Access to the registry is also random.

 

[R. C. White]

Hi, Ken.

I've noted that pagefile.sys is always dated today at the time that I turned
on the computer this morning. My understanding is that a new page file is
created each time the computer is restarted. It is started from scratch
each time, and probably in a different location. So defragging would be of
only transitory benefit anyhow, until the next restart.

Is that correct?

RC
--
R. C. White, CPA
San Marcos, TX
(e-mail address removed)
Microsoft Windows MVP
Windows Live Mail 2010 (15.3.2804.0607) in Win7 Ultimate x64)

"Ken Blake" wrote in message

I am more interested in defragging the registry than the pagefile.

Same thing. Access to the registry is also random.

 

[Ken Blake]

Hi, Ken.

I've noted that pagefile.sys is always dated today at the time that I turned
on the computer this morning. My understanding is that a new page file is
created each time the computer is restarted. It is started from scratch
each time, and probably in a different location. So defragging would be of
only transitory benefit anyhow, until the next restart.

Is that correct?

It sounds right to me, RC, but I'm not completely sure.

 

[Jeff Layman]

Hi, Ken.

I've noted that pagefile.sys is always dated today at the time that I
turned on the computer this morning. My understanding is that a new page
file is created each time the computer is restarted. It is started from
scratch each time, and probably in a different location. So defragging
would be of only transitory benefit anyhow, until the next restart.

Is there a pagefile.sys on a hard disk (from a Windows OS) when you boot
from a linux live CD and look at the C: drive? Or is it deleted when the
computer is turned off?

Is there a Windows utility which can be used to see exactly where any file
resides on a HD (including pagefile.sys)? If so, it would be interesting to
see where it is each time after a few reboots.

 

[R. C. White]

Hi, Jeff.

I've never used Linux, so I can't answer that part of your question.

The pagefile.sys is not normally deleted when the computer is turned off.
I've been dual-booting (multi-booting, usually) for a decade or more and I
often see lingering pagefile.sys entries in the Boot volumes for Windows
installations other than the one currently running. But, knowing that no
two Windows installations can be using the page file at the same time, I've
often set both Vista and Win7 (for example) to put their page file on Drive
E: (for example). So when Vista is booted on Drive V:, it creates and uses
E:\pagefile.sys; when Win7 is booted on Drive C:, it re-creates and uses
E:\pagefile.sys. This conserves disk space - but since my last HDD addition
(1 TB), I have more disk space than I need, so I don't bother with this
currently. If I ever spot a pagefile.sys with a date other than today, or a
time other than when I started the current session, then I know it is left
over from some previous session and will never be used again, so I can
safely delete it. If it ever is needed again, it will automatically be
re-created.

We can manage the size and location of pagefile.sys in each Windows
installation by going to the end of a long click-path:
Start | Control Panel | System | Advanced system settings | Advanced (You'll
need to furnish Administrator credentials to get past here) | (Performance)
Settings | Advanced | (Virtual memory) Change ... and Finally we see the
Virtual Memory page. Whew!

Here we can specify how much space Windows can use on each volume - or just
choose System managed size, which is what I've almost always used in Vista
and Win7.

Is there a Windows utility which can be used to see exactly where any file

resides on a HD (including pagefile.sys)?

Of course. Windows Explorer, after we've set Folder Options to show System
Files. Both pagefile.sys and hiberfil.sys will be on the Boot volume, by
default. We can change the location of pagefile.sys, as above, but unless
we disable Hibernation, its file will always be on the Boot volume
(normally, but not necessarily, Drive C. And, if we disable Hibernation,
we can delete the leftover hiberfil.sys file.

RC
--
R. C. White, CPA
San Marcos, TX
(e-mail address removed)
Microsoft Windows MVP
Windows Live Mail 2010 (15.3.2804.0607) in Win7 Ultimate x64)


"Jeff Layman" wrote in message

Hi, Ken.

I've noted that pagefile.sys is always dated today at the time that I
turned on the computer this morning. My understanding is that a new page
file is created each time the computer is restarted. It is started from
scratch each time, and probably in a different location. So defragging
would be of only transitory benefit anyhow, until the next restart.

Is there a pagefile.sys on a hard disk (from a Windows OS) when you boot
from a linux live CD and look at the C: drive? Or is it deleted when the
computer is turned off?

Is there a Windows utility which can be used to see exactly where any file
resides on a HD (including pagefile.sys)? If so, it would be interesting to
see where it is each time after a few reboots.

 

[Jeff Layman]

resides on a HD (including pagefile.sys)?

Of course. Windows Explorer, after we've set Folder Options to show
System Files. Both pagefile.sys and hiberfil.sys will be on the Boot
volume, by default. We can change the location of pagefile.sys, as above,
but unless we disable Hibernation, its file will always be on the Boot
volume (normally, but not necessarily, Drive C. And, if we disable
Hibernation, we can delete the leftover hiberfil.sys file.

Sorry, wasn't clear in what I meant. What I was interested in was a utility
which could tell you which sector(s) and track(s) a file occupied. I guess
this means something which could interrogate the master file table data at
any time, and show that information on the screen. I suppose that when a
defragmentation program analyzes the disk, it is doing part of this by
showing the defragmentation visually in a strip (or it did in XP - I'm not
sure how much info the Win7 equivalent shows).

 

[Bob I]

Hi, Ken.

I've noted that pagefile.sys is always dated today at the time that I
turned on the computer this morning. My understanding is that a new page
file is created each time the computer is restarted. It is started from
scratch each time, and probably in a different location. So defragging
would be of only transitory benefit anyhow, until the next restart.

Is that correct?

RC

Nope, you're looking at the Date Modified, enable Date Created to see
the correct info.

 

[R. C. White]

Hi, Bob.

That's interesting! Could you explain what those dates mean? Does this
change the practice I described? Does the page file move to a new location
on each restart?

RC
--
R. C. White, CPA
San Marcos, TX
(e-mail address removed)
Microsoft Windows MVP
Windows Live Mail 2010 (15.3.2804.0607) in Win7 Ultimate x64)


"Bob I" wrote in message

Hi, Ken.

I've noted that pagefile.sys is always dated today at the time that I
turned on the computer this morning. My understanding is that a new page
file is created each time the computer is restarted. It is started from
scratch each time, and probably in a different location. So defragging
would be of only transitory benefit anyhow, until the next restart.

Is that correct?

RC

Nope, you're looking at the Date Modified, enable Date Created to see
the correct info.

 

[Guest]

re-format your computer and install open source linux ubuntu, just fyi,
thread closed!

 

[Char Jackson]

Hi, Bob.

That's interesting! Could you explain what those dates mean? Does this
change the practice I described? Does the page file move to a new location
on each restart?

The pagefile is just a scratch pad, a dummy file that contains
temporary data. The OS maintains pointers to that data, and those
pointers are only valid for the duration of the current Windows
session. During every system boot those pointers are cleared and the
system starts fresh. At that moment, the pagefile still contains lots
of data, (only the pointers were cleared), but it is data from a
previous Windows session and is invalid in the current session and
therefore is not used.**

The pagefile never physically moves and doesn't routinely get deleted
or recreated. It's created once, then it's reused over and over again.
If you let Windows manage the size of the pagefile, it will
dynamically grow (and theoretically shrink), as needed, and there lies
the possible rub.

When Windows needs to grow the pagefile, some number of days, weeks or
months after Windows was installed, it may find that the contiguous
disk blocks are already in use, so it will fragment the pagefile. It's
this physical fragmentation of the pagefile that can slow down access
to the contents of the pagefile.

An obvious method of preventing pagefile fragmentation is to remove
the pagefile (or temporarily move it to another drive or partition),
defragment the partition where you want the pagefile to reside, then
create a new pagefile, but this time manually set a minimum and
maximum size rather than letting Windows manage the size. Since the
pagefile will never shrink or grow, it cannot become fragmented.
Windows will alert you if the pagefile is too small, so there's little
or no danger from manually setting the size.

**If you boot a live Linux OS on your Windows system you can examine
the contents of the pagefile, looking for text strings and other
goodies. It's somewhat surprising to see what's typically stored in
there.

 

[J. D. Slocomb]

Nope, you're looking at the Date Modified, enable Date Created to see
the correct info.

From a cursory search it seems that the "pagefile" is just a name used
by MS for what other systems refer to as a "Swap File" - a place to
swap out some memory resident instructions or data to allow another
application to have more memory room. When the larger application is
terminated, or the second program gains access's to the CPU the data
is swapped back into memory.

If this is correct then when the computer is shut down the pagefile
data simply becomes redundant as the applications that used this data
are stopped.

In fact the system wilt run (usually) pretty well with no pagefile
whatsoever.

Cheers,

John D. Slocomb
(jdslocombatgmail)

 

[R. C. White]

Hi, Char.

Thanks for the explanation. It mostly fits with what I already knew.

Back in the day when 20 MB was a giant HDD and we were still using MS-DOS
and FAT(12) and Peter Norton really wrote Norton Utilities, especially
DiskEdit, I spent many tedious hours reading my disks, byte by byte. I was
amazed at how much "erased" data was still there. Nowadays, I seldom look
that closely at my disks, but I'm confident that many of my secrets that I
"deleted" months or even years ago are still there and readable by anyone
with the right tools (Yes, they are still available and some are built right
into Win7, as I'm sure you know.) and just a small amount of skill. (Even
before MS-DOS and hard drives, I did the same things on floppies with
SuperZap and other utilities for my TRS-80s. Aah...memories! <g> )

RC
--
R. C. White, CPA
San Marcos, TX
(e-mail address removed)
Microsoft Windows MVP
Windows Live Mail 2010 (15.3.2804.0607) in Win7 Ultimate x64)


"Char Jackson" wrote in message

Hi, Bob.

That's interesting! Could you explain what those dates mean? Does this
change the practice I described? Does the page file move to a new location
on each restart?

The pagefile is just a scratch pad, a dummy file that contains
temporary data. The OS maintains pointers to that data, and those
pointers are only valid for the duration of the current Windows
session. During every system boot those pointers are cleared and the
system starts fresh. At that moment, the pagefile still contains lots
of data, (only the pointers were cleared), but it is data from a
previous Windows session and is invalid in the current session and
therefore is not used.**

The pagefile never physically moves and doesn't routinely get deleted
or recreated. It's created once, then it's reused over and over again.
If you let Windows manage the size of the pagefile, it will
dynamically grow (and theoretically shrink), as needed, and there lies
the possible rub.

When Windows needs to grow the pagefile, some number of days, weeks or
months after Windows was installed, it may find that the contiguous
disk blocks are already in use, so it will fragment the pagefile. It's
this physical fragmentation of the pagefile that can slow down access
to the contents of the pagefile.

An obvious method of preventing pagefile fragmentation is to remove
the pagefile (or temporarily move it to another drive or partition),
defragment the partition where you want the pagefile to reside, then
create a new pagefile, but this time manually set a minimum and
maximum size rather than letting Windows manage the size. Since the
pagefile will never shrink or grow, it cannot become fragmented.
Windows will alert you if the pagefile is too small, so there's little
or no danger from manually setting the size.

**If you boot a live Linux OS on your Windows system you can examine
the contents of the pagefile, looking for text strings and other
goodies. It's somewhat surprising to see what's typically stored in
there.

 

[Dave \Crash\ Dummy]

Hi, Char.

Thanks for the explanation. It mostly fits with what I already knew.



Back in the day when 20 MB was a giant HDD and we were still using
MS-DOS and FAT(12) and Peter Norton really wrote Norton Utilities,
especially DiskEdit, I spent many tedious hours reading my disks,
byte by byte. I was amazed at how much "erased" data was still
there. Nowadays, I seldom look that closely at my disks, but I'm
confident that many of my secrets that I "deleted" months or even
years ago are still there and readable by anyone with the right tools
(Yes, they are still available and some are built right into Win7,
as I'm sure you know.) and just a small amount of skill. (Even
before MS-DOS and hard drives, I did the same things on floppies with
SuperZap and other utilities for my TRS-80s. Aah...memories! <g> )

Data is never deleted. Sectors are just marked as available. If they are
never used again, the data remains. So called disk cleaning software
just overwrites the sectors numerous times to make the original data
unreadable.

Peter Norton selling out to Symantec was like having Santa Claus die. :-(