Fixing pagefile.sys from recovery console???

[surface9]

I tried a simple but involved method of backing up my windows 2000
(sp4) system. I installed my main win2k system to Drive XXX and
installed all my drivers and got connected to the internet and, after
I got it all working OK, I created a backup to DRIVE ZZZ connected as
a USB drive. The actual method (which works for XP), is to install
just the basic windows 2000 sp4 system to a seperate drive YYY, and,
then, boot to DRIVE YYY using the SYSTEM menu's during POST to select
which harddrive for booting. After I get booted up to DRIVE YYY
(which is only the basic win2k with only the USB driver installed
extra), then I can see DRIVE XXX (as drive E and then I connect
DRIVE ZZZ as USB DRIVE F: Then I use the xcopy command to copy the
entire h/d from E to F as follows:

xcopy E:\*.* F:\*.* /s/e/c/h/o/y

This method works for XP, and it seems to work for win2k also, but, I
discovered that when I try to boot to my backup ZZZ, I have to first
go into the Recovery Console (booting from the Win2k CD), and then
execture FIXBOOT in order for the PC to go ahead and boot to ZZZ. But
then, when it gets to the point where it is going to put up the
desktop (with the intro sound clip), it shows a message dialogue
telling me there is not enough virtual memory, and giving me
instructions on how to increase the page file - but those instructions
require that I have a desktop so I can right-click on "My Computer".
Here is where it gets into an infinite loop of making the intro sound
clip, putting up the error message, and, when I click OK, it repeats
endlessly.

So, how can I use the recovery console to make sure the pagefile.sys
is set up correctly. I can examine the backup disk (ZZZ) and it does
have a pagefile.sys which is exactly the same size as the one on XXX,
so, I am thinking it must be something flaky. Drive XXX and Drive ZZZ
are both the same make, model, and size, but have different VOLIDS,
but, when I used the same VOLID for ZZZ as for XXX, it still got
caught in that endless loop about pagefile.sys.

Since I have used this technique many times to create backups for XP,
and I have also restored from these backups successfully (in XP), I am
wondering what is different about win2k and how can I fix the
pagefile.sys problem so I can go ahead and boot from my backup
(ZZZ).

The reason I want to avoid having to re-install win2k here is because
it always means I have to call AT&T to get my DSL working again and
that is a tortuous experience (takes over 2 hours with someone who
usually speaks with such a thick accent I can hardly understand what
they are saying).

How can I fix that pagefile.sys problem on my backup ZZZ drive?

 

[Pegasus [MVP]]

I tried a simple but involved method of backing up my windows 2000
(sp4) system. I installed my main win2k system to Drive XXX and
installed all my drivers and got connected to the internet and, after
I got it all working OK, I created a backup to DRIVE ZZZ connected as
a USB drive. The actual method (which works for XP), is to install
just the basic windows 2000 sp4 system to a seperate drive YYY, and,
then, boot to DRIVE YYY using the SYSTEM menu's during POST to select
which harddrive for booting. After I get booted up to DRIVE YYY
(which is only the basic win2k with only the USB driver installed
extra), then I can see DRIVE XXX (as drive E and then I connect
DRIVE ZZZ as USB DRIVE F: Then I use the xcopy command to copy the
entire h/d from E to F as follows:

xcopy E:\*.* F:\*.* /s/e/c/h/o/y

This method works for XP, and it seems to work for win2k also, but, I
discovered that when I try to boot to my backup ZZZ, I have to first
go into the Recovery Console (booting from the Win2k CD), and then
execture FIXBOOT in order for the PC to go ahead and boot to ZZZ. But
then, when it gets to the point where it is going to put up the
desktop (with the intro sound clip), it shows a message dialogue
telling me there is not enough virtual memory, and giving me
instructions on how to increase the page file - but those instructions
require that I have a desktop so I can right-click on "My Computer".
Here is where it gets into an infinite loop of making the intro sound
clip, putting up the error message, and, when I click OK, it repeats
endlessly.

So, how can I use the recovery console to make sure the pagefile.sys
is set up correctly. I can examine the backup disk (ZZZ) and it does
have a pagefile.sys which is exactly the same size as the one on XXX,
so, I am thinking it must be something flaky. Drive XXX and Drive ZZZ
are both the same make, model, and size, but have different VOLIDS,
but, when I used the same VOLID for ZZZ as for XXX, it still got
caught in that endless loop about pagefile.sys.

Since I have used this technique many times to create backups for XP,
and I have also restored from these backups successfully (in XP), I am
wondering what is different about win2k and how can I fix the
pagefile.sys problem so I can go ahead and boot from my backup
(ZZZ).

The reason I want to avoid having to re-install win2k here is because
it always means I have to call AT&T to get my DSL working again and
that is a tortuous experience (takes over 2 hours with someone who
usually speaks with such a thick accent I can hardly understand what
they are saying).

How can I fix that pagefile.sys problem on my backup ZZZ drive?

You write "I tried a simple but involved method of backing up my windows
2000". You're contradicting yourself: The method can't be simple and
involved at the same time. Reading your post I'd say it is extremely
involved and it is about as clear as mud. Here are two simple methods to
back up a Windows installations. Both of them work:

a) By using an imaging program such as Acronis TrueImage.
b) By booting the machine with a Bart PE boot CD (or similar), then using
xcopy.exe or robocopy.exe to copy all files (including hidden files!) to the
backup medium.

