Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Ghost client failure

Created: 09 Jan 2013 | 21 comments

Hi

I'm having an issue with the ghost client stopping on an XP Pro machine. From memory, it is Ghost 7.0.1.355. That should at least be close. The log in the Ghost console shows:

Task Name: <Hostname> - Manual Baseline Backup Task
User: Administrator
Execution Time: 1/8/2013 9:20:47 PM
Number of client machines: 1
Clients finished OK: 0

Task warnings:0

Task process listing
<Hostname> - administrator Wake-on-LAN 1/8/2013 9:20:48 PM Success
<Hostname> - administrator Update DOS system files 1/8/2013 9:20:58 PM Success
<Hostname> - administrator Update DOS Network Drivers 1/8/2013 9:20:58 PM Success
<Hostname> - administrator Changing Logon Settings 1/8/2013 9:20:58 PM Success
<Hostname> - administrator To target operating system 1/8/2013 9:23:10 PM Success
<Hostname> - administrator Create Incremental Snapshot 1/8/2013 10:02:36 PM Success
<Hostname> - administrator Changing Logon Settings 1/8/2013 10:02:36 PM Success
<Hostname> - administrator To Virtual Partition 1/8/2013 10:22:38 PM Failed
Details for: To Virtual Partition

On the client, within seconds of the 10:02:36 entry, the service manager puts an entry into the event viewer that says that the ghost client died unexpectedly. There are no files ngerror.*. There is an vpart.txt (I'm not sure that was the name) that looks like:

Processor exception
Generated at G:\750\src\Trunk\Win32\HardExceptionHandlerWin32.cpp:620

Program Call Stack

Exception code: 0xc0000005 ACCESS_VIOLATION
Fault address: 0x01a0bbf9 0x0001:0x0006abf9 C:\Program Files\Symantec\Ghost\MACHCONF.DLL
Registers:
EAX=0x01ad2000 CS=0x001b EIP=0x01a0bbf9 EFLGS=0x00010202
EBX=0x01ad1fe8 SS=0x0023 ESP=0x00d3e908 EBP=0x01ad1fb0
ECX=0x01ad1fe8 DS=0x0023 ESI=0x00d3e94c FS=0x003b
EDX=0x000001ad ES=0x0023 EDI=0x01ad1fe8 GS=0x0000

Call Stack
Address    Frame      Logical Addr      Module
0x01a0bbf9 0x01ad1fb0 0x0001:0x0006abf9 C:\Program Files\Symantec\Ghost\MACHCONF.DLL
0x01acec98 0x01a1f8a0 0x0000:0x00000000
0x019fc0c0 0x019fbfe0 0x0001:0x0005b0c0 C:\Program Files\Symantec\Ghost\MACHCONF.DLL
End Call Stack

At one point, this process was working. I have no idea what has changed and I also have no idea how to get it going again. Would someone please clue me in?

Something of an aside, I read somewhere about running ngctw32 -recovery and gave it a try. While the run itself successfully contacted the server, I find myself unable to get out of the app and unable to find any documentation on how to do so. Once I hit ^Break, I got the c:\ prompt, but all commands seem to get "bad command or filename" and rebooting only returns to it. How do I get out of this??? Booting off a CD and editing the partition table seems less than optimal though effective.

Thank you

Ed Hoeffner

Comments 21 CommentsJump to latest comment

EdT's picture

This is an incredibly old version of Ghost that you are using with an MSDOS boot environment.

My suspicion is that the target hardware may not be compatible with a DOS boot environment, as DOS does not support SATA hard disks (unless you can select compatibility mode in the BIOS to make the hard disk emulate the older IDE standard). Errors involving a virtual partition are usually caused by issues with hard disk accessibility, or with a failure of the network drivers to connect - the latter would not appear to be the issue you are seeing.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

InAtari's picture

Hi

I'd have to agree with you except this was working for many months. I was able to get the version and it is 7.5.0.335 as seen from the Ghost console on the server. I haven't tried reinstalling, but I was hoping to avoid that.

Do you happen to know a clean way to exit the DOS env?

Thanks

Ed

EdT's picture

There is no way to exit the DOS environment other than switching off the machine - after all, what is there to exit to ??

If this has been working for many months and is now not working - something has changed. Are you able to determine what?

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

InAtari's picture

When you switch off the machine, it just boots right back into the DOS env. I'd like to be able to go back into XP without having to edit the partition table.

As far as what changed, I agree something must've changed, but I've no idea what. Certainly not the disk itself or any major hardware items. I don't *think* anything. I keep up with patches, which would be my guess (and only a guess). Any suggestions on where to start looking? What types of changes could cause this?

Thanks

EdT's picture

So what you are saying, if I understand correctly, is that your PC is effectively dual booting, but defaulting to booting into DOS rather than XP.

What I would suggest is that you have a close look at the boot.ini file (hidden file in root of c:) that is getting installed as part of your XP image. There is plenty of information on how this is formatted, but as a start, you can set the timeout parameter to 5 so that you have 5 seconds to choose which environment to boot into, and then have a look at which boot option is set as the default. Chances are this has changed to specify DOS as the default rather than XP.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

InAtari's picture

Sorry, I guess I wasn't clear enough. Under normal conditions, it boots into XP just fine. It is not a dual boot situation. XP only. In this case, running ngctw32 -recovery alters the boot partition to a small one that it creates and changes the drive letter of the current boot partition. Once in this state, the only way to get back to XP is to delete this little partition that's labelled C: in the table and set the old C: partition back to active. Then it will boot as normal.

This also used to happen if the client failed to connect to the server at the start of a backup. The only way to restore the machine was to edit the table. There must be a better way since when the backup ends normally, the machine boots back into XP.

Thank you!

EdT's picture

I'm really not sure why this needs to happen at all. You boot the target system, run Ghost and load the image onto the hard disk. Whether this is from a local image source or from a network source is not really relevant.

If you need to, you could add code to wipe the hard disk entirely and repartition it according to your needs to ensure a correct starting environment but this is not usually necessary.

Maybe there is something about your old version of Ghost that I am misunderstanding, but over the many years I have used various Ghost releases, I have never seen the problem you describe.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

InAtari's picture

Hi

Prior to Ghost, the partitioning is just fine (as seen in XP disk manager):

50M Dell Partition |||           300G Active C:                                                   ||| Some tiny unused partition

Now, Ghost boots up in some form (ngctw32 -recovery or maybe Ghost failed to connect to the server) and boot into CD:

50M Dell Partition ||| A little less than 300G Healthy D: ||| Small size Active C: ||| Some tiny unused partition

I don't remember the size of the created partition, but it's pretty small.

It is booting off the small C: partition and will continue to do so until you come in and edit the partition table to get rid of that small partition and label what is now the D: partition as active. Reboot and it comes back as the C: drive.

Thanks!

EdT's picture

Is the DELL partition formatted as FAT or NTFS ?  Is it marked as a hidden partition?

Are you able to provide the exact Ghost command line(s) that are used to deploy the image to your machine?

I'm wondering whether the DOS boot can "see" the existing DELL partition and therefore assigns C: as its drive letter and puts the main image on D:  However, that does not explain where the tiny C: partition is coming from, as it does not make sense for a single partition image to result in two partitions on the target machine. 

This leads me to add that I am making assumptions based on unknown factors. Are you restoring a partition image (my assumption), or could this be a disk image which may comprise more than one partition? Are there any commands in the imaging process that are manipulating the partition structure?

One thing you could try is to make a copy of the DELL partition, and then wipe the hard disk entirely, then restore your image to the blank hard disk. Does this solve the issue?

The logs you have provided don't really tell me anything. So what would help is to understand the exact process that your Ghost imaging scripts are carrying out.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

InAtari's picture

I now see where I've done 2 things wrong. My apologies. I should never have mixed 2 issues together. The logs I sent were for my real problem, which is that the client is not backing up now where it used to before. In the process of trying to solve that, I did a ngctw32 -recover from the command line on the client because I'd read a little about it and hoped it would fix whatever was creating the not backing up problem. All it did was attempt to boot into ghost, getting hung on connecting successfully to the server, and a reboot would just start doing that all over again. We had that issue before when the client would sometimes be unable to connect to the server during regularly scheduled backups, and the only way I ever found of being able to reboot back into XP was to edit the partition table as described above. That tiny partition is created by ghost. Since I created a problem that bothered me before while trying to deal with the failing backup issue, I thought I'd ask that question also. I should not have done that.

To sum up, the main issue here is that the client backup (not restore) is failing. The logs, etc. above relate to that issue. A separate issue/annoyance is that when things go wrong in ghost, it can leave the machine in a state where it won't boot into XP and the only way to get it back to XP is to edit the partition table.

Sorry about the mess.

EdT's picture

The log shows that there was a problem with the virtual partition. The most common cause of this I've covered in my first reply, so can we go back to the issues around bios settings and the hard disk subsystem.  You say nothing has changed, but is the machine you are having problems with, a machine that worked previously, or is it a new purchase?  Have there been any updates applied to this machine, eg bios updates, or has the motherboard been changed?

The problem with using MSDOS with modern hardware is that it does not support the standard SATA hard disk interface that machines now ship with, so MSDOS cannot "see" the hard disk which prevents you taking an image.  Most bioses still have a "compatibility mode" setting which allows the hard disk to "emulate" the older parallel ATA standard which needs to be set if using MSDOS.  If this machine is new, or has had a bios upgrade or a motherboard change (for example), then the bios is almost certainly defaulting to AHCI enabled which would give you the sort of problems you are experiencing.

Alternatively, if there has been a hardware change which affects the network interface, it is possible that the network driver file in your MSDOS boot environment no longer works and needs updating.

Your original posting does not clarify whether this issue affects one specific machine or all of them - and again, this has a substantial impact on where you need to focus your diagnostic efforts.

And yes - mixing two different issues does cause all sorts of confusion ;-)  Sticking to one issue at a time and providing maximum detail is always the best way to go!!

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

