Part 1:  The Symptoms

To all

There have been multiple reports of problems with external HDD's that did not show up when a person boots to the Ghost 10 Recovery Environment (RE).

Ghost4me.John was first here:

Brian reported a different problem here:

And when I got my copy of Ghost 10, I reported the problem here:

I think I was the first to report that this problem effected Firewire HDD's as well as USB external HDD's.

This is of great concern if your OS becomes un-bootable for some reason, and you hope to be able to recover a functional back-up image of your OS from an image stored on your external HDD--because you have to use the RE to restore your OS partition  :o !

There's been much speculation as to what is the cause of this problem, who's to blame, and how to *fix it*.  It's obviously a Ghost 10 problem--because it does not occur at all in Ghost 9's RE.  

Ghost4me.John felt that it must have something to do with the new version of Microsoft's WinPE (Pre-install Environment) that is used to boot from the Recovery Disk CD to the Symantec Recovery Environment (RE).  Brian pointed out that if everything showed up okay in the Ghost 10 RE, then the various partitions and drives had the same drive letters in the RE as they did in WinXP.  That made me wonder if Ghost 10 was somehow *marking* the HDD's so they could read that information when the RE booted and could then assign those drive letters.

Now, several fixes (workarounds?) have been reported, and appear to work in most instances (perhaps all?!):

Ghost4me.John tested and found that by editing the external HDD's disk ID that the external HDD then showed up in the RE--see here:  I can confirm that this fixed my problem of not seeing my external HDD's as well.

Brian found that by assigning new drive letters before those of the USB Card Reader, then his missing external HDD now shows in the RE--see here:

Quote:

Booted to Windows and in Disk Management I changed K and L back to G and H, the original USB external HD drive letters before the card reader was plugged in. Booted to Ghost 10 RE and the USB external HD was seen as G and H.

Again, I can confirm that this also made my external HDD's show up in the RE also.

There appears to be two separate and distinct issues for the Ghost 10 RE:

1.  Ghost4me.John has determined that the new WinPE that is used for the Ghost 10 RE reserves two drive letters for itself:  X:\ for the optical boot drive--regardless of any drive letter assignment in WinXP, and Z:\ for the MS RamDrive that WinPE loads during boot.  If you have assigned either of these drive letters to other drives in WinXP, then those drives will not show up in the Recovery Environment (RE) of Ghost 10.

Ghost4me.John also said he thought someone else had mention that drive letter S: was reserved--but, in all the testing I've done so far, the drive letter S: has not been used or reserved when booted to the Ghost 10 RE--so I have my doubts about that--if anyone can confirm that the drive letter S:\ is reserved for something in the Ghost 10 RE, please let us know.

2.  Other drive letter conflicts when other USB devices are being used, especially USB memory stick Card Readers.

I believe I have worked out *most* of the *whys and wherefores* of this issue, and how to control and avoid the problem(s).

Continue to Part 2:  The Setup

NightOwl, your exceptional ability to distill and document an issue is clearly evident in the prior post.  I recommend that you add a reference to this superb summary into the FAQ thread, so that others will be able to find it easily in the weeks and months to come.

ditto.

NightOwl rocks.

[glb]Hey - is this a great forum - or what !!![/glb]

El Pecador,

It is a fantastic forum.

How you coming at getting back to your somewhat normal self?

thorin

thorin wrote on Apr 4^th, 2006 at 9:16pm:

"... How you coming at getting back to your somewhat normal self?..."

After spending over $300 USD on power tool rentals alone at The Home Depot just to remove our spoiled hardwood parquet flooring, just last week I finally felt that we have finally turned the corner on renovating our home.

Since we had no flood insurance - in spite of an Allstate Premier Homeowner's policy (<$2,900 received) - we are now essentially working 'out-of-pocket' as the pittance from Red Cross and FEMA have long since played out.  No contractors or permits - just friends and a single undocumented day laborer - is the mode each day in performing a task that would ultimately consume $50,000-to-60,000 were it done professionally 'on-the-up-and-up'.

CLICK HERE to read context of "... As I drove around and looked out the car window, I felt astonished that I could be in the United States of America...".

CLICK HERE to read context of "... I wonder what New Orleans will be like in fifteen years.  Until then, I need a bullet proof soul...".

EP :'(

Part 2:  The Setup