I recommend you look at one of these methods for your backup process.

 

[surface9]

You write "I tried a simple but involved method of backing up my windows
2000". You're contradicting yourself: The method can't be simple and
involved at the same time. Reading your post I'd say it is extremely
involved and it is about as clear as mud. Here are two simple methods to
back up a Windows installations. Both of them work:

a) By using an imaging program such as Acronis TrueImage.
b) By booting the machine with a Bart PE boot CD (or similar), then using
xcopy.exe or robocopy.exe to copy all files (including hidden files!) to the
backup medium.

I recommend you look at one of these methods for your backup process.

I tried several times to create a Bart CD before but couldn't get it
to work - it would go through all the steps and then not boot. I
finally gave up. I can use an imaging method (I use H2COPY) which
does work but requires several hours to complete. The method I wanted
to use works very well with XP and I was wondering why it has problems
with Win2k. It is involved, but, once you get it down, it is very
simple. It requires 3 hard drives (which are very cheap these days).
The main hard drive XXX is where you go to the trouble of installing
the system fresh with all drivers, applications, and connections. The
2nd hard drive YYY is just a "working" installation of Win2k that will
be used to execute the xcopy command (you cannot use xcopy for copying
the very system that you boot from). The third harddrive is ZZZ which
is the target of the xcopy (a clone of XXX). When I install XP on
XXX, then I can use YYY (which has win2k) to execute the xcopy over to
ZZZ, and ZZZ can be booted and works and can also be xcopied back onto
XXX should XXX get infected and need restoring. I have done this for
years and it works flawlessly - what happened to me this time was that
both my main XXX and my backup ZZZ failed at the same time (they were
both very old h/d's and I should have known better - live and learn).

I realize from your post you don't think much of this method of backup/
restore, but, for XP, it works very well, is quick (a few mintues at
most), and puts your main drive XXX right back to the state it was in
when the original xcopy was executed. I have a seperate XP machine
and I never have to worry about viruses because I can restore it to
its original fully installed state within 15 minutes. It doesn't
requies any fix to the pagefile.sys or anything else - just do the
xcopy backwards and i'm good to go. I don't understand why
pagefile.sys is different for win2k.

My question on here has to do with fixing the pagefile.sys problem - I
was hoping there was some command from the repair console that I could
use to do that.

 

[Pegasus [MVP]]

You write "I tried a simple but involved method of backing up my windows
2000". You're contradicting yourself: The method can't be simple and
involved at the same time. Reading your post I'd say it is extremely
involved and it is about as clear as mud. Here are two simple methods to
back up a Windows installations. Both of them work:

a) By using an imaging program such as Acronis TrueImage.
b) By booting the machine with a Bart PE boot CD (or similar), then using
xcopy.exe or robocopy.exe to copy all files (including hidden files!) to
the
backup medium.

I recommend you look at one of these methods for your backup process.

