Restoring GHO image to another partition

This is what I did step by step

• I imaged a full XP installation with drivers from a running Windows 7 with Norton Ghost's DOS version (can't remember the version number exactly) to a GHO file
• Restructured the HDD geometry from the scratch by deleting all the partitions & then creating new ones
• Experimentally restored the GHO image to the first primary partition

The result was: XP booted fine until the logon screen, but after entering the password, it stalled. The screen with an XP logo freezed for ever & HDD activity went up. The HD light was blinking continuously.

I understand that with the partitioning I've performed, the disk signature, the start sector, end sector, length of the drive where XP was initially installed & the drive letter - everything have been changed. Is there any way to make the restored XP work properly? Or should the backed system partition image always is to be restored to the EXACT partition where it was backed up from?

Its a known hassle, and a Backup Image should not necessarily be restored on the same partition number, letter or drive. There are several known ways to generalize a Win install sufficiently enough to be restored on a different drive or partition in the same or different PC.

One of simplest and most effective ways one could possibly try is using Paragon Hard Disk Manager or Backup & Recovery Suite trial CD, as it has Adjust Migrated OS (or similar) feature. Of course, it isn't that educational as other methods, but it works very well (even on its own within the same PC & hardware).

I understand that with the partitioning I've performed, the disk signature, the start sector, end sector, length of the drive where XP was initially installed & the drive letter - everything have been changed. Is there any way to make the restored XP work properly? Or should the backed system partition image always is to be restored to the EXACT partition where it was backed up from?

Then you should also have learned that you need to offline delete the contents of the mounteddevices key.