(Hey, thanks for the *kudos* above before I even get to the good stuff, but here's some more: )

To All

First of all, I have to qualify what I am going to say here:  My findings apply only to my system.  I suspect that the software works (functions) the same on all systems, but the way the hardware reacts and responds may depend on the different hardware that's out there--so the final output responses may vary on each individual system based on the actual components hooked up to that system.

The reason I say the above is that I am unable to duplicate some of Brian's results of his testing that he reports here:

For instance--elsewhere he states that he has assigned his second optical drive as Z:\ in WinXP, but you will see him reporting it in the above post as M:\, O:\ and K:\--on my system, if I assign my second optical drive Z:\--it simply does not appear in Ghost 10's Recovery Environment (RE), apparently because the assigned optical drive letter Z:\ in WinXP conflicts with the *reserved* drive letter for the RamDrive in the RE.

Also, he reports this:


Quote:

With the external HD absent I plugged in a USB card reader. Drive letters assigned were G, H, I and J. In the RE the card reader drive letters were I, J, K and L. There was no G or H. The slave CD drive was M.

On my system, the only time my Card Reader drive letter assignments are *bumped* up, is if either my USB HDD and/or Firewire HDD are hooked up with the Card Reader--never when they are absent.


Quote:

Booted to Windows and the card reader drive letters were G, H, I and J and the external HD was K and L. As before. I removed the card reader, rebooted and the USB external HD was still K and L. Booted to RE and the USB external HD wasn’t seen at all. CD drive was K.

On my system--that was the first test I did--remove the Card Reader--and my USB HDD and Firewire HDD both show up fine once the Card Reader is removed.

So the specifics as to how your system responds may be different--but the outline of what I'm going to report and the tools you can use, should allow you to avoid the problems in the Ghost 10 RE with external HDD going *missing*.

So, what is the problem--it's a combination of the sequence that was used in hooking up your USB devices in WinXP that eventually get a *sticky* drive letter assigned, the sequence that drive letters are assigned by WinPE in the Ghost 10 Recovery Environment (RE), and how Ghost 10 tries to use the *sticky* drive letters in the RE, but apparently has not implemented *completely* the use of those *sticky* drive letters.

Part 3a:  The Tools for Investigation of the Problem

To All

So, how did I come to the conclusion at the end of *Part 2* above?

1.  The first tool is included in the Ghost 10 Recovery Environment (RE)!  It's Ghost v8.2 that is included so one can access *legacy* Ghost images from pre-Ghost 9.x and 10.x.

You access this program in the RE from the *Main Screen/Recover/Recover using legacy Ghost image* (its file name on the Recovery Disk is *RESTOREGHOST.EXE*).  This Ghost version is the 32-bit version--which means it can only run under a booted/functioning Windows OS, which includes the WinPE (preinstall environment) that is booted for the Ghost 10 RE--so I call this the *Ghost32 v8.2* program.

This is a very interesting program!  I do not know how to take *screen shots* in the RE, so I can only show screen shots running under WinXP:

http://nightowl.radified.com/forumimages/Ghost32-v8.2-drive-letters.gif

In this first screen shot, the arrow points to my *hidden, primary partition* that has my Win98se OS on it--when I wish to boot to Win98se, I hide the WinXP OS partition and un-hide the Win98se OS partition and now the system boots to Win98se.  But when it's hidden, it's not assigned a drive letter.

In Ghost32 v8.2, all partitions that are *seen* by the Windows OS, but not assigned a drive letter, are shown first in the drop down list of partitions before it begins the list of partitions with drive letter assignments.  The partitions are identified by a first #--the *Disk #*, and then by a second #-- the *Partition #*--so my hidden Win98se partition is *1:2*--which is disk #1, and the 2nd partition on that disk.  

Following the *1:2* is the partition *label*--in my case *[WIN98SE]*, and then the file system--*FAT*.

After the listing of the partitions without a drive letter, then the partitions with drive letters begins with the drive letter listed first, then the disk#:partition#, then the label, then the files system--so for example *C: 1:1 [WIN_XP] NTFS drive*.

In this second screen shot, you can see most of the rest of my partition assignments as they were when I first started using Ghost32 v8.2 from the Ghost 10 Recovery Disk:

http://nightowl.radified.com/forumimages/ghost32destinationdrives.JPG


The first time I booted to the Ghost 10 RE, my Adaptec Firewire HDD with 2 partitions, and my Iomega USB HDD with one partition were *missing* as far as being available in any Ghost 10 recovery funcitons, but both HDD's with their partitions were present in the Ghost32 v8.2 interface without drive letters being assigned to them.

(The best way in Ghost 10's RE to see if your external HDD's are being seen is from the *Main Opening Screen/Analyze/Explore My Computer* which is essentially *Windows Explorer* for the Recovery Environment--if your USB and/or Firewire HDD have drive letter conflicts with other devices--then it/they will be missing from the directory tree.)

In WinXP, my Adaptec Firewire HDD is Disk #8 and its partitions are 8:1 and 8:2, and my Iomega USB HDD in WinXP is Disk #7 and its partition is 7:1.  But.....in the Ghost 10 RE the Adaptec Firewire HDD is now Disk #1 with partitions 1:1 and 1:2, and the Iomega USB HDD is Disk #2 with partition 2:1.

So, something very different is going on in the Ghost 10 RE compared to WinXP!

By the way, the best way to get to a list of the partitions in Ghost32 v8.2 is to click on *Local>Check>Image* like this:

http://nightowl.radified.com/forumimages/Ghost32v8.2Local-Check-Image.JPG


Then click on the drop down list arrow and you can scroll all the partitions that can be seen in by Ghost32 v8.2:

http://nightowl.radified.com/forumimages/Ghost32v8.2dropdownlist.JPG




2.  The second tool is RegEdit--the registry editor.

Continue to Part 3b:  The Tools for Investigation of the Problem

NightOwl, a thought for consideration:  Could the use of the free VolumeID utility to change the ID of an external hard disk drive provide a mechanism to force Ghost 10 to see the hard disk drive in the recovery environment?  In other words, could the use of this utility accomplish the same outcome as that achieved through a disk edit procedure – but with greater ease and safety?

Pleonasm

Here's the command window results of running *VolumeID.exe /?*:


Quote:

G:\Utilities\SysInternal Utilities\VolumeID\v1.xx>volumeid /? VolumeID V2.01 - Set disk volume id Copyright (C) 1997-1999 Mark Russinovich http://www.sysinternals.com usage: volumeid [drive:] [Id] Id must be in the following hexadecimal format: xxxx-xxxx Note: new NTFS volume ids will not appear in directory listings until after the next reboot.

It's unclear as to what *[drive]* designator one is supposed to use here--the real problem will occur for someone who has the wrong *sticky* drive letters present in the registry of WinXP (which is what the Ghost 10 RE *reads* to get the *sticky* drive letters--and if the sequence is wrong--then the drive letters from the WinXP registry will conflict with the drive letters be assigned in the Ghost 10 RE).  So, if you now have a non-booting, corrupt WinXP OS and can not boot to WinXP and use the drive letters assigned in WinXP to designate which drive you want to change the *volume ID* on--you are stuck--but the Ghost 10 RE will still be *reading* your registry in the corrupt, non-booting WinXP OS--which means you will still not see your external HDD's if there are conflicting drive letter assignments.

So, the question is--can you access your HDD's in DOS, run *VolumeID*--and what [drive] designator would one use?

Also, the *VolumeID* appears to be the *Volume serial number* that shows when you open a *command window*:


Quote:

G:\Utilities\SysInternal Utilities\VolumeID\v1.xx>dir Volume in drive G is PART_G Volume Serial Number is A233-C8FF Directory of G:\Utilities\SysInternal Utilities\VolumeID\v1.xx

I'm not sure that will clear the *sticky* drive letters that are derived from the *Disk ID* that Ghost4me.John refers to above.

NightOwl wrote on Apr 7^th, 2006 at 12:06pm:

which is what the Ghost 10 RE *reads* to get the *sticky* drive letters... but the Ghost 10 RE will still be *reading* your registry

The RE does not read any partition's registry.  The RE is a stand-alone Windows Preinstallation Environment built and created exclusively from the boot cd and a ms-ramdrive created in memory.

Same is true of BartPE, which is a stand-alone preinstallation environment.

In a multi-partition environment, how would Ghost (or any application) know which registry hive from which partition or partitions to load?  

I'm keeping quiet until NightOwl has told all.

Ghost4me


Quote:

The RE does not read any partition's registry.  The RE is a stand-alone Windows Preinstallation Environment built and created exclusively from the boot cd and a ms-ramdrive created in memory.

Hmmmm....pretty strongly held belief statement....but, I'll let you be your own judge  ;) !

(But, I'll tip my hand--the patience of Brian is a most admirable trait!)


Quote:

Same is true of BartPE, which is a stand-alone preinstallation environment.

I have to admit, I have not used BartPE as yet--does it have the ability to report the same drive letters that you have assigned in WinXP when booted to its Preinstall Environment--or are the drive letters based on *as seen during boot* assignment of the first available drive letter like Ghost 9.x's Recovery Environment?


Quote:

In a multi-partition environment, how would Ghost (or any application) know which registry hive from which partition or partitions to load?

Indeed--how do they do this--obviously not well--because people's external HDD's are going *missing* in the RE!

Part 3b:  The Tools for Investigation of the Problem

To all

(to continue)

2.  The second tool is RegEdit--the registry editor.

A favorite website with lots of good info on *multi-booting* and more, is Dan Goodell's site:  Understanding MultiBooting and Booting Windows from an Extended Partition.

On this page regarding Fixing Windows 2000/XP Drive Letters, I recalled that Dan had a procedure to make WinXP *forget* its *sticky* drive letter assignments.  

Now he was talking about when you create and restore OS images and cause a drive letter assignment that effects the ability to boot correctly from a restored image.  

But, I wondered if this registry editing method could help with what appeared to be a *sticky* drive letter assignment gone awry.  So I reviewed his Method #2:


Quote:

If we plan ahead, we can clear the registry's drive letter table before cloning the partition, then let 2000/XP rebuild it the next time it boots. To clear the table of partitions and drive letter assignments, use regedit to navigate to [HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices]. This key will contain a bunch of values like "\??\Volume{...}" and "\DosDevices\C:", etc. (See illustration above.) Deleting all values will induce Windows to regenerate all signatures and assign fresh drive letters the next time it boots. Thus, we clear the registry values, make the clone, and then the clone will rebuild the table the first time it boots.

So, click on *Start/Run/type "regedit"* and click OK--this will bring up the Registry Editor.

Navigate to *[HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices]*.  Here, if you wish, you can select all the values in the right hand veiw screen by clicking to highlite the first item, then hold down the *shift* key, and click on the last item.  (Note:  I leave the value *(Default)* un-highlited and do not delete that value.)  Now click the right mouse button, select *delete*, and confirm your choice:

http://nightowl.radified.com/forumimages/regedit_mounted_devices.JPG


http://nightowl.radified.com/forumimages/regedit_mounted_devices2.JPG



Continue to Part 4:  The Testing Results

NightOwl wrote on Apr 7^th, 2006 at 9:56pm:

Part 3b:  The Tools for Investigation of the Problem

As to the question of whether or not the WinPE reads the XP registry, here are results of some testing I just completed.

Case 1. The most obvious case:  your hard drive died, you power off and install a new blank hard drive, turn your external USB2 drive on, boot from the RE cd:

Obviously, the RE can not read from the XP registry as it doesn't even exist.  No files exist.  I tested this case by powering off, pulling ide cables and power connectors from my 2 hard drives, and replacing with a blank drive.

Result:  Ghost 10 RE worked fine, recognized my two USB drives.  The USB drive letters were assigned sequentially, as d and e.

Case 2. I removed ALL ide cables and power cables, booted from the RE cd.
Result:  The RE environment started up normally, but did not enumerate any of the two external USB2 drives I have.  I'm assuming in this case that WinPE RE must want to have at least one IDE (or SATA) drive attached.  (this is probably a bug)

I should probably test this case with BartPE as well and see what BartPE does.

Case 3. I left my XP IDE master connected, removed my second IDE drive, and booted from the RE cd.
Result:  Ghost 10 RE worked fine, recognized my two USB drives.  The USB drive letters however were not assigned sequentially, as d and e.  One of them which I had assigned to k: under Windows XP, was now k again.

Conclusion for test case 3:  one of these two possibilities:
1. The RE read the disk signature DiskID and because there was a valid XP OS system/hard drive present, assigned the USB2 to the disk signature DiskID.
2. The RE read the registry of the IDE drive, and then read the disk signature DiskID.  It is hard for me to believe this because how would the RE know what hive to load?, and from which partition (if multi-boot)?

Note:  I have not heard from Dan Goodell or found documentation anywhere as to the contents of the DiskID field on hard drives; that is, whether it contains just a unique signature or contains a signature plus drive letter for XP.

Even if the RE *does* read the registry, it shouldn't.  The purpose of recovery is to recover, not to be dependent upon some external file (registry).  Fortunately, Ghost 10 does just that:  in the event of a real disaster, case #1 above applies with a new blank hard drive.

Overall conclusion:

The Ghost 10 RE (like anything) could be improved on but works well in most scenarios.  

Some would say that is not good enough, but I would suggest that that is like claiming that your DOS diskette with Ghost 2003 is screwed up because it doesn't recognize your USB hard drive.  As has been pointed out over and over, there are at least 3 different usb drivers that the user is supposed to *try* to see if they work with your configuration and diskette or cd.  

And obviously try before you really need it.  

Same is true for Ghost 10  -- you are supposed to test it first to determine if it works in your environment.

(You should also test fire extinguishers before you need them.)

John. wrote on Apr 8^th, 2006 at 1:32pm:

I should probably test this case #2 with BartPE as well and see what BartPE does.

I retested case #2 (no IDE drives attached at all):

1. Using BartPE, the external USB2 drives were not recognized.  This is not too surprising because I believe that BartPE is based upon WinPE.

2. Using Ghost 9 RE cd:  Using the Ghost 9 RE cd, both external USB2 drives were enumerated.  The Ghost 9 Recovery Environment is from a different proprietary vendor (not WinPE) I understand.  This probably explains why case #2 works correctly for that PE.

NightOwl, the data structure for a Disk Signature does not appear to contain a drive letter designation.  The same can also be said for the Partition Information data structure.

In addition, note that the Microsoft article How Windows 2000 Assigns, Reserves, and Stores Drive Letters says "the drive letter is … located in the system's registry."  The same insight is repeated in How to restore the system/boot drive letter in Windows.

Therefore, is the drive letter corresponding to a partition stored exclusively in the active operating system registry - and nowhere on the physical disk drive itself?

Summary:

Case #2 (no IDE drives present) clearly shows that a PE does not need to have an internal physical disk drive present to function.

The Preinstallation Environment is created and exists as I stated before:  needing only the cd (and a memory ms-ramdrive which it creates).

That is true with WinPE, BartPE, and Proprietary PE which I tested and confirmed all three.

Everyone, don't forget about the missing internal HD partitions as well.

http://radified.com/cgi-bin/YaBB/YaBB.cgi?board=general;action=display;num=1142005842;start=75#81

Ghost4me

You're getting *warmer*  ;) !

I'm at work and can not spend enough time right now to post the tests and the results I have--which I think will start to explain all--hopefully I'll get to that this evening...

But, do these tests:

1.  Use Disk Management to change your USB HDD to, say, letter Q:\ .

Reboot the Ghost 10's RE and see what drive letter you see for your USB HDD--I'm betting it's going to be Q:\ !

(Before you do the next test, create an image backup of your OS partition so you can recover if something goes awry--that's what I did just in case  ;) ! )

2.  Now boot back to WinXP, use *regedit* and delete the values on the right side for the *MountedDevices*.

Reboot the Ghost 10's RE and see what drive letter you see now for your USB HDD--I'm betting it's the next available drive letter.

The only thing you changed is the registry values for *MountedDevices*--Ghost 10 is *reading* the registry's *MountedDevices* values and using that key's value(s) to assign drive letters in the RE--if it does not find values in the *MountedDevices* key, then it simply assigns the next available drive letter in the order WinPE *enumerates* the devices during boot when you boot to the RE--I never said Ghost 10 would not work properly if the drive letter assignment values were not present for Ghost 10 to *read*--what I've been saying is that if the *MountedDevices* values conflict with the way Ghost 10 *enumerates* the devices during boot--then your external HDD's will not show up correctly for Ghost 10 functions--if there is no conflict--then everything will show up without a problem!

As you have shown, if you have a blank, new HDD with no OS on it--Ghost 10 in the RE will have no *Registry* to *read*--so there will be no conflicts!

But the real problem occurs if there is an OS, there is a Registry, and there is a conflict with Ghost 10's RE so you will not *see* your external HDD that has your OS partition image backup on it--now, if your OS is not booting properly and you want to boot to the RE and restore that image from your external HDD--but because Ghost 10's RE is still able to read the Registry of that OS system that will not boot--you're in trouble--because your external HDD will not show up for you to select that backup to restore!!!!!!

Ghost4me, I believe the assessment of the statement "The RE does not read any partition's registry" is still an open question, pending input from NightOwl and Dan Goodell.

NightOwl's Case 3 suggests that the recovery environment does in fact read from the registry on an active partition containing the Windows XP operating system.  Additionally, the citations I supplied in Reply #16 suggest that the registry is the only store in which the drive letter designations are located.  Therefore, if the recovery environment is retrieving the drive letters assigned by Windows XP, it must be reading from the registry – correct?

Brian


Quote:

Everyone, don't forget about the missing internal HD partitions as well.

*Wait for it.....wait for it......*

I think I have that worked out, too--stay tuned!

NightOwl

Quote:

1.  Use Disk Management to change your USB HDD to, say, letter Q:\ . Reboot the Ghost 10's RE and see what drive letter you see for your USB HDD--I'm betting it's going to be Q:\ !

That is the workaround I previously posted to avoid or correct an external USB2 drive letter conflict.

NightOwl

Quote:

2.  Now boot back to WinXP, use *regedit* and delete the values on the right side for the *MountedDevices*. Reboot the Ghost 10's RE and see what drive letter you see now for your USB HDD--I'm betting it's the next available drive letter.

I just ran that test.  However, the only registry entry I deleted was the \DosDevices\K: entry because my external USB2 drive had been hard-assigned to K.  Note, the key value is/was the same as the DiskID on my external usb drive.  I left the rest as is.  When I rebooted into the Ghost 10 RE, the USB2 drive was assigned f: which was the next available drive letter.

Deleting the Mounted Devices registry entries seems to accomplish the same thing as Erasing the DiskID but is easier to accomplish.

If you have multiple problems with multiple usb devices as reported by Brian, then deleting all the the Mounted Devices entries would probably clear everything up.  Not necessary in my case.

From this test I would have to say that the WinPE (or Ghost 10 RE) has a serious design flaw in loading the registry hive file, if it is present.  As Brian and others reported, the Ghost 9 Proprietary Environment doesn't have this flaw.

Not sure how to get this information to Microsoft tech, but at this point I would say that is the bottom line on the issue.

Ghost4me, I suspect that the behavior of the Ghost 10 recovery environment is intentional rather than a "design flaw" – despite the fact that it clearly has some issues that will (hopefully) be fixed in the next version.

It is not difficult to believe that most naïve PC users could easily be confused by drive letters in the recovery environment that are inconsistent with those displayed while using Windows XP.  Under these circumstances, the user could inadvertently restore an image to the wrong partition while in the recovery environment.  My guess is that Symantec Technical Support had too many such complaints with Ghost 9, which may have served as the impetus for the change with Ghost 10.

Pleonasm wrote on Apr 8^th, 2006 at 4:25pm:

Ghost4me, I believe the assessment of the statement "The RE does not read any partition's registry" is still an open question, pending input from NightOwl and Dan Goodell.

No RE should rely on nor read anything on the hard drives, in my opinion.  The purpose of an emergency recovery CD is to build a minimal operating system without depending upon anything except the bare essentials (the CD in this case).  You're trying to repair a corrupt disk drive contents, not depend upon its contents.

Whether that's an emergency recovery DOS diskette, emergency recovery WindowsPE CD, or emergency recovery Linux diskette or CD, the intent should be to not rely on anything except the CD or diskette to bootstrap the system.

Considering the amount of discussion here and elsewhere regarding Ghost 10's inability to find your external usb2 drive, all over many many months, I would say that Symantec has done more user harm than good by its RE design on this specific point.  There's probably been more frustrated users than happy users.

I gladly compliment Symantec on other areas of the Ghost 10 recovery process because I think they are well done, but not external USB2 hard drive logic.

John's question about a multiple boot system prompted me to do a test on my son's computer which doesn't have a drive letter problem with the card reader and USB external HD. He has two WinXP partitions. In the main WinXP the external HD was assigned G and H. The other WinXP has different internal HD partition letters and the external HD was assigned E and F on its virginal connection.

In the Ghost 10 RE, when the main WinXP was active, the external HD was G and H. The same as Windows. The internal HD partitions had the same drive letters as in Windows.

In the Ghost 10 RE, when the other WinXP was active, the external HD was E and F. The same as Windows. The internal HD partitions had the same drive letters as in Windows.

So either the external HD has two DiskIDs or the RE is accessing drive letter information from the active OS partition. I suspect the latter.



PS The internal HD drive letters of each OS when active and their respective RE drive letters are consistent with this hypothesis.

Part 4:  The Testing Results

To All

So, let me set the stage--I have two internal HDD's--the primary has C:\ thru H:\, and the secondary has I:\, J:\ and K:\.  In all the tests, these never varied (unless I specifically change them)--so we can ignore those for now.

I added my Iomega USB HDD first--I chose to format it as a single partition, and WinXP assigned L:\ .

Some time later, I added a memory stick multi- USB Card Reader, and it was given four drive letters in WinXP--M:\, N:\, O:\ and P:\ .

And, recently, I got an Adaptec USB/Firewire Enclosure Kit--so I can make it either a USB or Firewire external HDD--I formatted it with two partitions and WinXP assigned it Q:\, and R:\ .

These drive letters in WinXP are *sticky*--I can plug and unplug any or all and re-plug any or all and they always get the same drive letters.

To round out the setup--I always assign my DVD-Rom as X:\ and that's the unit I usually boot my bootable CD's from, and I assign my CD-RW as Y:\ .

L:\ = Iomega USB

M:\ = Card Reader
N:\ = Card Reader
O:\ = Card Reader
P:\ = Card Reader

Q:\ = Adaptec Firewire
R:\ = Adaptec Firewire

X:\ = DVD-Rom
Y:\ = CD-RW

Test #1:  I plug everything in (I chose Firewire for the Adaptec enclosure kit), re-booted to the Ghost 10 Recovery Environment (RE)--both the Iomega USB and the Adaptec Firewire HDD's were missing from the *Explore My Computer*--also, my second optical drive is missing as well.  So this is what I saw:

Drive letters L:\, M:\, and N:\ were not used, and notice the Card Reader drive letters have been bumped up two drive letters from what's seen in WinXP:

O:\ = Card Reader
P:\ = Card Reader
Q:\ = Card Reader
R:\ = Card Reader

X:\ = DVD-Rom  (boot drive)

Z:\ = MS-RamDrive

But, in Ghost32 v8.2, both the Adaptec Firewire HDD and the Iomega USB HDD were listed, L:\, M:\, and N:\ drive letters are not used, and the second optical drive is not present:

1:1 = Adaptec Firewire   (no drive letter assigned)
1:2 = Adaptec Firewire   (no drive letter assigned)
2:1 = Iomega USB HDD   (no drive letter assigned)
7:2 = Win98se   (hidden--no drive letter assigned)
7:1 = C:\ WinXp
7:3 = D:\
7:4 = E:\
7:5 = F:\
7:6 = G:\
7:7 = H:\
8:1 = I:\
8:2 = J:\
8:3 = K:\
3:1 = O:\ Card Reader
4:1 = P:\ Card Reader
5:1 = Q:\ Card Reader
6:1 = R:\ Card Reader
------- X:\ DVD-Rom  (boot drive)
------- Z:\ MS-RamDrive

Test #2:  I then shut down, un-plugged the Card Reader and left the Iomega USB HDD and the Adaptec Firewire HDD hooked up, and re-booted to the Ghost 10 Recovery Environment (RE).

Now, both HDD's appear in *Explore My Computer* with the WinXP assigned drive letters, and the second optical drive also is present:

L:\ = Iomega USB

Q:\ = Adaptec Firewire
R:\ = Adaptec Firewire

X:\ = DVD-Rom  (boot drive)
Y:\ = CD-RW
Z:\ = MS-RamDrive

So, there's something about the Card Reader that is causing a problem--notice that the drive letters in *Test 1* of the Card Reader match the drive letters of the Adaptec Firewire HDD in *Test 2*!  So in *Test 1*, the Card Reader is being assigned drive letters that are not from WinXP's *sticky* drive letters, but they now conflict with drive letters that are part of the WinXP *sticky* drive letters!

Test #3:  Shut down, re-connected the Card Reader, booted with a floppy disk so I could change my active partition from my WinXP OS to my Win98se OS--and then re-booted to the Ghost 10 RE.  Now in the Win98se OS there's no *sticky* drive letters, so no registry to *read*--here's the results:

L:\ = Adaptec Firewire
M:\ = Adaptec Firewire

N:\ = Iomega USB

O:\ = Card Reader
P:\ = Card Reader
Q:\ = Card Reader
R:\ = Card Reader

S:\ = CD-RW

X:\ = DVD-Rom  (boot drive)

Z:\ = MS-RamDrive

Everything showed up and was assigned a drive letter!

Note--the order of the drive letter assignments in this test compared to the *Disk #* in Ghost32 v8.2 listed in the *Test 1* results--first available drive letters assigned to the Adaptec Firewire L:\ and M:\ (Disk #1 in Ghost32 v8.2), next available drive letter N:\ assigned to the Iomega USB HDD (Disk #2 in Ghost32 v8.2), and then drive letters O:\, P:\, Q:\ and R:\ assigned to the Card Reader (Disk #3, #4, #5, & #6 in Ghost32 v8.2)!

Test #4:  Re-booted and hide the Win98se partition and un-hide the WinXP partition--re-booted to WinXP.

Now, deleted the all the values in the Registry Key *[HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices]*.  Still with the Firewire HDD, USB HDD and Card Reader hooked up, re-booted to the Ghost 10 RE.

The results were exactly the same as *Test 3* above!

Well, based on the above, I was convinced that Ghost 10's RE was *reading* the *MountedDevices* registry key if it had values present to read--if not, it would choose it's own order to enumerate the various USB devices, and they would show up fine.  But, if the registry values in some fashion did not match some specific sequence that the RE needed *to see*--then there were drive letter conflicts and things would then not show up in the Recover Environment as they should.

The various HDD's had the same drive letters in Ghost 10's RE as they did in WinXP as long as they showed up in the RE and WinXP's *MountedDevices* values had not been deleted, but the Card Reader's drive letters did not remain the same as seen in WinXP--critical observation!

Ghost4me, I understand the perspective you stated in Reply #24, and it has much merit.  Based on "Case 1" by NightOwl, however, we now know that if the active operating system partition containing the registry is unavailable (missing, corrupt or absent), then Ghost 10 will nonetheless properly run.  In fact, under these circumstances, the Ghost 10 recovery environment appears to function the same as that of Ghost 9, with respect to the assignment of drive letters.  Therefore, the current methodology used by Ghost 10 does not place the user "at risk", but may cause some headaches as noted throughout this thread.

Part 5:  Interpreting the Test Results

To All

I have listed only a few tests above--I have done quite a few more test--just to illustrate--I now can tell you what USB port on my USB 2.0 PCI card will assign a drive letter first if I have two or more USB HDD's hooked up--as well as which USB port on my 4-port USB hub will get assigned drive letters first--but that's not important to this discussion.

The above results should have enough data to understand my conclusions.

Understand--I'm *making all of this up*--I have no *insider knowledge* as to how Ghost 10's RE really works, how it *reads* the Registry key *MountedDevices*, or what sequence of events occur while the RE is booting--I have just *created a model* that seems to explain what happens based on the observations (there are several points that I really *stretch* to make the model work  ;) because I don't have a good explanation for the behavior! )

So, it appears that the Card Reader does not inherit the *sticky* drive letters from WinXP.  Even though WinXP can assign and remember the Card Reader's drive letters in WinXP, in Ghost 10's RE the Card Reader appears to be assigned the next available drive letters after the RE has mounted the various external HDD's and internal HDD's, but apparently before the RE has assigned the drive letters to those external and internal HDD's.

Ghost 10 RE appears to mount the devices in this order:

1st  Firewire HDD's
2nd USB HDD's
3rd USB Mass Storage Devices (non-HDD's)
4th Internal HDD's

(Look back at the test results in *Test #1* for the Ghost32 v8.2--this is the order of the disk #'s assigned to the various above devices.)

Ghost 10 RE now knows how many partitions will need drive letters assigned (having mounted the various devices--but has not *automatically* assigned drive letters yet--it has to *read* the Registry for that if it wants to make the drive letters in the RE match the drive letters as seen in WinXP!)

But, again, Ghost 10 RE *knows* that it is not going to give the Card Reader the *sticky* drive letters from WinXP (? because it's not a HDD volume ?), so it assigns the *next available* drive letters to the Card Reader, having set aside enough drive letter *slots* for the number of HDD partitions present.

Again, look at my setup in *Test #1*--I have C:\ thru K:\ on internal HDD's--so that many drive letters can not be used--so none of those can be *next available*, I have 2 partitions on the Firewire HDD--so L:\ and M:\ would not be next available, and I have 1 partition on the Iomega USB HDD--so N:\ would not be next available.  

So, the next available is O:\--and look what drive letters are assigned to the 4 slots of the Card Reader:  O:\, P:\, Q:\ and R:\ !

Now Ghost 10 RE moves on and assigns the two *hard wired* drive letters required by the WinPE--X:\ for the *optical boot drive*, and Z:\ for the MS-RamDrive.

Now it's time to *read* the *MountedDevices* Registry key in order to assign *sticky* drive letters.  C:\ thru K:\--no problems--they can be assigned to the internal HDD partitions without any problems--no conflicts.  Next, Ghost 10 RE wants to take care of the Firewire HDD--its sticky drive letters in WinXP are Q:\ and R:\--but that's a problem--the Card Reader has already been given those drive letters and the assignment of the *sticky* drive letters will not work--so the Firewire HDD does not get a drive letter assignment and so it does not show up for Ghost 10 RE functions (but it still shows up in the Ghost32 v8.2 listing because that program will *see* partitions by disk # even when a drive letter does not exist!).

Next, Ghost 10 RE moves on to the next device--the Iomega USB HDD--well, here's where I'm really *stretching* my explanation  ;) , when Ghost 10 RE tried to assign drive letters to the Firewire HDD, the Firewire was in line to take the next available drive letters L:\ and M:\, but the *sticky* drive letters for the Firewire HDD were Q:\ and R:\, so Ghost 10 RE sees there is a drive letter conflict with the drive letters it has already assigned to the Card Reader, and simply notes that L:\ and M:\ were *not available* due to conflicting drive letters--and the next available drive letter is N:\--so, now reading the *MountedDevices* drive letter assignment for the Iomega USB HDD--it's L:\--but that drive letter has been *discarded* as having conflicting drive letter assignments--so Ghost 10 RE again refuses to assign the *sticky* drive letter that's found in the Registry key, and the Iomega HDD too is not *seen* by the Ghost 10 RE functions because no drive letter was successfully assigned (but it is seen by the Ghost32 v8.2 program).

As for my second optical drive--it is assigned the *sticky* drive letter in WinXP as Y:\--that drive letter does not *conflict* with any other drive letters--as noted in *Part 2....*, Brian's second optical drive conflicts with the Z:\ MS-RamDrive drive letter assignment--and his second optical drive simple shows up in the drive letter assigmnet *game* as the next available drive letter in the RE after all HDD and Card Reader drive letters have been assigned--on my system--if there are any drive letter conflicts anywhere--my second optical drive just simply never shows up--if there are no conflicts--it shows up as Y:\ !

*********************************************

Brian, you mentioned this above:


Quote:

Everyone, don't forget about the missing internal HD partitions as well. http://radified.com/cgi-bin/YaBB/YaBB.cgi?board=general;action=display;num=1142005842;start=75#81

So, here's your setup:


Quote:

I plugged in the card reader, G H I J and then the USB HD, K L.  My hard drive partitions are C D E F M N P. In the RE the card reader was L M N O. The external HD wasn't seen and neither were most of my HD partitions. The only HD partition seen was C: drive. The spare optical drive was P (the one I'd made V in Windows).

Okay, so your internal HDD has 7 partitions, and your external HDD has 2--so 9 altogether--that's C:\, D:\, E:\, F:\, G:\, H:\, I:\, J:\ & K:\--so Ghost 10 RE gives your Card Reader the next four drive letters that are not being *set aside*--L:\, M:\, N:\, & O:\ .

Then it tries to *read* the *MountedDevices* sticky drive letter assignments for the USB HDD--and it finds that the WinXP sticky drive letter for the USB HDD L:\ conflicts with the drive letter it has assigned to the Card Reader in the RE (I have found that if a device has two or more partitions--and at least one of the partitions has a drive letter conflict--then the whole device is failed by Ghost 10 RE, and none of the partitions are assigned drive letters), so no USB HDD is seen in the RE.

Next, it tries to assign the sticky drive letters to your internal HDD's, but your sticky drive letters for your internal HDD of M:\ and N:\ conflict with the drive letters Ghost 10 RE has already assigned to the Card Reader--so that fails and I would expect partitions M:\ and N:\ to not show up.

But, you say D:\, E:\, F:\ and P:\ also do not show up--well, my model does not predict that--but when I set this similar situation up on my system so the Card Reader drive letters would be bumped up to conflict with an internal HDD partition drive letter--the results did make the internal HDD partition not show up, but it also effected other drive letters further up that should not have had drive letter conflicts--but the internal drive letters before the Card Reader/HDD partition drive letter conflict were not effected like you have stated--so the only thing I can say is different systems react differently when a conflict occurs.

In my test--all the missing partitions in Ghost 10 RE *Explore My Computer* showed up just fine in Ghost32 v8.2's listing of *seen* partitions!  But, of course, Ghost 32 v8.2 does not help you if your Ghost image is created by Ghost 10--and your images can not be accessed by the Ghost 10 recovery tools!


Continue to Part 6:  Conclusions and Recommendations

Pleonasm


Quote:

however, we now know that if the active operating system partition containing the registry is unavailable (missing, corrupt or absent), then Ghost 10 will nonetheless properly run.  In fact, under these circumstances, the Ghost 10 recovery environment appears to function the same as that of Ghost 9, with respect to the assignment of drive letters.

But, as I noted in reply #19 above:


Quote:

But the real problem occurs if there is an OS, there is a Registry, and there is a conflict with Ghost 10's RE so you will not *see* your external HDD that has your OS partition image backup on it--now, if your OS is not booting properly and you want to boot to the RE and restore that image from your external HDD--but because Ghost 10's RE is still able to read the Registry of that OS system that will not boot--you're in trouble--because your external HDD will not show up for you to select that backup to restore!!!!!!

Brian

You are the BartPE and ReatogoPE expert--is there a *plug-in* that once booted to one of these WinPE's, you can edit the Registry of the OS of the active, boot partition.

See where I'm going--if you have a Registry issue between your *MountedDevices* and the Ghost 10 RE--can you boot to BartPE, edit the *MountedDevices* to delete the key values, and then re-boot to the Ghost 10 RE and let it mount and assign drive letters on it's own without the conflict of attempting to use *sticky* drive letters from the Registry that are mismatched.

NightOwl, concerning Reply #30, ERD Commander 2005 is a set of tools on a boot CD that claims to be able to edit the registry of a PC.  Unfortunately, it is no longer sold as a separate product, but only as part of an Administrator's Pak at USD$1,199.

Concerning Reply #29, the question is whether the reading of the registry from the active partition containing the operating system is a "design flaw" for the Ghost 10 recovery environment.  One could reasonably argue that such is true, since it creates the potential of a situation of not being able to see a partition containing the recovery point.  My point is that such a downside risk – in the minds of Symantec – may be offset by the increased 'ease-of-use' afforded to the naïve PC user by the consistency of drive letters in Windows XP and in the recovery environment in Windows PE.  Ideally, of course, one would expect a solution that accomplished both objectives.

A workaround approach to the problem we are discussing involves BartPE.  In the event that a user does not have visibility to a partition containing the recovery point while using the Ghost 10 recovery environment, it should be possible to boot using BartPE and simply copy the recovery point to another destination using the File Manager.

NightOwl wrote on Apr 9^th, 2006 at 2:33pm:

is there a *plug-in* that once booted to one of these WinPE's, you can edit the Registry of the OS of the active, boot partition.

See my posting here about one registry add-in for BartPE:
http://radified.com/cgi-bin/YaBB/YaBB.cgi?board=general;action=display;num=1140647361;start=17#17

It's a handy add-in that I have used to correct issues with client pc's that weren't able to boot.  I wouldn't recommend it though for casual editing.  You select the hives you want to load into memory, then modify and then resave the files.

For your hypothetical case:
1) If you're able to startup the xp system, just modify the registry directly.
2) If you're not able to startup the xp system, and you have problems with the RE, delete the corrupted os partition, and then reboot the RE.  According to your tests, all drives should re-appear.

Pleonasm


Quote:

A workaround approach to the problem we are discussing involves BartPE.  In the event that a user does not have visibility to a partition containing the recovery point while using the Ghost 10 recovery environment, it should be possible to boot using BartPE and simply copy the recovery point to another destination using the File Manager.

Ah...excellent workaround!--but what a *pain in the butt*--you already spent the time saving that image to your external HDD, and now you have to spend more time transferring it elsewhere to access it--when it should simply be available when you boot to the Ghost 10 RE--better to simply not have Ghost 10 playing these *cute* games of trying to have drive letters in the RE match the drive letters from you WinXP environment.

If your external HDD's don't show up in the Ghost 10 RE--how has that made to poor *naïve PC user* better off  ;) !

But, still a viable workaround!

Ghost4me


Quote:

2) If you're not able to startup the xp system, and you have problems with the RE, delete the corrupted os partition, and then reboot the RE.  According to your tests, all drives should re-appear.

Also excellent!!!--I'm betting that this should work too--probably even *easier* than Pleonasm's recommendation of copying the image files to a new location where they can be seen.


Quote:

I wouldn't recommend it though for casual editing.  You select the hives you want to load into memory, then modify and then resave the files.

Well, that's what I didn't know--I was hoping it would be a more friendly interface like what one sees in WinXP.

Would it be *hard* to explain to someone how to navigate the the *MountedDevices* key values so they can be deleted?

NightOwl wrote on Apr 9^th, 2006 at 2:33pm:

--is there a *plug-in* that once booted to one of these WinPE's, you can edit the Registry of the OS of the active, boot partition.

NightOwl,

I looked at regedit in Reatogo BartPE and navigated to the MountedDevices keys. Alas, they are only for the BartPE OS and not for the installed WinXP.

John told me about Registry Editor PE but I haven't spent the time to learn how it works. John, could you provide a cookbook approach to get to those keys?

NightOwl wrote on Apr 9^th, 2006 at 3:54pm:

Would it be *hard* to explain to someone how to navigate the the *MountedDevices* key values so they can be deleted?

Here's the instructions on how to just even get started with loading a remote registry using the Registry Editor PE for BartPE:
http://regeditpe.sourceforge.net/

As to how easy it would be to explain that to someone, you would first have to explain:
1) How to create BartPE setup from your Windows XP setup disc. (assuming the person has the Microsoft setup disc.)
2) How to add the Registry Editor add-in to BartPE.
3) How to burn and create the BartPE cd.