InAtari's picture

This machine was working just fine for many weeks (A year or 2 anyway). As far as I know, there have been no changes other than OS patches. The user would let me know if she was going to do anything to it and would very probably ask me to do it. Certainly, there have been no hardware changes. I have not flashed the bios and don't believe the user would be capable of doing so. I'd ask but she was out today. At present, this is the only machine being backed up. The drive is a SATA drive. Any bios settings that I should post?

EdT's picture

What is the bios setting for hard disk?  Is there a compatibility mode setting for the HD, and if so, is it enabled?  If it is not, try enabling it and see if that helps.

Also, check the amount of free space on the hard disk, run CHKDSK and also run DEFRAG. Make sure there are no virus infections.  Check the event log to see if there are any reported hard disk errors.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

InAtari's picture

Other than "On", there is no bios setting for the disk. There is a SATA operation mode, which is set to "Normal", not "Combination". Normal is the default as it was originally setup. There's 34G free on the drive. The event viewer shows no errors related to the disk. As for the rest, I'm going to wait until I know the important files are off the machine somewhere.

I watched the machine this time around, and there is nothing to be seen at the login window. The Ghost warning just goes away and becomes the regular windows login window.

The machine is running Symantec Endpoint Protection and also has McAfee installed, though the McAfee service is not started.