I tried several times to create a Bart CD before but couldn't get it
to work - it would go through all the steps and then not boot. I
finally gave up. I can use an imaging method (I use H2COPY) which
does work but requires several hours to complete. The method I wanted
to use works very well with XP and I was wondering why it has problems
with Win2k. It is involved, but, once you get it down, it is very
simple. It requires 3 hard drives (which are very cheap these days).
The main hard drive XXX is where you go to the trouble of installing
the system fresh with all drivers, applications, and connections. The
2nd hard drive YYY is just a "working" installation of Win2k that will
be used to execute the xcopy command (you cannot use xcopy for copying
the very system that you boot from). The third harddrive is ZZZ which
is the target of the xcopy (a clone of XXX). When I install XP on
XXX, then I can use YYY (which has win2k) to execute the xcopy over to
ZZZ, and ZZZ can be booted and works and can also be xcopied back onto
XXX should XXX get infected and need restoring. I have done this for
years and it works flawlessly - what happened to me this time was that
both my main XXX and my backup ZZZ failed at the same time (they were
both very old h/d's and I should have known better - live and learn).

I realize from your post you don't think much of this method of backup/
restore, but, for XP, it works very well, is quick (a few mintues at
most), and puts your main drive XXX right back to the state it was in
when the original xcopy was executed. I have a seperate XP machine
and I never have to worry about viruses because I can restore it to
its original fully installed state within 15 minutes. It doesn't
requies any fix to the pagefile.sys or anything else - just do the
xcopy backwards and i'm good to go. I don't understand why
pagefile.sys is different for win2k.

My question on here has to do with fixing the pagefile.sys problem - I
was hoping there was some command from the repair console that I could
use to do that.
=========
Here is the standard method to clone a disk without using an imaging
product:
1. Get your three disks ready:
Disk1=An auxiliary Windows installation.
Disk2=Your source disk.
Disk3=Your target disk.
2. Connect Disk1 as the primary master disks, the others as slave disks.
3. Boot the machine from Disk1.
4. Partition & format Disk3 if necessary.
5. Mark its primary partition active.
6. Use robocopy.exe to copy Disk2 to Disk3.
7. Disconnect all disks.
8. Make Disk3 the primary master. Do NOT leave Disk2 connected!

Windows XP or Windows 2000 will now boot normally. If your current target
installation has a problem with the paging file then you did not follow the
above recipe. You're in a good position to say what you did differently.

 

[BillW50]

In Pegasus [MVP] typed on Thu, 24 Sep 2009 20:11:35 +0200:

I tried several times to create a Bart CD before but couldn't get it
to work - it would go through all the steps and then not boot. I
finally gave up. I can use an imaging method (I use H2COPY) which
does work but requires several hours to complete. The method I wanted
to use works very well with XP and I was wondering why it has problems
with Win2k. It is involved, but, once you get it down, it is very
simple. It requires 3 hard drives (which are very cheap these days).
The main hard drive XXX is where you go to the trouble of installing
the system fresh with all drivers, applications, and connections. The
2nd hard drive YYY is just a "working" installation of Win2k that will
be used to execute the xcopy command (you cannot use xcopy for copying
the very system that you boot from). The third harddrive is ZZZ which
is the target of the xcopy (a clone of XXX). When I install XP on
XXX, then I can use YYY (which has win2k) to execute the xcopy over to
ZZZ, and ZZZ can be booted and works and can also be xcopied back onto
XXX should XXX get infected and need restoring. I have done this for
years and it works flawlessly - what happened to me this time was that
both my main XXX and my backup ZZZ failed at the same time (they were
both very old h/d's and I should have known better - live and learn).

I realize from your post you don't think much of this method of
backup/ restore, but, for XP, it works very well, is quick (a few
mintues at most), and puts your main drive XXX right back to the
state it was in when the original xcopy was executed. I have a
seperate XP machine
and I never have to worry about viruses because I can restore it to
its original fully installed state within 15 minutes. It doesn't
requies any fix to the pagefile.sys or anything else - just do the
xcopy backwards and i'm good to go. I don't understand why
pagefile.sys is different for win2k...

I do. Sounds like surface9 (OP) is trying to boot from an USB drive
which is a copy. Although a copy is fine. Although it needs a MBR and
the boot.ini needs repair. But then trying to boot from the USB won't
work without lots of work. As Windows will get confused when the USB
ports gets reset in the middle of booting and it will continue using
Windows from a different drive and it will really be confused. So if
this is the case, patch Windows so it *can* boot from USB. Or totally
give up the idea of booting from an USB in the first place.

 

[surface9]

I tried several times to create a Bart CD before but couldn't get it
to work - it would go through all the steps and then not boot.  I
finally gave up.  I can use an imaging method (I use H2COPY) which
does work but requires several hours to complete.  The method I wanted
to use works very well with XP and I was wondering why it has problems
with Win2k.  It is involved, but, once you get it down, it is very
simple.  It requires 3 hard drives (which are very cheap these days).
The main hard drive XXX is where you go to the trouble of installing
the system fresh with all drivers, applications, and connections.  The
2nd hard drive YYY is just a "working" installation of Win2k that will
be used to execute the xcopy command (you cannot use xcopy for copying
the very system that you boot from).  The third harddrive is ZZZ which
is the target of the xcopy (a clone of XXX).  When I install XP on
XXX, then I can use YYY (which has win2k) to execute the xcopy over to
ZZZ, and ZZZ can be booted and works and can also be xcopied back onto
XXX should XXX get infected and need restoring.  I have done this for
years and it works flawlessly - what happened to me this time was that
both my main XXX and my backup ZZZ failed at the same time (they were
both very old h/d's and I should have known better - live and learn).

I realize from your post you don't think much of this method of backup/
restore, but, for XP, it works very well, is quick (a few mintues at
most), and puts your main drive XXX right back to the state it was in
when the original xcopy was executed.  I have a seperate XP machine
and I never have to worry about viruses because I can restore it to
its original fully installed state within 15 minutes.  It doesn't
requies any fix to the pagefile.sys or anything else - just do the
xcopy backwards and i'm good to go.  I don't understand why
pagefile.sys is different for win2k.

My question on here has to do with fixing the pagefile.sys problem - I
was hoping there was some command from the repair console that I could
use to do that.
=========
Here is the standard method to clone a disk without using an imaging
product:
1. Get your three disks ready:
    Disk1=An auxiliary Windows installation.
    Disk2=Your source disk.
    Disk3=Your target disk.
2. Connect Disk1 as the primary master disks, the others as slave disks.
3. Boot the machine from Disk1.
4. Partition & format Disk3 if necessary.
5. Mark its primary partition active.
6. Use robocopy.exe to copy Disk2 to Disk3.
7. Disconnect all disks.
8. Make Disk3 the primary master. Do NOT leave Disk2 connected!

Windows XP or Windows 2000 will now boot normally. If your current target
installation has a problem with the paging file then you did not follow the
above recipe. You're in a good position to say what you did differently.

These 8 steps are pretty much what I am doing except a) disk3 is
connected as a USB during the copy command, and b) I use xcopy instead
of robocopy. I have never heard of robocopy but I will go now and see
what I can find out about it. I am not trying to boot to a USB - I do
just what those 8 steps say and then I try to boot from my backup
(disk3), after the xcopy completes, but mounting it as the primary
with no other disks present. It says it is not-bootable, but, I then
boot to my Win2k CD and run FIXBOOT from the repair console, and then
boot to Disk3 again and it goes OK, until it is ready to bring up the
desktop - then it goes into the infinite loop about the pagefile.sys
being too small or not present - I check this Disk3 by booting to a
DOS disk and looking to see that there is infact a pagefile.sys file
and it is the exact same size as the original one (Disk2 from the 8
steps above). If robocopy works better then xcopy, then that will
solve my problem, but, I am still wondering why the xcopy method works
for XP and not for Win2k.

 

[BillW50]

In
surface9 typed on Thu, 24 Sep 2009 21:41:10 -0700 (PDT):

... but, I am still wondering why the xcopy method works
for XP and not for Win2k.

Being a user of both Windows 2000 and XP and running without pagefiles,
Windows 2000 complains loudly if there isn't a pagefile or it is too
small. While Windows XP doesn't care if you have one or not. So I can
see that.

If it makes you feel any better, I like to use BartPE and A43 (free file
manager) to copy all of the files and folders. Works perfectly under XP.
With the exception if MS Works v9 is installed. As the copied versions
will not run Works anymore.

 

[Sid Elbow]

These 8 steps are pretty much what I am doing except a) disk3 is
connected as a USB during the copy command, and b) I use xcopy instead
of robocopy. I have never heard of robocopy but I will go now and see
what I can find out about it. I am not trying to boot to a USB - I do
just what those 8 steps say and then I try to boot from my backup
(disk3), after the xcopy completes, but mounting it as the primary
with no other disks present. It says it is not-bootable, but, I then
boot to my Win2k CD and run FIXBOOT from the repair console, and then
boot to Disk3 again and it goes OK, until it is ready to bring up the
desktop - then it goes into the infinite loop about the pagefile.sys
being too small or not present - I check this Disk3 by booting to a
DOS disk and looking to see that there is infact a pagefile.sys file
and it is the exact same size as the original one (Disk2 from the 8
steps above). If robocopy works better then xcopy, then that will
solve my problem, but, I am still wondering why the xcopy method works
for XP and not for Win2k.