Then explain how to use the RegistryEditorPE plugin, navigate to the correct key(s), modify them, save the files, etc.

Compare that with how to explain to someone how to delete a corrupted partition.

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


Brian wrote on Apr 9^th, 2006 at 4:31pm:

John told me about Registry Editor PE but I haven't spent the time to learn how it works. John, could you provide a cookbook approach to get to those keys?

This has screenshots and the documentation:
http://regeditpe.sourceforge.net/

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


Observations (my 2 cents worth):

Let's not lose sight of the forest for the trees here.

We're talking about using an emergency boot RE cd because our normal XP operating system does not boot; it is corrupted and we want to restore the partition from a backup image stored on an external USB2 drive.

This is not an everyday occurrence.  It should not be attempted by a novice.  It would be like asking the question, "Can you give me steps on how to remove my appendix?"  What may be simple for a doctor, is not simple for the user.  Same applies I think to these advanced scenarios--nice to talk about at a doctor's (or PC) convention, but "don't try this at home".

Besides, this is a case where the external USB2 drive is not recognized properly by the RE cd.  It could all be a moot point soon, when/if Microsoft or Symantec recognizes the problem.

And it's not like the issue of getting USB2 drives to work in DOS.  In DOS and Ghost 2003 you have no support for USB2 drives at all.  The user must use a trial and error approach to finding something that works with his DOS diskette (or cd) and his external USB drive.  In that case finding a driver that works is necessary just to get the Ghost 2003 backup imaging process to backup to USB, much less the emergency restore.