(as long as the partition is Active and Primary at boot time Windows XP should recreate the "right" entry for the C:\ partition, and for any other partition, as long as the drive letters weren't previously "forced" with a "non-standard" drive letter assignment)

I do have these dejavu feelings from time to time....
http://reboot.pro/11642/page__st__17

or learn how to create a proper one:
http://www.911cd.net...63
http://reboot.pro/11196/


Wonko

I wish that method to work every time, but from experience it doesn't at times, in particular when restoring to a different partition order, plus not to c:\ one. For example, when one wants to use a 3-d party bootloader from a Win7 1-st partition to boot a migrated WinXP on a 2-nd partition - the method might not work on its own. It appears to be misfortunately incomplete. Paragon works every time though, hence it may be interesting to decipher how exactly. The way it appears to fix the issue ("Select an (original before migration) drive letter"...then fix migrated OS) is purposely on-surface incomplete, but indicative of the approach.

I wish that method to work every time, but from experience it doesn't at times, in particular when restoring to a different partition order, plus not to c:\ one.

WHICH method?

I listed TWO of them, one may not work, the second should always. (if used properly )
And of course in case of non-standard drive letter assignments you may face some conflict and/or need further tweaks, typically beacause of this:
http://support.micro...kb/223188/en-us
WITHOUT first this:
http://support.micro...kb/249321/en-us



Wonko

Thanks for the links. Its an interesting topic to discuss, especially given significant modern drives dieing statistics, hence the need to migrate the OS in private settings (not business). I'll look into this info... It may help to clarify, what Paragon does as well.

Thanks for the links. Its an interesting topic to discuss, especially given significant modern drives dieing statistics, hence the need to migrate the OS in private settings (not business). I'll look into this info... It may help to clarify, what Paragon does as well.

Also, sometimes in a multi-partition, multi-disk environment it is possible to use some other trick to have the drive letters "standard assigned".
Example:
http://www.msfn.org/...setup-question/

In the "old" times before "advanced" partitioning/resizing/whatever tools were freely available, the planning of a partitioning scheme used to be a very important part of a setup.

But on "normal" "end user" hardware, usually you just clone the "WHOLE" hard disk, in case of a bigger hard disk, since the Registry entry is ONLY about:

• disk signature
• partition start LBA

you never have problems, you just create a bigger partition (which starts obviously at the same address) and replicate the disk signature and everything should work, also on those laptops that use a "Recovery" initial small partition, though in this case you have to be additionally careful because of the proprietary MBR CODE some of the main OEM use.

It is when you have "strange" settings (both on the "source" and "target") or while you do some semi-random experiments, like Holmes.Sherlock seems like doing, that you face problems.


Wonko

Not only "advanced tools" are now easier to find, but also the manner in which hard drives are used has notably changed. Its ordinary now to have several HDs employed, and once one of these starts showing failing signs, immediate intent is not to buy a replacement drive (it takes time and does require extra research given bad experience and a possible chance to repair), but to migrate existing setup on one of currently used drives temporarily, thus making the PC available for work. So this thread's question is quite timely, not unusual at all, as I recently faced the same problem.

Its ordinary now to have several HDs employed, and once one of these starts showing failing signs, immediate intent is not to buy a replacement drive (it takes time and does require extra research given bad experience and a possible chance to repair), but to migrate existing setup on one of currently used drives temporarily, thus making the PC available for work.

Yep, but if the device is time or mission critical, it should have an adequate (and easily swappable) setup and backup.

This is more likely to pertain to "business" use than "average Joe" one, but having NOT a very current image of ALL your hard disks is a good way to risk losing data.

I mean, I do have a particularly critical PC that is used/accessed 24/7, with a hard disk dedicated to "system" and one to "data", but I do have also an identical PC ready with two hard disk - as well identical to the ones in the "working" machine, kept synchronized via Network.
If anything fails, even the smallest thing, I simply swap one or the other hard disk (or actually put into service the "spare" PC) and in no more than 15 minutes everything is up and working again, with - in the very worst cases - a few minutes of work NOT replicated.

The "old" trick that anyone can use is to have ALL your hard disks have a smallish "system" partition as first one, hosting a "base" OS, that is booted to image/backup/restore the "main" System partition (that I usually have on a second partition.

More generally DATA is priceless, OS installs are NOT, a "normal" user can well spend some time into backing up data regularly and re-install (or repair install) the OS.

But nowadays buying drives in couples, have one in an external enclosure and dd the main one on it is something even the metioned "average Joe" can afford.

I am pretty convinced that a repair install from the SETUP media can recover a situation like described, but cannot swear by it.

My rule of thumb is always get TWO smaller drives that a BIG one, the cost is usually very similar, and - from experience "top performance" and "high capacity" of newest model has often the drawback of a lesser - to say the least - reliability when compared to lower capcity, already widely in use, models.

About advanced tools I tend to try avoiding them as much as possible, they often give you the (WRONG) feeling you can do everything you want with partitions and filesystems (like moving, resizing, cloning, extend, etc.) which is normally not *needed* and that very often fails when you actually need to use some of their "advanced" features (but this is because you rarely test apporopriately the app in the actual scenario where at a certain point it's use it's needed).

I prefer to use "old", documented, tested and "simple" ways rather than rely on "automagical" software that claims to do everything (yes I did have my problems with Partition Magic and with Acronis apps at the time and I learned to never trust them without actually simulating their use BEFORE actually *needing* them in a "real" emergency).



Wonko

Will look at idea of adding a 1-st small bootable partition on each drive, though G4D coupled with a small partition with various ISO CDs feels better.

Windows Repair Install does not fix the above issue, I tried.

Having at least one large fast enough drive is a must for nowadays home web usage trends, like downloading HD movies.

Latest Paragon proven to be very robust error free partitioning tool overall, while Acronis IMHO excels in faster intelligent backups & restores & wipes.

Merely renaming the MOUNTEDDEVICE didn't change the situation.

One more important observation what I forgot to mention is: I use BioExcess Fingerprint recognition to log on to Windows. It was installed in the XP which I made the image from. BioExcess shows a finger icon on the top left corner of the logon screen. This is absent in the restored XP. It has made me believe that since the drive letter has been changed, it has stopped working. I mentioned it because like BioExcess, Windows itself can loss track of some important files which it falis to find out even after reenumeration of disk signatures after renaming MOUNTEDDEVICE. Hope it can help someone trying to troubleshoot the scenario.

Merely renaming the MOUNTEDDEVICE didn't change the situation.

One more important observation what I forgot to mention is: I use BioExcess Fingerprint recognition to log on to Windows. It was installed in the XP which I made the image from. BioExcess shows a finger icon on the top left corner of the logon screen. This is absent in the restored XP. It has made me believe that since the drive letter has been changed, it has stopped working. I mentioned it because like BioExcess, Windows itself can loss track of some important files which it falis to find out even after reenumeration of disk signatures after renaming MOUNTEDDEVICE. Hope it can help someone trying to troubleshoot the scenario.

And again , the key is MOUNTEDDEVICES and you DO NOT "rename" ANYTHING.
http://reboot.pro/11642/page__st__17
I have to ask you this question :

• have you understood the info contained in the above referenced post and in the links given?

If answer is yes, you simply CANNOT continue stating you "renamed" a key.
If answer is no, WHY didn't you ask for help and/or further clarifications on the matter?

One more important observation what I forgot to mention is: I use BioExcess Fingerprint recognition to log on to Windows. It was installed in the XP which I made the image from. BioExcess shows a finger icon on the top left corner of the logon screen. This is absent in the restored XP. It has made me believe that since the drive letter has been changed, it has stopped working. I mentioned it because like BioExcess, Windows itself can loss track of some important files which it falis to find out even after reenumeration of disk signatures after renaming MOUNTEDDEVICE. Hope it can help someone trying to troubleshoot the scenario.

Yep, but it is also possible that such an "advanced" login method uses a different method to trace/track the actual disk or partition (or it uses the same disk signature only?).

Why don't you simply try replicating the disk signature AND make a proper entry in MOUNTEDDEVICES assigning to the imaged drive the SAME drive letter it had originally?

Still it is possible that the Bioexcess thingy also looks for offset of the partition, though.


Wonko

Assigning to a relocated partition its previous drive letter often isn't possible, when that letter on another drive is already assigned to another partition. As we discussed above, the solution is more complex, but does require attentive reading.

There may be a large number of direct references to a previous drive letter in the restored system Registry. I didn't check if they were corrected as part of Acronis Restore Archive or Copy Partition operation (I assume they were), or Paragon changed all these refs later at once via Adjust Migrated OS feature, but they are all corrected now. Is it generally possible to use %SystemDrive%\ or %HOMEDRIVE%%HOMEPATH% or similar relative address in Registry keys instead of absolute addresses?

Or possibly merely correcting the drive letter in MountedDevices key will auto-redirect all subsequent calls to ANY registry key linked addresses without the need to correct drive letter in each key separately. This is above and beyond all other actions required to generalize OS and take care of the disk sig, despite full generalization might not be needed when relocating a partition within the same PC.

Regarding the disk sig: are we talking about a volume sig or HD sig? Because changing HD sig of the drive itself might not be possible as well, when another OS is already installed on that HD. Yet Paragon fixes that issue too for the relocated OS - probably by changing the drive sig reference in the OS?

Regarding the disk sig: are we talking about a volume sig or HD sig? Because changing HD sig might not be possible as well, when another OS is already installed on that HD. Hence, Paragon fixes that issue as well for the relocated OS - how exactly?

We are talking of DISK signature (the 4 bytes value in the DISK MBR) NOT about volume serial.

Usual disambiguation needed:

• Disk=HD=\\.\PhysicalDrive
• Drive=Volume=\\.\LogicalDrive=Partition(if Primary)

Item #2 needs the note between brackets as you can have a Partition (an Extended one) that is NOT a "drive" (as in "drive letter") and is NOT a "Volume", but it contains one or more drive(s), or volume(s) or LogicalDrive(s).

The good MS guys made a mess of the terminology and often use the terms "disk" and "drive" in a "casual" manner.


Most probably Paragon is fixing the Registry entry to the "right" drive letter and to the "new" signature.

I see that you also haven't read the given links.

It's not really rocket science, we are talking of 4 bytes (the Disk Signature) and a bunch more bytes (the LBA offset of the partition), I really cannot see which is the difficult part in this thread (provided that it is READ):
http://www.911cd.net...showtopic=19663

Information on Disk Signature can be found here:
http://thestarman.pc.../mbr/index.html
http://thestarman.pc...br/Win2kmbr.htm
and more advanced info on the way it is used when booting is given in the "XP Kansas City Shuffle" thread:
http://www.911cd.net...showtopic=21242

And I already posted about the problem one can normally have when changing drive letter.

Of course this may (or may not apply) to the specific BIOwhatever Holmes.Sherlock has.


Wonko

Is it generally possible to use %SystemDrive% or %HOMEDRIVE%%HOMEPATH% or similar relative address in Registry keys instead of absolute addresses?

Will merely correcting the drive letter in MountedDevices key auto-redirect all subsequent calls to ANY registry key linked addresses without the need to correct previous drive letter in each key separately?

PS: This guy at PCMinistry.com had an ample amount of time on his hands... Its not uncommon for ministry clerks to devote significant time to programming, forum discussions and system administration, and some are among the most knowledgeable ppl in their field of interest.

Is it generally possible to use %SystemDrive% or %HOMEDRIVE%%HOMEPATH% or similar relative address in Registry keys instead of absolute addresses?

NO.
Often but not *always*.It depends by a number of factors, including the type of key in the Registry and loading order/timing.

Will merely correcting the drive letter in MountedDevices key will auto-redirect all subsequent calls to ANY registry key linked addresses without the need to correct previous drive letter in each key separately?

NO.
That's only for allowing to boot by giving the actual volume the "right" drive letter but if you actually change the drive letter you will have the additional "problem" of logging in, see the MS KB I already cited .
AND ("later") you will need COA2 (or similar software) in order to change all "old drive letter" references to "new drive letter" ones.
http://www.pcmag.com...17,21065,00.asp


Wonko

Any web references to using relative addresses in Registry keys? Where such address examples can be found in Win XP or 7 Registry?

COA2 was reported to work OK up to WinXP SP3 32-bit. For Win7 I found another program Application Mover. Is their a free analog?

Any good links on migrating (install hardware dependent) apps with OS to a different PC, including performance comparison of migrated programs versus directly installed?

Acronis Restore or Partition Copy features appear to fix all app links automatically (Registry, .ini files, etc), since all apps are working normally after migrating a system with apps to a different drive or volume. Their Settings are preserved as well. Also Acronis Universal Restore feature can add missing drivers during restore to a different HW. Still question remains, whether performance of the migrated apps will be comparable to installed apps when HW changes, since some installers perform system dependent performance optimization during install. This point is frequently missed when considering migration, as ppl tend to center all relevant issues around migrated OS booting.

Any web references to using relative addresses in Registry keys? Where such address examples can be found in Win XP or 7 Registry?

Actually it's the "basics" of the Registry.
This info is all over the net, example:
http://msdn.microsof...s724884(v=vs.85).aspx
(stoopid MS link or stoopid board software makes the above link not clickable, copy and paste following)

http://msdn.microsoft.com/en-us/library/ms724884(v=vs.85).aspx

A key of type REG_EXPAND_SZ will expand to an environment variable.
Problem is that some keys may be read BEFORE the environment variables actually exist (or if you prefer before they are defined).

COA2 was reported to work OK up to WinXP SP3 32-bit. For Win7 I found another program Application Mover. Is their a free analog?

Well, I have no reason to believe COA2 doesn't work on 7. (of course not on 64 bit, but on 32 bit it should )

A very good tool (GUI) is/was Registrar Lite (but is not anymore available) from resplendence.com and BTW I have no idea whether it works on 7 anyway.
The file was called reglite.exe and can still be found around:
http://www.filewatch...084888.0.0.html

Obviously the "right" approach would be to use a "registry as a filesystem driver":
http://reboot.pro/7681/
and some batches with it, but our friend programmers seem like not having ANY interest in finishing/refining it.

Maybe something can be done with the new redistributable MS .dll for offline Registry editing:
http://reboot.pro/11212/
and with the nice tool erwan.l is developing:
http://reboot.pro/11312/
maybe using this:
http://www.codeproje...stryDumper.aspx
(or something similar) to dump the offline Registry and use on it "normal" text processing tools could be a possibility.

All in all, since what you are searching for is basically a three characters string, say "C:\" that needs to be replaced by another three characters string, say "F:\", once could also try using "blindly" gsar on the binary Registry file.

But this also needs a lot of testing and experimenting.

Another thingy maybe worth some time exploring :
http://lilith.tec-man.com/hivetools/



Wonko

Reports say COA2 doesn't work in Vista and Win7 32-bit properly.

More important, migrating installed apps with OS is not quintessential to adjusting only apps Registry refs. COA2 and such appear to do more..., yet still don't touch the apps performance re-optimization after migration.

Reports say

Actually a single - without ANY feedback/confirmation - report.

There are a zillion (unspecified) settings in 7 (or possible conflicts with other apps) that are not specified/adressed in that.

More important, migrating installed apps with OS is not quintessential to adjusting only apps Registry refs. COA2 and such appear to do more..., yet still don't touch the apps performance re-optimization after migration.

Can you rephrase/expand?

I seem like not being able to understand what you are meaning/wanting to say.


Wonko

Its probably better worded in this post.

Its probably better worded in this post.

Maybe , but I still fail to get the point you are trying to make.

What COA2 does is simply find in the Registry pointers to a PATH (including it's drive letter) and change them to the ANOTHER PATH:
http://www.pcmag.com...17,21065,00.asp
http://www.pcmag.com...,1161199,00.asp

But what you actually need if you change drive letter assignment, is only a subset of the above, just changing the drive letter in a PATH to another drive letter but keeping the rest of the path "as is".


Wonko

Application Mover is a tool that relocates installed programs from one path to another on your hard disk..., takes files found in the path specified in the 'Current Path' field (see below) and moves them to the 'New Path' path... Scans the windows registry for references to files located in the 'Current' field and changes those references to the 'New' path... Also scans all windows shortcuts in the Start Menu and adjusts path references to the new program location... Scans *.ini and Install.log files present in the original program path are checked for strings matching the old path location. If found, these strings are changed to the new location. Confirmation dialogs are available if you enable the 'Confirm changes' checkbox (see below). If a file is 'busy' and cannot be changed to the new location, a reboot prompt is offered. Pending changes are then completed after the reboot.

Application Mover is a tool that relocates installed programs from one path to another on your hard disk..., takes files found in the path specified in the 'Current Path' field (see below) and moves them to the 'New Path' path... Scans the windows registry for references to files located in the 'Current' field and changes those references to the 'New' path... Also scans all windows shortcuts in the Start Menu and adjusts path references to the new program location... Scans *.ini and Install.log files present in the original program path are checked for strings matching the old path location. If found, these strings are changed to the new location. Confirmation dialogs are available if you enable the 'Confirm changes' checkbox (see below). If a file is 'busy' and cannot be changed to the new location, a reboot prompt is offered. Pending changes are then completed after the reboot.

Yep, but this is another thing from COA2.

Application Mover moves applications (and obviously their addresses).
COA (Change of Address), changes addresses .

Here we are talking of changing drive letters, which is a subset of the addresses.

Obviously additional files, like .ini or .log files may need parsing and changing, but these being "plain" text files can be done with any number of available programs.

Still, a small number of binaries that self-modify themselves or however "encode" a "fixed" PATH in some "non-standard file will never work. (unless of course they are "known" to Application Mover - or Paragon - or Acronis - or whatever - and there is a provision for these special cases).

If what you are trying to say is that there is no 100% working solution and 100% foolproof, yes, that's it.
And that's it also why it is NOT recommended to change drive letters, to restore to other partitions on disk, etc. etc.


Wonko

I examined the registry hive of the restored XP offline after the renaming of MOUNTEDDEVICE key. Though I restarted XP once after I renamed the mentioned key, there was no such MOUNTEDDEVICE created by XP after the enumeration of the disk signature. Shouldn't the key be created automatically by XP once again?