Someone here might correct me on this but I seem to recall that, if the
pagefile is truly missing (i.e. doesn't exist) at boot time, Win2K
recreates it and goes on its merry way. In which case, the solution to
your problem would seem to be to not include the pagefile in your
backup/restore at all.

I don't know why this is happening although I suspect it may have to do
with the fact that the pagefile is a "special" file that Windows treats
differently from other files, probably accessing it directly rather than
through the regular filesystem (for speed) and it may need to know
exactly where it is on the drive/partition. (None of the defrag programs
that I have seen will move the swap file on the drive although they will
defrag it internally at boot time). If that is so, then backup/restore
using XCopy could restore the swap file to a different disk location and
Windows may well complain.

As for it working with XP - well, we know from recent threads here that
XP pagefile handling differs from Win2K - certainly in the sense that XP
will work with no pagefile at whereas Win2K demands at least a minimal
pagefile. Perhaps there are other differences that make XP more "robust"
in this respect.

Frankly, I think your backup method is .... well, masochistic And I
think if you tried a backup application such as Ghost or Acronis in
combination with a (single) USB drive, you'd look back and agree. There
is also a backup application - Rebit - which I'm trying out right now.
It runs in the background, backs up to a USB drive and keeps multiple
versions of modified files so you have a choice of files to restore. The
penalty for running in the background doesn't seem (so far) to be
severe. The USB backup drive is also plug-and-play on any machine (if
you have multiple licences). The only downside I've found is that it
won't let you backup individual partitions .... at least not on the boot
drive. It's the whole drive or nothing.

Whatever suits you though. Another thing you could consider, if you
continue with the XCopy/many-drive/fixboot method is to move the
pagefile to the second hard drive if you have one. Then it doesn't enter
into the scheme at all when you are backing up the boot drive.

 

[Pegasus [MVP]]

These 8 steps are pretty much what I am doing except a) disk3 is
connected as a USB during the copy command, and b) I use xcopy instead
of robocopy. I have never heard of robocopy but I will go now and see
what I can find out about it. I am not trying to boot to a USB - I do
just what those 8 steps say and then I try to boot from my backup
(disk3), after the xcopy completes, but mounting it as the primary
with no other disks present. It says it is not-bootable, but, I then
boot to my Win2k CD and run FIXBOOT from the repair console, and then
boot to Disk3 again and it goes OK, until it is ready to bring up the
desktop - then it goes into the infinite loop about the pagefile.sys
being too small or not present - I check this Disk3 by booting to a
DOS disk and looking to see that there is infact a pagefile.sys file
and it is the exact same size as the original one (Disk2 from the 8
steps above). If robocopy works better then xcopy, then that will
solve my problem, but, I am still wondering why the xcopy method works
for XP and not for Win2k.