With Ghost 10 fortunately, there doesn't seem to be any issue or problem of creating the backup image.  There's not an issue or problem of accessing the backup image from within XP.  The issue is the stand-alone recovery environment setup by the boot cd.

If someone called me on the phone and wanted over-the-phone instructions on how to restore their hard drive (remove their appendix), I would be hard pressed to give it.  Too risky.  Most likely I would say make an appointment and I'll come look at it.

Exchanging detailed instructions on a technical forum such as this is great.  But I wouldn't try to explain any of this to a someone.  Yes it is too hard to explain to somone (in my opinion).

[The opinions expressed here are those of the author.  Your mileage and opinions may vary.]

One final point or consideration that I failed to mention:

Most of the discoveries of the Ghost 10 issues with some configurations of external USB drives, occurs BECAUSE the user is testing the RE cd before it is actually needed during an emergency.

That is a good thing!  It means that one can prescribe several non-invasive procedures that will likely fix the problem without involving surgery on the registry, resetting the USB2 disk DiskID, BartPE or other measures.  That would likely involve simply:

1.) Rename the USB2 drive to a lower drive letter, using Disk Management in XP.
2.) Removing other USB2 devices (card readers etc.) before booting from the RE cd.

These two simple steps have resolved probably at least 75% of the cases brought to this forum for help.

