Ghost Solution Suite

I am trying to clone a Dell GX270 using a Dell GX260 image.  The 260 is a Uniprocessor machine and has only IDE connections for the drives which is why I chose it for the source image.  The 270 is a multiprocessor machine with a IDE connections for the drives.  There is a difference in the two motherboards enough to require an updated driver for the Mass Storage driver.  I have updated the driver database with the correct Mass Storage drivers as downloaded from Intel's website using their hardware identification utility.  I have rebuilt the WinPE images using the new driver database and made sure to check the option for include the Deploy Anywhere driver database in the image.

When I go to clone the 270 the Evaluate Deploy Anywhere step succeeds as well as the Deploy Anywhere step as well as the SID change step.  Then when it comes time to reboot the machine into the target OS it fails with a BSOD that moves by so fast that I can't read it and it promptly reboots itself and repeats this process until I intervene.

I tried to run just the clone step on the machine so that I could manually run the ghdplyaw32.exe command but it has now just sat at the words "performing evaluation" for the past 3 hours.  My question is if Deploy Anywhere is having problems with being manually run then why is it reporting success to the console and proceeding with the rest of the task when clearly it is not succeeding at all?

Any ideas?

Just to clarify I've tried new drivers, rebuilding the image with the drivers, and manually running the ghdplyaw32.exe command all with no success.

DA will pick the best driver that it can find. With IDE quite often this means that generic IDE driver that is shiped with any version of Windows is good enough and so DA might decide that it is OK to use it instead of the one in the driver database. Basically DA does some checks to ensure that device IDs, vendor IDs and other parameters are matching and if so then it will use the selected driver. That doesnt mean that it will be the driver you chose for it if generic one satisfies everything.

So, from DA perspective it has found correct driver and installed it hence why success in Console. Can you please confirm vendor and device IDs for this IDE controller?

Thanks.

The controller is an Intel 865G as identified from Intel's chipset identification utility and I downloaded the correct driver for it from them directly.

That is still weird though that DA would report success even though when it is manually run it never gets to the point where it says that it will do anything.  It just sits on Performing Evaluation.  It's still sitting there now.  I left it overnight just to make sure that it wasn't just taking an abnormally long time.

I'll ask person who is more knowlegable in this area to help you out.

I don't know why you are getting the initial blue screen.  We'll come back to that at the end.

There are some differences in the set of drivers that DA iterates over when run manually and as part of a console task.  In the manual case it will iterate over all of the drivers in the /ddb= directory that have valid driver.inf files.

When DA is run as part of a console task, it is the console which sends down a subset of the driver database to the client and DA iterates over that subset.

I suspect that the reason you are getting different behaviour when you run DA manually is that it is then iterating over drivers that were not in the subset sent down by the console and it is encountering a problem in parsing one of them.  I can send you a trial exe that may fix this problem if you send your email address to michael_franklinATsymantecDOTcom.

Once you can run DA manually, if it's still blue screening please put the /debug switch on the command line and send me the resulting ghdplyaw32.txt file from DA's working directory.  I would need to know the PCI ID string of the IDE device.  Something like:

PCI\VEN_8086&DEV_2651&SUBSYS_3005103C

Ok, I manually ran the "ghdplyaw32.exe /eval /debug /target=c:\windows" command just after a fresh clone task and this time it errored out on me immediately with "The Class GUID true does not exist in file c:\windows\inf\hal.inf". 

What does this mean for me?

Wait a minute... the clone task failed when it got pushed down to the client because of network storage problems we had on Friday.  I need to re-clone the client. 

Ok, I have attached the log files that were produced from running each of the two ghdplyaw32.exe commands.  I'm not sure what exactly I'm looking at as far as the chipset ID.  I see the integrated network card vendor ID and several USB IDs but not the chipset.

So are you now saying that the problem with DA apparently hanging is no longer there?

Are we left with the case that after apparently successfully retargeting the image you get a blue screen on reboot?

Where are the log files? -ok I see them attached to the first post in this thread

What version of DA are you running?  - right click C:\Program Files\Symantec\Ghost\ghdplaw32.exe and click the version tab

Thanks

That's the weird thing about all of this.  I was consistently getting a hanging program with ghdplyaw32 when I ran it manually until I started running it with the /debug switch.  I'd have to reimage again to see if it really is the /debug switch that is keeping the program working.

I am still getting the blue screen on reboot after a successful run but that should be more a problem of drivers from what I understand of the situation right?  At that point it's a matter of finding which driver DA is trying to use and then remove that one from the database.

The version of DA I am running is 11.5.0.2141.

I have yet to try and run the trial exe that you sent me.  I'll run some tests using the original file for now.

A thought has occurred to me just now.  In a future revision of DA you could make it so that it first collects all the drivers that match the hardware ID and then first choose the particular driver that has the newest date of addition to the database.  This would solve a lot of problems with having to update the driver database with a new driver and having to figure out which other driver might possibly apply to the system and then remove them.  This would also solve a problem where a user adds the latest driver to the database but that particular driver is causing a problem and needs to revert to an older driver by simply adding the old driver after having added the new driver.  The only drawback that I can see with doing it this way is that the database would have a tendency to grow but, so long as the user named their drivers correctly, then they could always go back and delete their own old drivers from the database.

A step beyond that even would be to have the system look through the database at the time of adding a new driver to see if the new driver would be replacing an existing driver and then give the user the option to either replace the driver with the new files or to continue adding a new driver option.

Ok, I have tested manually running the ghdplyaw32 command without using the /debug switch and it is now completing successfully.  Maybe the network storage problems we were having last week were causing an issue with the clone image and DA was getting stuck on the transmission errors.

I am still getting the BSOD though.  I need help finding the hardware ID in my logs and I need help with finding what driver is being used from the database so that I can remove it and try again.