============

Let's ignore for a moment the method you use to back up your installation
and concentrate on the actual paging file problem. The phenomenon you
observe may have two causes:
a) Your System drive letter is incorrect, or
b) The paging file pointer in the registry is invalid.

You can fix either or both of them by doing this:
- Launch your auxiliary version of Win2000.
- Create a backup of the System registry file of the problem installation.
- Using regedt32.exe to load the System hive of the problem installation.
- Examine HKLM\System\MountedDevices\DosDevices. Instead of DosDevices\C:,
it might have DosDevices\E:. If so then you need to change it back to C:.
- Examine HKLM\System\CurrentControlSet\Control\Session Manager\Memory
Management. Does the value "PagingFiles" point to a valid location?

 

[surface9]

These 8 steps are pretty much what I am doing except a) disk3 is
connected as a USB during the copy command, and b) I use xcopy instead
of robocopy.  I have never heard of robocopy but I will go now and see
what I can find out about it.  I am not trying to boot to a USB - I do
just what those 8 steps say and then I try to boot from my backup
(disk3), after the xcopy completes, but mounting it as the primary
with no other disks present.  It says it is not-bootable, but, I then
boot to my Win2k CD and run FIXBOOT from the repair console, and then
boot to Disk3 again and it goes OK, until it is ready to bring up the
desktop - then it goes into the infinite loop about the pagefile.sys
being too small or not present - I check this Disk3 by booting to a
DOS disk and looking to see that there is infact a pagefile.sys file
and it is the exact same size as the original one (Disk2 from the 8
steps above).  If robocopy works better then xcopy, then that will
solve my problem, but, I am still wondering why the xcopy method works
for XP and not for Win2k.