Other cases have dealt with SATA drivers, motherboard drivers, etc. which is a completely different subject.

Not minimizing the need for the RE cd to work in all cases, but whenever you recognize the problem BEFOREHAND, as we've seen, most of them are easily solved.  Because you are operating from an operational XP environment.

Ghost4me

Very good points.

I struggled with how to present this material in the first place--it is mind numbing--unless you enjoy the *technical puzzle* it presents--I'm sure there have been many who have abandoned this thread for that very reason...

But, I proceeded anyway because I know we are going to have folks show up here that say, "I installed Ghost 10 and have been creating back up images for x months and stored them on my external HDD.  I installed a program yesterday, it screwed up my system, and now I can't boot to my WinXP OS.  I booted the Ghost RE and my external HDD does not appear there--I can not access my backup image to restore and recover a functional OS--HELP ME PLEASE!"

So far, your feedback seems to offer the easiest way to help someone recover--if they are to the point of needing to restore their OS partition with a backup image--and they can not *see* their external HDD's in the Ghost 10 RE.

But, the other part of what I wanted to accomplish here, was to *know thy enemy*, so one can be prepared before the fact, and that's what I'm going to summarize in my *Conclusion and Recommendations*--if you know what can go wrong and why--it's easy to make a few changes now to avoid issues under duress and emergency conditions  ;) .

John. wrote on Apr 9^th, 2006 at 5:37pm:

This has screenshots and the documentation: http://regeditpe.sourceforge.net/

John,

I followed the instructions but I can't load the relevant MountedDevices. It doesn't really matter as I wouldn't use this approach anyway. I think your suggestion of deleting the partition is a lot easier.

Brian wrote on Apr 9^th, 2006 at 7:11pm:

I followed the instructions but I can't load the relevant MountedDevices. It doesn't really matter as I wouldn't use this approach anyway. I think your suggestion of deleting the partition is a lot easier.

Brian,
Did you integrate the Registry Edit PE into you BartPE and then burn a new BartPE CD?

I just printed out the instructions again, and went through them carefully.  I booted into my BartPE cd, started the RegistryEditorPE program.

Each step of 1) through 7) guessed the correct hive name to load, so it was a matter of just clicking "yes" several times to get through step 7).

I loaded my own user profile, following steps 8) through 9b).  Be sure to highlight ntuser.dat file in \documents and settings\youruserid\ and then click Open in 9b).

It then loads the registry hives and your user profile.  You can then navigate (much like regedit) to:
My Computer\HKLM\_REMOTE_SYSTEM\System\MountedDevices and see the entries.

Follow step 13) to close and save.

By the way, I tested and tried several other off-line registry hive editors and this one was much more straight forward than any other I tested.

Want to try again with these instructions?  I think you will be pleasantly surprised.

John, I did that. But the keys in MountedDevices are for BartPE rather than for WinXP. Have I missed something?

Brian, did you load your remote-user-profile also?  If so you should be able to look at a few registry entries that you can confirm are from the correct registry.  Also, were the file names (SAM, SECURITY, software, system) highlighted at each step and you selected open?  Plus the initial Windows directory from c: ?

All this *should* work.

Look in
HKEY_CURRENT_USER\Software and see if all the sub-keys there are the ones from your REAL xp system, or are they the BartPE ones?

NightOwl wrote on Apr 9^th, 2006 at 7:02pm:

"I installed Ghost 10 and have been creating back up images for x months and stored them on my external HDD.  I installed a program yesterday, it screwed up my system, and now I can't boot to my WinXP OS.  I booted the Ghost RE and my external HDD does not appear there--I can not access my backup image to restore and recover a functional OS--HELP ME PLEASE!"

The simplest answer is still delete the partition (many easy ways to do this) and retry.

However, I would NEVER tell someone to delete their *possibly* only partially (or totally) corrupt os partition BEFORE I verified that there was really a true verifiable restorable Ghost image on the backup.

That's why I would insist on examining the system myself first.

A safer approach would be to remove the failed/corrupt drive, put a new blank drive in, and restore the Ghost image backup to that one, if possible.  If not, I would then take the corrupt drive and install it inside a separate known good xp pc as an additional drive, and manually recover the critical customer files.

I am still having difficulties accepting the any recovery environment emergency boot cd reads files from the host pc disk drive, if present.  If someone told me they had an emergency boot DOS diskette that did this, I would say the same thing.

(I know I may be a born skeptic, but ... I am.)

John. wrote on Apr 9^th, 2006 at 7:53pm:

Brian, did you load your remote-user-profile also?

I did everything correctly but, duh, I looked for the subkeys in System rather than _Remote_System. You are correct. Now I know how to do it, it is easy.

Part 6:  Conclusions and Recommendations

To All

So, how to avoid having a problem with your external HDD not showing up in the Ghost 10 Recovery Environment (RE)?

A.  Well, for the first issue of reserved drive letters by the WinPE/Ghost 10 RE--you just need to avoid using the letters X:\ or Z:\ for any of your drives.

Actually, if you usually use one optical drive for booting, you can assign that drive the X:\ in WinXP and it will not create a problem in Ghost 10 RE--it will have X:\ there too, and it saves you one drive letter for use in WinXP--if needed.

*************************************************

B.  As far as drive letter conflict between what has been assigned in WinXP and then conflicts with what gets assigned in the Ghost RE (probably this only happens if you have a USB Card Reader--and maybe not with all USB Card Readers):

1.  Buy and add any peripheral external devices to your system in the order that Ghost 10 RE expects to see them--  :D  --of course that's not likely to happen--right?!

2.  If you boot to the Ghost RE and your external HDD's are missing, first thing to do, if you have a USB Card Reader, is to shut down, disconnect it, and re-boot to the Ghost RE to see if your external HDD's now show up--if yes, you have access to your images on the external HDD's and you're good to go.

3.  If you want to keep your devices hooked up, and the *sticky* drive letters in the order Ghost 10 RE *needs* to see them to avoid creating a drive letter conflict, then you could do the following:

a.  In Ghost 10 RE, run Ghost32 v8.2, and look at the *Disk #* associated with each of your devices--that tells you in what order the Ghost 10 RE *wants* to see those devices.

b.  Shut down.  Disconnect all the peripheral devices.  Boot to WinXP.  Run *Regedit* and delete all the values in the *MountedDevices* key.  Shut down and re-boot to WinXP.  Now add each of the devices in the order Ghost32 v8.2 suggested when you were in the Ghost 10 RE.

The new drive letter assignments will now be in the order that Ghost 10 RE wants, and will not create a drive letter conflict.

If you later change the devices, like creating additional partitions on your external HDD--in WinXP--that will put new drive letter(s) in the *MountedDevices* that are after the Card Reader's drive letters--it will cause a conflict--you have to redo steps a. and b. above to once again avoid the conflict.

Alternatively, rather than using the RegEdit program, you could go to *Disk Management* in WinXP and re-order the drive letters for your devices there--but that can become a little complicated if you are running out of *free* drive letters to temporarily assign while you move things around--but it can work--I've done it.

Brian wrote on Apr 9^th, 2006 at 8:20pm:

I did everything correctly but, duh, I looked for the subkeys in System rather than _Remote_System. You are correct. Now I know how to do it, it is easy.

Brian, thanks for the feedback.  I corrected my previous post:

http://radified.com/cgi-bin/YaBB/YaBB.cgi?board=general;action=display;num=1144131251;start=30#40

As I said before, and you can see, it is easy, but it isn't as well, and one can be misled to thinking they have modified the registry, when in fact they haven't or they modified the wrong one.