EdT's picture

It is considered bad practice to have more than one antivirus product installed on a machine. If the McAfee service is not started, it is not being used, so why not try uninstalling it altogether?

Other than that, you may want to review what other changes may have been made to the system since the last time the backup worked. Perhaps reverting to an earlier system restore point would be worth trying as this does not roll back data - only operating system changes.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

InAtari's picture

I haven't given up on this. Since my last post, I have tried a bunch of times to get this to work. It actually has backed up successfully once and failed several times since as well as many times before. Going on the naive assumption this means there's something going on network-wise, I took a look at the process with Wireshark on the server. The only thing that shows as strange is that the (UDP heartbeat)/(TCP incremental snapshot) conversation at 20 second intervals continues about 500 seconds after the time the Ghost log viewer lists the process as failing. At the end, the 2 exchange aierror.log and that's that. Since the client event log says that the server process has died long before the time of the failure notice seen on the server log viewer, it must be a different process responsible for network communication.

Thanks

EdT's picture

Have you considered hardware failure?  If all was working for a long time and suddenly isn't, with no known hardware or software changes, then maybe you have developed a fault on the NIC (for example) which is causing the transfer to fail.  Or you could have a damaged network cable, dodgy port on the switch, etc, etc.

Have you explored any of these possibilities?

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

InAtari's picture

I thought about them but ruled them out because the user is not seeing any issues. There is no indication of problems of this sort in the event log either. Just to follow up the best i can, I spoke with the people responsible for the jacks on both ends of this and they are not seeing any problems on their end. The capture I took with Wireshark on the server showed no indication of problems, but maybe that isn't low enough to see them.

Dpak D's picture

Type ghreboot ,if allowed ,to reboot to OS

InAtari's picture

In the Wireshark captures that I have, they all have the same value after CommandReturnCode in the first death packet. 0c 04 09 00 02. Don't know if that'll make any difference to the problem, but I thought I'd at least get it in.