============

Let's ignore for a moment the method you use to back up your installation
and concentrate on the actual paging file problem. The phenomenon you
observe may have two causes:
a) Your System drive letter is incorrect, or
b) The paging file pointer in the registry is invalid.

You can fix either or both of them by doing this:
- Launch your auxiliary version of Win2000.
- Create a backup of the System registry file of the problem installation..
- Using regedt32.exe to load the System hive of the problem installation.
- Examine HKLM\System\MountedDevices\DosDevices. Instead of DosDevices\C:,
it might have DosDevices\E:. If so then you need to change it back to C:.
- Examine HKLM\System\CurrentControlSet\Control\Session Manager\Memory
Management. Does the value "PagingFiles" point to a valid location?

I got a copy of robocopy and I will try to use it later, but, first, I
would like to use the regedt32 method.

I don't know how to create a backup of the system registry for the
problem installation, since I am booting to my auxillary system and
when I run regedt32, it comes up with the registry for that system - I
don't see any method for me to switch over to the registry for the
backup h/d (the target of the xcopy), which you are calling the
"problem installation". When I use "load hive", it asks me for a
file, but, I don't have a file to load since I can't get into the
registry of the problem installation - there must be some way to gain
access to this problem installation registry, but, since I can't boot
to it, then I am stuck - I'll look around but if you know what
switches or technique I can use for backing up the registry of a
system that you are NOT booting to, please advise. I am suspecting
that this method will solve my problem, after I find out how to get at
it. I am connecting the problem installation as a USB drive and I am
able to see it using windows explorer (it comes up as drive E, so, I
just need a little techie help here getting at its registry.

 

[surface9]

I got a copy of robocopy and I will try to use it later, but, first, I
would like to use the regedt32 method.

I don't know how to create a backup of the system registry for the
problem installation, since I am booting to my auxillary system and
when I run regedt32, it comes up with the registry for that system - I
don't see any method for me to switch over to the registry for the
backup h/d (the target of the xcopy), which you are calling the
"problem installation".  When I use "load hive", it asks me for a
file, but, I don't have a file to load since I can't get into the
registry of the problem installation - there must be some way to gain
access to this problem installation registry, but, since I can't boot
to it, then I am stuck - I'll look around but if you know what
switches or technique I can use for backing up the registry of a
system that you are NOT booting to, please advise.  I am suspecting
that this method will solve my problem, after I find out how to get at
it.  I am connecting the problem installation as a USB drive and I am
able to see it using windows explorer (it comes up as drive E, so, I
just need a little techie help here getting at its registry.

Just for practice, I just now examined those keys (you cited above)
for the registry of my main (source) system:

It has 5 entries for DosDevices (for A, C, D, E, and F).

The entry for memory management is as follows:
PagingFiles: REG_MULTI_SZ: C;\pagefile.sys 1536 3072...

I am eager to compare these to the problem installation registry as
soon as I figure out how to get at it.

 

[Pegasus [MVP]]

I got a copy of robocopy and I will try to use it later, but, first, I
would like to use the regedt32 method.

I don't know how to create a backup of the system registry for the
problem installation, since I am booting to my auxillary system and
when I run regedt32, it comes up with the registry for that system - I
don't see any method for me to switch over to the registry for the
backup h/d (the target of the xcopy), which you are calling the
"problem installation". When I use "load hive", it asks me for a
file, but, I don't have a file to load since I can't get into the
registry of the problem installation - there must be some way to gain
access to this problem installation registry, but, since I can't boot
to it, then I am stuck - I'll look around but if you know what
switches or technique I can use for backing up the registry of a
system that you are NOT booting to, please advise. I am suspecting
that this method will solve my problem, after I find out how to get at
it. I am connecting the problem installation as a USB drive and I am
able to see it using windows explorer (it comes up as drive E, so, I
just need a little techie help here getting at its registry.

Just for practice, I just now examined those keys (you cited above)
for the registry of my main (source) system:

It has 5 entries for DosDevices (for A, C, D, E, and F).

The entry for memory management is as follows:
PagingFiles: REG_MULTI_SZ: C;\pagefile.sys 1536 3072...

I am eager to compare these to the problem installation registry as
soon as I figure out how to get at it.
=============
First the easy bit: You have a problem with your paging file location.
Instead of
C;\pagefile.sys
it should be
C:\pagefile.sys
If that's what it already is then I recommend you be extremely careful when
hacking the registry. Typographical errors like this one can cause a lot of
trouble.

About creating a backup of the System hive: Use the copy command or Windows
Explorer to copy X:\winnt\system32\config\system to some backup location
where X: is the drive letter of your problem installation. It is as simple
as this!

About using regedt32.exe:
1. Launch regedt32.exe.
2. Click the hive you're interested in, e.g. HKLM.
3. Click "Registry", then "Open Hive".
4. Specify your file name, e.g. "X:\winnt\system32\config\system".
5. Give the baby a name, e.g. "Surface".
6. Click the + to the left of "Surface".
7. Navigate to the keys I mentioned previously.
8. When finished, click Surface, then File/Unload hive.
(I quote Step 8 from memory since I am not currently in front of a Win2000
PC).

If you had a Bart PE boot CD then you could use regedit.exe, which is much
easier to use.

 

[surface9]

Just for practice, I just now examined those keys (you cited above)
for the registry of my main (source) system:

It has 5 entries for DosDevices  (for A, C,  D,  E, and F).

The entry for memory management is as follows:
 PagingFiles:  REG_MULTI_SZ: C;\pagefile.sys  1536  3072...

I am eager to compare these to the problem installation registry as
soon as I figure out how to get at it.
=============
First the easy bit: You have a problem with your paging file location.
Instead of
C;\pagefile.sys
it should be
C:\pagefile.sys
If that's what it already is then I recommend you be extremely careful when
hacking the registry. Typographical errors like this one can cause a lot of
trouble.

About creating a backup of the System hive: Use the copy command or Windows
Explorer to copy X:\winnt\system32\config\system to some backup location
where X: is the drive letter of your problem installation. It is as simple
as this!

About using regedt32.exe:
1. Launch regedt32.exe.
2. Click the hive you're interested in, e.g. HKLM.
3. Click "Registry", then "Open Hive".
4. Specify your file name, e.g. "X:\winnt\system32\config\system".
5. Give the baby a name, e.g. "Surface".
6. Click the + to the left of "Surface".
7. Navigate to the keys I mentioned previously.
8. When finished, click Surface, then File/Unload hive.
(I quote Step 8 from memory since I am not currently in front of a Win2000
PC).

If you had a Bart PE boot CD then you could use regedit.exe, which is much
easier to use.

I was able to create the hive for the backup and load it into regedt32
and to my suprise all the entites mentioned above are exactly
identical to the primary system. (I am sure I was viewing the backup
because I gave it an unusual name XXXX) The only thing that makes me
wonder is under dosdevices, each of the letters has a series of two
digit numbers behind them - if that designates a serial number for the
H/D, then that might be a problem because the one for DosDevices\C
would be to the primary h/d and NOT the backup - but, I don't even
know what those numbers mean. The pagefile.sys was exactly the same,
so, unless there is something else to check, it looks like I'll need
to just go ahead and use ROBOCOPY, which will overwrite my current
backup that I can't seem to get past the pagefile.sys problem anyway.

One other thought - could it be that the system under which you are
performing the copy must be DIFFERENT from the system you are
copying? When I backup my XP system, I am using windows 2000 as my
auxillary boot, so the xcopy command is being run under Win2000 but
against XP as both the source and target. Maybe that is why it works,
and, for me to be able to use win2000 as a source and target, I might
need to create an auxillary bootable h/d with XP (just to make it a
different system while performing the xcopy).

So much confusion - I really wish there was something I could do from
the repair console to fix the problem, but, alas, it seems to be well-
hidden.

 

[Pegasus [MVP]]

See *** inline.


I was able to create the hive for the backup and load it into regedt32
and to my suprise all the entites mentioned above are exactly
identical to the primary system. (I am sure I was viewing the backup
because I gave it an unusual name XXXX) The only thing that makes me
wonder is under dosdevices, each of the letters has a series of two
digit numbers behind them - if that designates a serial number for the
H/D, then that might be a problem because the one for DosDevices\C
would be to the primary h/d and NOT the backup - but, I don't even
know what those numbers mean.
*** You will find the same binary value further up under the same key
*** where it is recorded against a value of the form \\??\Volume\4ef01...
*** This in turn is the partition volume label that you see when you
*** run the command mountvol.exe from a Command Prompt. No
*** need to worry about it - Windows will usually sort itself out if the
*** values do not match the current partitions. However, "usually" is
*** not always. To find out if your drive letters are correct, do this:
*** 1. Run this command from a networked machine while running
*** the problem version of Windows:
*** psexec.exe \\ProblemPC cmd
*** 2. Check the drive letter you see. Is it C:?
*** You can get psexec.exe from www.sysinternals.com.

The pagefile.sys was exactly the same, so, unless there is
something else to check, it looks like I'll need to just go ahead
and use ROBOCOPY, which will overwrite my current backup
that I can't seem to get past the pagefile.sys problem anyway.

One other thought - could it be that the system under which you are
performing the copy must be DIFFERENT from the system you are
copying? When I backup my XP system, I am using windows 2000 as my
auxillary boot, so the xcopy command is being run under Win2000 but
against XP as both the source and target. Maybe that is why it works,
and, for me to be able to use win2000 as a source and target, I might
need to create an auxillary bootable h/d with XP (just to make it a
different system while performing the xcopy).
*** A copy is a copy is a copy, regardless of the operating system.

So much confusion - I really wish there was something I could do from
the repair console to fix the problem, but, alas, it seems to be well-
hidden.
*** The Bart PE boot CD is the ideal tool for this sort of work.

 

[surface9]

The first four pairs of hex numbers is the disk signature. In order
for the clone to work correctly, the disk signature in MountedDevices
has to be identical to the disk signature that is located in the MBR
of the clone disk.http://www.geocities.com/thestarman3/asm/mbr/Win2kmbr.htm

The easiest way to make this happen is to boot from a Windows 98
emergency boot disk, and run the fdisk /mbr command, which will zero
the existing disk signature. Then when Windows 2000 is booted, the
loader will see that the disk signature in the MBR is zero, change it
so it's not zero, and modify the disk signature fields in the registry
so they're identical to the MBR disk signature.

Another way is to use a program such as MBRWizard to change the disk
signature in the MBR so it agrees with the registry. This will make
the disk signature identical to the parent disk's, and if you connect
both disks to the computer, the disk signature in the MBR of one of
the disks will be changed when Windows is booted.

A third way is to modify the disk signature field in MountedDevices in
the registry of the clone so it matches the disk signature in its MBR.

Hallelujah!

FIxing the disk signature in the MBR of my backup solved the problem,
and, I am now booted up on my backup (primary being disconnected)
replying to this post on my backup. It turns out that the 4 digit
value in the MBR for the disk signature of the backup was not the same
as in the registry for Drive C, but was correct for Drive F (the
target when the xcopy was performed). So, I just used the disk editor
program (from starman, using your web refernce), DE (booted from DOS),
to write over this disk signature in the backup to match what is
already in the registry for drive C:, and, bingo!, it worked like a
champ. So, now, I am confident that I can xcopy this backup back onto
the primary (should the primary pick up a virus), and the registry
will already be correct so it should boot right up.

The only thing I still wonder about is why I had to run FIXMBR and
FIXBOOT (using the recovery console from booting with the win2k CD),
before the backup will boot. If I just run the xcopy from the source
to the backup and try to boot to the backup, it says it is a non-
bootable disk. Booting to the win2k CD and entering the repair
console and running fixmbr and fixboot solves that problem. Just
curious about it.

So, anyway, I can now put the backup on the shelf and be ready to
restore it anytime my primary gets infected. Thanks for the pointers.