So you have used the new exe that I sent you and that doesn't fix the BSOD?

When I looked at the logs you posted earlier the eval was not finding any missing drivers so DA is not actually installing any new drivers at all.  DA is updating the HAL and there have been some problems with more modern machines and XpSP3 but I'm not aware of any with older machines such as the ones you are using.  I did notice that it looked as though you had run DA previous to making the image? Or maybe this is just to do with the problems you have been having.  I would be interested to know if DA really is adding drivers.  Boot into WinPE and lay down the image.  Are there any entries under c:\drivers\symantec?

Run DA manually - what are the entries under c:\drivers\symantec?


I noticed that HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DevicePath has a lot of added drivers, and its possible that one of those drivers is causing a problem.  Try removing the added drivers from that key [make sure that %systemroot%\inf is still there]  BTW it would be more standard from a GSS perspective to add those drivers to the ddb and let DA select those it thinks are needed.

The image appears to have been sysprep'd - another place that things could be going wrong.

The questions that you raise about the ddb management and  making DA prefer drivers are interesting, and deserve a detailed reply.  But I don't have time for that right now.  One of the things you are asking for is a way to annotate drivers in the ddb to make DA prefer them.   DA has a weighting mechanism that it uses to choose the driver most likely to be the one prefered by Windows.  It's a more complicated problem to ensure that a specified driver is the one that Windows will prefer.

"So you have used the new exe that I sent you and that doesn't fix the BSOD?"

I have not used that yet since I wanted to test the functionality of the older DA files.  I wanted to make sure that the BSOD wasn't being caused by transmission errors due to the problems with our network storage.  We have fixed the problems with our storage and the BSOD is still happening but at least it isn't hanging up the system anymore.  I'll have to try the new file you sent me next to see if that clears the BSOD.

"I did notice that it looked as though you had run DA previous to making the image?"
 
The image was originally built on a GX270 and I used Ghost to image the GX260 with DA enabled to run.  It didn't work successfully because of the HAL problems of going from a multiprocessor to a uniprocessor HAL.  When this happened I just ran a repair on the OS and it fixed everything so I took that image and put it up on the server to use for the rest of the machines.  We'll be starting a new semester here soon and I'll be able to rebuild the original image from scratch then.  I don't know if there would be any existing damage in the OS from doing things this way but I figured that it should work since it does replace all drivers and system files and it did make the system start to work after I ran the repair.

"I would be interested to know if DA really is adding drivers. Boot into WinPE and lay down the image. Are there any entries under c:\drivers\symantec?"

There is no such directory on the destination C drive after the image has been layed down.

"I noticed that HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DevicePath has a lot of added drivers, and its possible that one of those drivers is causing a problem. Try removing the added drivers from that key [make sure that %systemroot%\inf is still there] BTW it would be more standard from a GSS perspective to add those drivers to the ddb and let DA select those it thinks are needed."

I put those drivers in that path so that when the system gets booted into the OS that it would automatically find the video drivers and sound drivers and everything else that is vital to making the computers work as soon as possible after having been imaged.  When it comes time to reimage our 5 labs of 30 computers each it would be best if the installation of these drivers could be handled automatically.  I didn't realize that DA was using this path as well.  Seems to me that it shouldn't (if it really is) because then it might start pulling drivers from the different source systems instead of pulling them according to what the imaged system needs.

"The image appears to have been sysprep'd - another place that things could be going wrong."

Do you mean previously on this particular image or at all?  I thought Sysprep was supported by GSS.

I have tried the new file you sent me in every conceivable way but no matter how I name it it will not work.  The error it says is "The system cannot find the file x:\ghost\ghdplyaw32.exe".  Any ideas on what I'm doing wrong or how to fix this?

Just to clarify.  I'm in the working directory when I execute the file.  I can run "dir" and I can see it sitting there but it turns blind everytime I try to run the file.

Go to your Ghost installation [typically C:\Program Files\Symantec\Ghost] and rename ghdplyaw32.exe to something else so you keep the older version

copy in the new exe that I sent you

Go to the Ghost Boot Wizard and edit the WInPE that you are using

check or uncheck one of the drivers - this will force a rebuild of the WinPE with the new version of DA

Lay down a fresh image on your target machine and try the new exe - note that running DA over an image that has been retargeted [without then successfully booting through mini-setup] is not supported

It still could not find the file ghdplyaw32.exe even after having rebuilt the image.  I believe that the exe has somehow gotten corrupt somewhere along the way if this particular file is working for you at the moment.

Ok, there are a number of possibilities so let's work through them

1) the exe is corrupt - I have resent it with an md5 sum

2) there is a problem in rebuilding your WinPE
- just try copying the exe in x:\ghost once the WinPe has booted

- if you are using the 256Mb WinPe try the 512Mb one.  If that is not possible then try removing some of the drivers you have enabled in the Ghost Boot Wizard and then try rebuilding you WinPE.  It's possible that because you are short on space something is going wrong

Can you please tell me if the machines mentioned at the start of this post have Intel of AMD processors?

I never could get that file to work, by the way.  It just kept saying that the file wasn't there even though I could do a dir *.* and find it manually.

At any rate, I finally got the time to create a brand new, fresh, image on my source GX260.  I successfully created an image from this machine and then was successfully able to push the image out to a GX270 and a GX280.  So the solution for my problem was to create a new image and work from there because GSS 2.5 didn't like that it was working from an image of an image of an image.  My regsitry changes to the "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DevicePath" location with the path to all of my various drivers is working wonderfully as well because not only is the network card and mass storage driver working (default support from GSS 2.5) but my video card and sound card and everything else is installing perfectly as well for each hardware profile.

Thanks alot, Michael, for your assistance here.