NightOwl, congratulations. This is just an amazing piece of research and interpretation. I’ll need to read this thread several times before it all sinks in but I have learnt so much from the various contributors. So far you have been preaching to the converted but now the information needs to be accessible to the average Ghost 10 user.

Brian

Thanks--appreciate the *pat on the back*--I've been very pleased with the ongoing responses--and it's forced me to learn a few more tricks along the way  ;) !

I still have not installed Ghost 9.x or 10 on my system--I wasn't willing to if I was not able to *see* my external HDD's where I store some of my Ghost images--now, maybe I'll proceed.

I hope others will be able to *wade* thru this maze and report their findings using their unique set of devices hooked up to their systems.

Pleonasm wrote on Apr 8^th, 2006 at 5:54pm:

I suspect that the behavior of the Ghost 10 recovery environment is intentional rather than a "design flaw" – despite the fact that it clearly has some issues that will (hopefully) be fixed in the next version.

I've given this a lot of thought.  Don't mean to overdo the analysis of what was in someone else's minds, but I believe I have a complete correct logical explanation now:

Conclusion:

The Windows Preinstallation Environment was never designed to be an "emergency stand-alone boot" loader environment.  It was never designed to repair dead systems.

It was designed as a minimal operating system; created, not with lots of bells and whistles, but with just a bare operating system, and enough capability to update or change an existing Windows XP system.  Much like the old vanilla DOS boot diskettes don't have any bells and whistles, but just bare bones files.

http://www.microsoft.com/whdc/system/winpreinst/WindowsPE_over.mspx

With that framework in mind, it follows that WinPE is an "operating system updater" boot cd.  Think of it as being used to update an XP system offline.  That is the key.  It's analogous to the concept of taking cold-backups (offline backups) with Ghost, not hot-backups.

Key Point:  That is why the WinPE environment is built to look like the parent OS!  

You would want your offline-updater to present and update an existing OS with close to the same look and feel as the user previously experienced.  That is why I believe that the drive letter environment we've been discussing, is maintained and honored as best as is possible.

It's not an emergency system repair CD.  (If you need that, look at the highly regarded
http://www.winternals.com/Products/AdministratorsPak/  for technician-based tools to repair dead systems.)

Simply put by Microsoft:

"Windows PE is a minimal Windows system that provides limited services based on the Windows XP Professional and the Windows Server 2003 kernels. It also provides the minimal set of features required to run Windows Setup, access and install operating systems from the network, script basic repetitive tasks, and validate hardware."

Quote:

BartPE vs. Windows PE?    * BartPE is not supported by Microsoft. Windows PE is an official Microsoft product.    * BartPE has a graphical user interface. Windows PE has a command line interface.    * The tools needed to make a BartPE installation are free software. Windows PE is available only to Microsoft OEM users.    * BartPE allows unlimited custom plugins. Windows PE has a limited range of plugins options.

John,

This is how Bart describes WinPE by Microsoft, as a Command Line Interface. I've never seen it used. BartPE and especially ReatogoPE are obviously much more like the Windows with which we are familiar. BartPE, Ghost 9/10 and ERD Commander are customised variations of the Microsoft product. I'd say Ghost 10 has been customised too much.

Brian, I would agree with all those bullet points about BartPE.  I've never seen the WinPE interface language either.  But I would say that "BartPE, Ghost 9/10, and ERD Commander" are the *results* of building an os environment with WinPE.  WinPE is the underlying structure.

The main difference with BartPE is that it has documented ways for the user to add plug-ins.  That's one of the primary reasons for its popularity.  Would BartPE be so popular if it only provided a way for you to boot from a cd, but run no programs?  The Symantec and ERD Commander uses of WinPE structure it to allow you run ONLY the specific programs and utilities they include, nothing more.

I think we have been shooting the messenger (Ghost 10), and not the message (WinPE) with Ghost 10.  It all makes sense when you consider this:

The Ghost 10 inability to see the usb drive is the same results I had with BartPE.  BartPE honored the MountedDevices registry entry.  WinPE is the culprit, not the application.

Do you remember all the griping, hand ringing, complaining that occurred when Windows 95, 98, Me, and 2000 came out?  Much of the complaints was that the setup could not or would not recognize the specific pc environment.  The Microsoft setup.exe program on the cd was just another manifestation of WinPE.

What was happening in those cases (and still does) is that the setup Preinstallation Environment didn't recognize something about the pc--such as the motherboard, ide controller chipset, pci addon sound card, etc etc.  The result was that half way through the setup, your pc would freeze, black-screen, or other aborts.  There was message boards filled with "workarounds" on how to get the setup WinPE to recognize your configuration correctly.

Sound familiar?  Sound like Ghost 10 running under WinPE?  I think it is because it is functionally the same thing happening.  I can recall during several corporate conversations of PC's that I was part of, that *most* but not all PC's could finish the setup/WinPE recognition logic, but not all.

As we've seen here, there are sprinklings of configurations that the WinPE configuration won't recognize properly:  USB drives, special HD controllers, SATA drives, certain motherboards.  I read recently of one user who could not get the Ghost 10 RE cd to recognize his new AMD dual core motherboard, and Symantec said "known problem".

That is really saying "known configuration" that that version of WinPE doesn't yet have built into it's database.  That is also why Symantec has multiple versions of their Ghost 10 RE cd available for specific Ghost 10 customers with hardware specific issues.

Brian, you correctly said in the past the most of the problems with Ghost (and TI) are a result of specific hardware configurations.

It's the same as the setup problems Microsoft has had every time it releases a new "pre installation" cd for setup.  

But it's the environment fault, not the application.

I'll bet money that when the Windows Vista cd (PE) comes out, it will produce all kinds of groaning, hand ringing, and complaints that it doesn't recognize some components about someones configuration.

Ghost4me and Brian

When you install WinXP from the installation CD, you don't get a *pretty* Window's graphical based PE OS--it's as Bart has said--it's a *command line* interface--you're given text instructions and asked to *Press F6* to install needed drivers, *Press 'R' for 'Repair', etc.  Actually, Microsoft refers to the initial boot of the installation as the *text mode*, and the second re-boot as the *graphical mode* of the installation process using its WinPE

Based on the descriptions of BartPE and ReatogoPE, I'd have to say that the Ghost 10 RE is more like them, than like the WinPE for the WinXP install CD!


Quote:

You would want your offline-updater to present and update an existing OS with close to the same look and feel as the user previously experienced.  That is why I believe that the drive letter environment we've been discussing, is maintained and honored as best as is possible.

I just think Symantec was trying to be *cute*--*Look--our Recovery Environment is better than yours--We have the same drive letters in the RE as seen in the parent WinXP OS that the user has!*

But, they just did a *poor*, incomplete job of it!!!

I don't think this issue is a Microsoft WinPE issue--this is something Symantec has *dreamed* up and inflicted on us in their attempt at *cuteness*!

Does BartPE or ReatogoPE show the same drive letter assignment in their interface as would be seen in the WinXP OS?  I'm betting *not*!

WinPE is not *equal to* Ghost 10 RE--two separate *beasts*!

This refers to *Window 2000*, but a Google search implies that this applies to WinXP as well:

How Windows 2000 Assigns, Reserves, and Stores Drive Letters

It mentions how the installation process tries to bring forward previous drive letter assignments if there is already a previous Windows installation:


Quote:

the drive letter assignments are exported to the $Win_nt$.~bt\Migrate.inf file so the text-mode setup program can reference and import them into the MountMgr database as part of the upgrade process

NightOwl, in my opinion, Symantec now owes you its gratitude in thoroughly diagnosing and documenting this issue.  You have a made a significant contribution toward addressing the “Ghost 10 recovery environment drive letter” problem.

I am confident that I will miss something in the following list, but it may be valuable to summarize and characterize the conditions under which this problem may appear:

• The user is running Ghost 10 (rather than Ghost 9), and . . .
  
• The user needs to restore the active partition containing the operating system (otherwise, the Ghost 10 recovery environment need not be invoked since the restore operation can be done from within Windows XP), and . . .
  
  • The drive containing the recovery point is external, or . . .
    
  • The drive containing the recovery point is recognized in Windows XP as “X:\” or “Z:\” or. . .
    
  • The user has attached external devices to the PC after creating a recovery point but before invoking the Ghost 10 recovery environment.

At the risk of being redundant, I recommend that you edit Reply #45 to add the (obvious) solution to this problem:  boot into BartPE and use the A43 File Management utility to simply copy the recovery point to a destination that is already visible to the Ghost 10 recovery environment.  This approach, in my opinion, is the one that is most easily explained to a user and has the lowest downside risk of inadvertently damaging the PC through deleting partitions, editing a disk sector, or editing the registry.  Of course, in some circumstances, a user may not have another destination onto which the recovery point may be copied – but, in the worse case, the user could invest a small sum to purchase such a device.

Ghost4me


Quote:

The Ghost 10 inability to see the usb drive is the same results I had with BartPE.  BartPE honored the MountedDevices registry entry.  WinPE is the culprit, not the application.

Is this true!  I must have missed it!  

So, if you change a partition drive letter in WinXP from say E:\ to Q:\, and then boot to the BartPE--it will be Q:\ in the BartPE?

If this is true, then your external HDD's should go *missing* in BartPE as well, if you have a Card Reader whose drive letters are assigned at a lower letter than your external HDD's in WinXP!

**********************************************

Brian

If you re-assign your external USB HDD to K:\ and L:\ beyond your Card Reader--if you boot to BartPE now--can you see your external USB HDD?

Ghost4me
Quote:The Ghost 10 inability to see the usb drive is the same results I had with BartPE.  BartPE honored the MountedDevices registry entry.  WinPE is the culprit, not the application.  


NightOwl wrote on Apr 10^th, 2006 at 10:01am:

Is this true!  I must have missed it!   So, if you change a partition drive letter in WinXP from say E:\ to Q:\, and then boot to the BartPE--it will be Q:\ in the BartPE?

Short answer:  that depends.  Don't forget, BartPE is built from your running XP system and your XP setup disc.

I just built a new BartPE boot cd.  Rebooted, and my previously-sticky-usb drive of letter K: was assigned to e: by BartPE.  To see what was going on, I started up the BartPE Registry Editor and compared the MountedDevices from BartPE registry with the MountedDevices from the xp C: drive.  In BartPE, the MountedDevices contained the following letters: a,c,d,e,f,g,h,x.

So in that case since my USB drive (whose DiskID signature didn't match anything in the BartPE MountedDevices entry), BarPE honored the MountedDevices entry and assigned the next available non-used, which was e:.  If there were an entry in the MountedDevices BartPE entry that matched my USB drive, then I assume it would get K: again.

NightOwl:

Quote:

I just think Symantec was trying to be *cute*--*Look--our Recovery Environment is better than yours--We have the same drive letters in the RE as seen in the parent WinXP OS that the user has!* But, they just did a *poor*, incomplete job of it!!!

I disagree.


NightOwl:

Quote:

WinPE is not *equal to* Ghost 10 RE--two separate *beasts*!

I disagree again.  

WinPE is the Microsoft operating system environment.  Ghost 10 RE uses the operating system environment of WinPE.  Both are WinPE. The application that runs within that environment is Ghost 10.

Hopefully this forum allows more than one opinion.

Ghost4me, I am confident that the forum welcomes multiple opinions – so, please do offer your insights on any and all topics!  In my own case, I have found your posts quite valuable.

Concerning Windows PE and the Ghost 10 recovery environment, remember this:  Ghost 10 might not have visibility to an external USB hard disk drive, whereas Ghost 8.2 – running in the same Windows PE environment – does detect the drive.  Therefore, it is not the case that the “problem” resides in the combination of Ghost 10 coupled with Windows PE?

NightOwl wrote on Apr 10^th, 2006 at 10:01am:

If you re-assign your external USB HDD to K:\ and L:\ beyond your Card Reader--if you boot to BartPE now--can you see your external USB HDD?

NightOwl,

My main computer is away being fixed so I can't do the test. I wouldn't expect a problem because it's only Ghost 10 that assigns the same drive letters as seen in WinXP. Ghost 9 and both varieties of BartPE assign drive letters sequentially.

Ghost4me

You made your BartPE from a WinXP that had your USB drive letter assigned as K:\, but when you booted to the BartPE--your BartPE assigned it the *next available* drive letter E:\--I assume this means that the drive letters in BartPE are not *inherited* from the WinXP system's Registry that you used to create the BartPE, nor does BartPE *read* that registry key for *MountedDevices* in the active WinXP OS Registry during boot--but simply mounts and assigns drive letters as they are *seen* during the booting of BartPE.

Is the WinPE that is being used to create the BartPE from a WinXP installation disk?  I believe that Ghost 10 RE is built on a newer version of WinPE--perhaps v2.x--which is being developed for the upcoming Windows Vista release--and the older installation CD for WinXP was based on the v1.x--and Ghost 9 RE used that older version too--so we may be comparing *apples to oranges*!


Quote:

Hopefully this forum allows more than one opinion.

Didn't mean my comments to be taken so personally to mean you are not allowed your own opinion--sorry!

What I was trying to say is that WinPE is a starting point--a foundation for other companies (developers) who want to license WinPE from Microsoft to then customize to their liking--once a company *customizes* it to their specifications--I no longer think the finger points at WinPE, per say, but at the company that has modified it.

So, you don't think Symantec has customized Ghost 10 RE to work to their specifications--and specifically to read the *MountedDevices* registry of the active OS, if present?  You could certainly be right--if Symantec is using the newer version of WinPE--maybe that is the standard way it operates--I presume we will find out when the new version of Windows ships, and if the future BartPE is built from that newer version of WinPE--we'll see that new behavior.

Ghost4me

I'm still confused about these previous comments:


Quote:

Quote:The Ghost 10 inability to see the usb drive is the same results I had with BartPE.  BartPE honored the MountedDevices registry entry.  WinPE is the culprit, not the application.

When did you experience not seeing your USB HDD in BartPE--what was the setup?

In response to my question:


Quote:

Is this true!  I must have missed it!   So, if you change a partition drive letter in WinXP from say E:\ to Q:\, and then boot to the BartPE--it will be Q:\ in the BartPE?

You answered:


Quote:

Short answer:  that depends.

Under what circumstances does BartPE inherit the drive letter that's assigned in the WinXP OS--your response indicated that it was not?!

Brian's response was that BartPE and ReatogoPE assign drive letters sequentially similar to Ghost 9 RE--and the WinXP drive letter assignments are not an issue in those settings.

NightOwl

Quote:

You made your BartPE from a WinXP that had your USB drive letter assigned as K:\, but when you booted to the BartPE--your BartPE assigned it the *next available* drive letter E:\--I assume this means that the drive letters in BartPE are not *inherited* from the WinXP system's Registry that you used to create the BartPE, nor does BartPE *read* that registry key for *MountedDevices* in the active WinXP OS Registry during boot--but simply mounts and assigns drive letters as they are *seen* during the booting of BartPE.

That's my interpretation.  BartPE was built and burned from a Windows XP Professional slipstreamed SP2 startup cd which I made some time ago. That and anything it pulls from my live XP system.

The problem is that we are conjecturing as to the difference between the PE built from the Windows XP installation CD vs. the PE offered to vendors from Microsoft.

I would have expected BartPE to have contained the registry entries of my existing XP Pro system.  Evidently, it doesn't and just builds a minimal PE setup environment.


Quote:

Is the WinPE that is being used to create the BartPE from a WinXP installation disk?

Yes


Quote:

I believe that Ghost 10 RE is built on a newer version of WinPE--perhaps v2.x--which is being developed for the upcoming Windows Vista release--and the older installation CD for WinXP was based on the v1.x--and Ghost 9 RE used that older version too--so we may be comparing *apples to oranges*!

I agree about apples and oranges.


Quote:

What I was trying to say is that WinPE is a starting point--a foundation for other companies (developers) who want to license WinPE from Microsoft to then customize to their liking--once a company *customizes* it to their specifications--I no longer think the finger points at WinPE, per say, but at the company that has modified it. So, you don't think Symantec has customized Ghost 10 RE to work to their specifications--and specifically to read the *MountedDevices* registry of the active OS, if present?

I don't think it is customized, but I don't know.  As I mentioned I do know that Symantec has multiple versions of the Ghost 10 RE on their ftp server.  From what I saw, the various versions were the SAME Ghost 10 program, but different RE configurations targeted at different motherboards, hard drive controllers and other hardware.  But same Ghost 10 program.

NightOwl:

Quote:

I'm still confused about these previous comments:

Quote:

Quote:The Ghost 10 inability to see the usb drive is the same results I had with BartPE.  BartPE honored the MountedDevices registry entry.  WinPE is the culprit, not the application.   When did you experience not seeing your USB HDD in BartPE--what was the setup?

I saw that is my test case #2 (no ide drives attached):
http://radified.com/cgi-bin/YaBB/YaBB.cgi?board=general;action=display;num=1144131251;start=15

NightOwl:

Quote:

Under what circumstances does BartPE inherit the drive letter that's assigned in the WinXP OS--your response indicated that it was not?!

"So in that case since my USB drive (whose DiskID signature didn't match anything in the BartPE MountedDevices entry), BartPE honored the MountedDevices entry and assigned the next available non-used, which was e:.  If there were an entry in the MountedDevices BartPE entry that matched my USB drive, then I assume it would get K: again."

My response (in quotes above) is that depending upon the version of BartPE, and XP upon which it's built, and xp startup cd, then *IF* BartPE pulls in the MountedDevices entries from the live XP system, it would honor them.

My case #2 showed BartPE and WinPE behaving the same regarding the IDE drives.  Not sure why in that case.

Obviously, still some mysteries here . . .  but glad to acknowledge and accept all points of view.  Thanks.

Pleonasm wrote on Apr 9^th, 2006 at 3:08pm:

ERD Commander 2005 is a set of tools on a boot CD that claims to be able to edit the registry of a PC.

I've taken up an offer to play with this. Regedit does show the WinXP registry unlike the BartPE Regedit. Drive letters are assigned sequentially, like Ghost 9.

Brian

Where did you get a copy of *ERD Commander 2005*--even the 7-day temporary license download is $499.00--or should I not ask  :-X ?!

$$$$. I tried it on a friend's computer. Most of what I saw is already on ReatogoXPE.

I had to try this. Using my second WinXP partition I deleted the subkeys from MountedDevices and rebooted. As expected my drive letters were now sequential. I restored an image to this partition, booted to ReatogoXPE and deleted the subkeys using Registry Editor PE. Rebooted and the drive letters were now sequential.

It's not so hard even though I had misgivings a few days ago.

Brian

Thanks for reporting the results of your experiment on editing the WinXP Registry using *Registry Editor PE* on the *ReatogoXPE*.  This adds to our collective knowledge base regarding the issue of *missing drive letters* in the Ghost 10 RE.

This is a *way out there* question--but you have lots of experience with BartPE, and maybe visit some forums where things like this may be discussed.

Have you seen any discussion about the fact that WinPE is out in more than one version--I think Microsoft has introduced v2.x last summer (2005) and that may be what's on the Ghost 10 Recovery Disk vs v1.x that's probably on the Ghost 9 Recovery Disk.

1.  Is there any evidence that the newer WinPE is being shipped on more recent WinXP installation CD's?  

2.  Can the new version of WinPE be used to create the current BartPE?

3.  Here's the way out part--when BartPE needs the WinXP CD to build the BartPE CD--is it using the WinXP CD to just load the 4 sector boot image, the *Microsoft Corporation.img*?  

Is that boot image the *WinPE*--and everything else on the installation CD in the data portion is the *customization* of the WinPE environment?

Could one substitute the Ghost Recovery Disk for the WinXP installation disk so as to build the BartPE that now is using the WinPE v2.x?

NightOwl wrote on Apr 13^th, 2006 at 8:47am:

"... Could one substitute the Ghost Recovery Disk for the WinXP installation disk so as to build the BartPE that now is using the WinPE v2.x ?..."

A fascinating notion, indeed !!!

EP :'(

NightOwl asked (in Reply #34), “Would it be *hard* to explain to someone how to navigate to the *MountedDevices* key values so they can be deleted?”

Saving the following text to a registration entries file (e.g., ClearMountedDevices.REG) and double-clicking the file ought to clear the registry key automatically by first deleting the key and then recreating it.  (Lines 2 and 4 in the file are blank and are required.)

REGEDIT4

[-HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices]

[HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices]

NightOwl, are you willing to give this a test?

Readers of this thread may be interested in reviewing these two Microsoft articles to learn more about Windows PE:

• Windows Preinstallation Environment Technical Overview
  
• Windows PE 2.0 for Windows Vista Overview

Now, in the spirit of “creative thinking,” here is a hunch based upon the following two Microsoft articles:

• How to Customize a WinPE Startup Process
  
• A Description of the Diskpart Command-Line Utility

Taken together, these two articles appear to suggest that (1) the startup process of WinPE (in the file STARTNET.CMD) can be modified, akin to a DOS AUTOEXEC.BAT; (2) the DISKPART utility may be invoked during the WinPE startup process; and (3) that DISKPART may be used to assign drive letters to partitions.  If a modified STARTNET.CMD file can be injected into a Ghost 10 recovery environment ISO file and then burned to a CD, might that be a way to control and customize the drive letter assignments?

Also of interest may be this:  BartPE StartNet Plug-In

NightOwl wrote on Apr 13^th, 2006 at 8:47am:

Have you seen any discussion about the fact that WinPE is out in more than one version--

I saw that comment in this forum so we are probably referring to the same post. I don't know if it's true.


Quote:

when BartPE needs the WinXP CD to build the BartPE CD

The BartPE download is around 5 MB. It needs a WinXP CD to build the final product which is around 300 MB so a lot of Microsoft files are taken from the CD. There is only one BartPE. Reatogo has a licence from Bart to use his software. I've built a BartPE CD utilizing the XPE plugin but it wasn't a patch on Reatogo's version. It's interesting to read Bart's comments on his  initial attempts at creating a PE.


Quote:

Hi, my name is Bart Lagerweij. I've been creating DOS based boot disks and bootable CD-Roms from Dos 3.x (not sure what year) until 2002. I have created the: Corporate Modboot, Network bootdisk, CD-Rom bootdisk, a hardware independent Dos CD-Rom driver eltorito.sys and lots of other tools needed to boot a PC the way I want it to. As you can read above I've stopped doing that in 2002. Why? I saw a Windows PE (WinPE) bootable CD-Rom (from Microsoft) in action and I got very, very curious. I knew then as I know now, that in time PE-based solutions will be every PC technicians best friend. Goodbye to all the good and bad dos-based NTFS utilities! Now we can boot from a CD-Rom and have full read/write access to NTFS volumes! Here are a few things that are possible with PE and are not possible with any type of dos-based boot disk, even when using network support and ntfsdos:    * Accessing very large (>2TB) NTFS volumes or accessing volumes that are not seen by the BIOS, like some fibre channel disks.    * Very reliable scanning and cleaning of viruses on NTFS volumes using a "clean boot".    * Active Directory support.    * Have remote control over other machines, using vnc or remote desktop. While I was already thinking about what great things this could do, I noticed the end-user license agreement for Microsoft software that is included with Windows Preinstallation Environment (Windows PE) 1.2 (eula.txt). In section "1. ELIGIBILITY." it states the following: ..."You may only install and use the SOFTWARE PRODUCT if you are an active Microsoft Software Assurance Member ("SAM") for the systems product pool or servers product pool, if you currently have license coverage for Microsoft Windows operating system (OS) Upgrades via a Campus Agreement or School Agreement, or if you are a current or former participant in the Windows XP Joint Development Program, Windows XP Rapid Adoption Program, Windows .NET Server Joint Development Program, or Windows .NET Server Rapid Adoption Program. If you do not meet one or more of the requirements listed above, you may not install or use this SOFTWARE PRODUCT and you must terminate the installation of this SOFTWARE PRODUCT immediately"... Oops, that does not include me. As a matter a fact that does not include most of us! This was very disappointing. But then I started thinking, how difficult can it be to build something similar to Windows PE from a Windows XP installation CD-Rom? A quick file compare looked like most of the needed files are on the Windows XP CD-Rom. Only because I thought building this would be easy, I started coding my own builder program. Had I known how hard it would be, I would probably never have started programming PE Builder. This first version (v1.0.0) of PE Builder was released on April 28, 2003. Yes, version 1 was a very simple, very static, very bad and copyright violating program. And the (very friendly) people at Microsoft had every right to kick my butt. But I learned from it and in May 2003 I started on a second version. In July (three months later) v2 was ready. Version 2 did not have the problems that version 1 had. The version 2 build engine had its own registry hive builder which was not easy to program and took about 50% of my research and coding time. It also was dynamic enough that it could build from Windows XP and Server 2003. In v2.0.1 I added a small but very powerful menu program called nu2menu, which was written by my buddy Henk de Jong. The latest 2 version (v2.0.2b) even used a new ISO filesystem called "ISO-9660:1999 (version 2)" instead of the Joliet extensions. Some non-English versions of Windows XP had filenames longer than the maximum allowed length for Joliet filenames (103 chars). I had to patch the ISO building program (mkisofs.exe) so that the Windows NT bootstrap and setup loader would boot properly. The file and directory names can now be up to 207 characters. But again this version had something bad. When comparing some INF files they looked too much like the Windows PE builder from Microsoft. I had to change the entire INF file layout to use its own format. And on Sep 1, 2003 (almost 6 months after starting) version 3 was ready. After adding plugin support, PE Builder got very popular. People from all over the world are writing their own plugins to add the program they like and use.

Quote:

Could one substitute the Ghost Recovery Disk for the WinXP installation disk so as to build the BartPE that now is using the WinPE v2.x?

After reading Bart's comments, no.

Pleonasm wrote on Apr 13^th, 2006 at 11:06am:

REGEDIT4 [-HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices] [HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices]

Pleo, brilliant. It works. I ran the reg file and when I looked in MountedDevices all keys were gone. I rebooted and the keys had been recreated and the HD drive letters were sequential.
At least this averts asking someone to navigate the registry.

Pleonasm


Quote:

REGEDIT4 [-HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices] [HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices] NightOwl, are you willing to give this a test?

Looks like Brian beat me to it--but, in post #34, I was actually referring to editing the Registry while using BartPE or ReatogoXPE--I was not thinking about an easier way than RegEdit if able to boot and use a *healthy* WinXP--but your addition is a nice touch!

NightOwl,

http://regeditpe.sourceforge.net/

When I first saw this page I thought they were demonstrating an example registry edit and I wondered what I should click. But you just click everything shown on this page, exactly. I read too much into it.

Then edit _REMOTE_SYSTEM\System\MountedDevices (or just look if you are learning).

After you have run the program once, it's obvious. But as John mentioned, you have a long way to go if you don't know how to build a ReatogoXPE CD.

Brian wrote on Apr 14^th, 2006 at 1:53am:

After you have run the program once, it's obvious. But as John mentioned, you have a long way to go if you don't know how to build a ReatogoXPE CD.

The main reason I moved choices D and E to the bottom of the Simple solutions: USB2/Firewire drives & Ghost 10 Cookbook was because of the complexities and knowledge required to first build a BartPE or ReatogoXPE cd.  If you have a damaged or corrupt operating system, chances are you can't build a BartPE cd.

I've created and used them both.  BartPE was the first "troubleshooting boot cd" that I ever found; it's been around for quite awhile, and it's saved my b*tt several times.  

BartPE is a little more difficult to understand how to add your plugins to.  ReatogoXPE has a simpler pick-and-choose approach.  They are both great tools for an PC tech person, but neither is for a novice, either to build or use.

Great topic! :) Thanks to everyone that contibuted. I'm new to this forum and I just saw this topic today. I would have loved to have taken part back in April. Please forgive me for butting in at this late date.

Fisrt, I'll try to shed some light on some of the unanswered question about WinPE and how Symantec is using it to run the Ghost 10 RE. Second, I'll offer a method of modifying the Ghost 10 CD to allow you to edit the remote registry directly from the Ghost 10 RE.

Both Ghost 9 and Ghost 10 run on  WinPE 1.0. (I'll call it 1.0, but I don't know the exact numbers Micosoft uses). The Ghost 9 RE was built using WinPE based on WinXP/SP1. The system drive (that's the drive you boot the CD from) gets assigned a drive letter sequentially after all the volumes on the hard drives in the system. The Ghost 10 RE was built using WinPE 1.0 based on WinXP/SP2. The system drive is hard coded as the X: by SP2. WinPE 2.0 (introduced with Vista) uses a totally different boot stucture. BTW, Microsoft is now giving WinPE 2.0 out for free in the Windows Automated Installation Kit if you want to play with it.

Symantec is allowed to modify WinPE to run as they wish. The default shell in WinPE is the command prompt, but it is set up so that OEM's can easily subsistute their own custom shell. Symantec has provided a GUI shell that runs the RE programs they also provided. Based on NightOwls work, I can say that Symantec has obviously modified the way drive letters are assigned in the Ghost 10 RE. Standard WinPE and BartPE  do not do this.

Now for the constuctive part of this post. Would you like to have the ability to edit the remote registry and truely explore the drives in the system directly from the Ghost 10 RE? Follow these steps and you can:

1. Start with my guide on how to add drivers to the RE posted here http://radified.com/cgi-bin/YaBB/YaBB.cgi?board=ghost9_10;action=display;num=1165214368.

2. In step 6 also enable the A43 File Managment Utility.

3. Now go to the copy of your Ghost 10 CD on your hard drive. Navigate to the I386\Shell\Utilities folder. Now choose one of the utilities you can live without. Let's say PTEDIT32.EXE. Rename it to something like PTEDIT32.EXE.ORG so you can put it back later if you wish. Now copy "CMD.EXE" from I386\System32 to the Utilities folder. Rename "CMD.EXE" in the Utilities folder to "PTEDIT32.EXE".  I think you get the picture. We are going to trick Ghost into running a command prompt when we go to the Utilities menu and click Edit the Parttion Table.

4. Now continue on with steps 7 and on in the add drivers guide.

When you boot the modified CD it will act just like the Ghost 10 RE you have been used to using. Except, now when you click Utilities/Edit Parttion Table you will be brought to a real command prompt. Now you are actually in the default WinPE shell. To edit the remote registry enter "regedit". The registry editor will open. Highligt the HKey_Local_Machine key. Now go to the File menu and choose Load Hive. In the window that opens click the drop down menu for the Look in box. Choose the drive letter of the system you wish to edit the registry. Let's assume it is the C:. Now navigate to C:\Windows\System32\confg. In the config folder choose "system" and click the Open button. In the next window name the hive "REMOTE_SYSTEM" and click the OK button. Now you can go to HKLM\REMOTE_SYSTEM\MountedDevices and remove what you want. Next, highlight the HKLM\REMOTE_SYSTEM key in the left hand pane. Then go to the File menu and choose Unload Hive. Now you are done, you can close the registry editor. You will have to reboot directly back to the Ghost 10 RE and all your missing drive should show up thanks to NightOwl.

Edited 12/10/06:
You could add more plugins (this is limited to plugins that do not include registry entries) when you build the CD. You will also need to enable the Nu2Menu plugin or you will get build errors. Hmm, the Registry Editor PE plugin comes to mind. Once you are in the Ghost 10 RE at our freind the real command promt. You can enter "cd X:\Programs\A43". Then enter A43.exe. Now you can browse to X:\Programs\RegisterEditorPE and double click RegistryEditorPE.exe to start the program. Using A43, you can browse all your hard drives with the ability to add, delete or edit files as you wish.

Enjoy.

mustang,

Thanks for that really interesting information. I didn't know we could add plugins to the Ghost CDs. I built a CD and found the NU2Menu plugin had to be enabled otherwise there were build errors with your plugin. A43 worked fine but the TI plugin started with an error re "proper serial number". It's the plugin from my ReatogoXPE. Don't worry as I'd prefer to run it from ReatogoXPE. It's faultless from there.

Hi Brian,

Thanks for the feedback.


Quote:

I built a CD and found the NU2Menu plugin had to be enabled otherwise there were build errors with your plugin.

You can leave the Nu2Menu plugin disabled if you edit each plugin you add and remove the following two lines (they are usually at the end of the file):


Code:

[Append] nu2menu.xml, A43_nu2menu.xml

The name will be different in the second line for each plugin, just remove those two lines and the build errors will disappear.


Quote:

A43 worked fine but the TI plugin started with an error re "proper serial number".

Yeah, that's what I get for not testing! You should only add plugins that don't make registry entries. Some of my entries didn't make it into the registry. The A43 and Registry Editor PE plugins both work, as they need no registry entries.

I'll go back and edit my post above to make this clear.