GSS 2.5.1 Client Update Error

[Migration User]

Hi all, I installed latest patch on GSS - actually 2.5.1 (OS:Windows Server 2003 Standard) and then installed the new Symantec Ghost Client Package to client machine (Windows XP SP3 witch latest MS patches). After installation client pc show this error message. Any idea what to do with this problem?

Thanks

Symantec Ghost Client Agent
An exception has occurred of type C0000005
C:\Program Files\Symantec\Ghost - C:\Program Files\Symantec\Ghost\ngctw32.exe 11.5.1.2266
C:\WINDOWS\system32\USER32.dll!MsgWaitForMultipleObjectsEx+0x30
C:\WINDOWS\system32\USER32.dll!GetLastInputInfo+0x86
C:\WINDOWS\system32\USER32.dll!MsgWaitForMultipleObjects+0x1F
r:\depot_cont\ghost\gsstrunk\ghost\configureagent\agentlib\sockevent.cpp#433:SocketEvent::wait
    unsigned int msTimeout = 0xFFFDD8
    unsigned int callerHorizon = 0x498B2
r:\depot_cont\ghost\gsstrunk\ghost\configureagent\client\clientmain.cpp#4376:l_mainLoop
    unsigned int c_sock = 324
    unsigned int code = 0x1B30000
    unsigned int count = 0x42FFD8
r:\depot_cont\ghost\gsstrunk\ghost\configureagent\client\clientmain.cpp#4811:main
    int argc = 1
r:\depot_cont\ghost\gsstrunk\ghost\configureagent\client\clientmain.cpp#5289:g_runMain
    int argc = 1
    bool standalone = false
    unsigned int length = 212
    int wait = 0x77DE1701
    bool doReboot = false
r:\depot_cont\ghost\gsstrunk\ghost\configureagent\client\clientstate.cpp#117:ClientService::process
r:\depot_cont\ghost\gsstrunk\ghost\configureagent\library\src\win\firewall.cpp#405:Library::Win::l_serviceMain
    unsigned int argc = 2
    unsigned int data = 0
    unsigned int dataSize = 4
    unsigned int type = 0xFFFF94
  ....

Attachment(s)

NGERROR.zip   10.37 MB 1 version

[Edward Tippelt]

See this thread:
https://www-secure.symantec.com/connect/forums/gss25-not-updating-live-update

[Migration User]

However, that shouldn't in principle matter, because the relevant client code is very old and very stable and isn't particularly different in this build; the error is internal to Windows, and in something of an odd place - since the original poster thoughtfully included the NGERROR.DMP file in the attachment which I can use to inspect the state of the process at the time of failure, I've been trying to work through what this piece of Windows is doing.

In essence, the client application is calling a Win32 API to work out what to do next (and to idle if there's nothing to do), and this API consults all kinds of things in the process. One of those things is looking at a piece of memory that USER32.DLL uses to share with its companion kernel driver WIN32K.SYS, something that is done to avoid unnecessary user/kernel mode transitions in the handling of window messages; at the point of failure Windows sees that there does appear to be some information there, but the fault has occurred when it attempts to access this memory address, although the memory address in question *is* part of an address space range that is present in the dumpfile, so it's not completely invalid.

Not ever having seen anything quite like this before, I'm a little stumped when it comes to positing even an immediate cause, let alone a root cause. After all, this user/kernel communication path is a pretty old piece of Windows so it should be pretty stable and it's not clear at all what on earth any of my code could be doing to trigger such a problem anyway since this is a private Windows communication path that I know I don't mess with.

This leaves me casting about in the dark for possible causes; the other other odd thing about the attached process I can see is that there are a group of third-party DLLs being referenced, which appear to be NetWare components which have been loaded into the client process (presumably indirectly via some standard Windows facility such as Windows Sockets or LDAP). I'm not drawing any particular inference as to whether this is important, merely noting it because it's very unusual to see Netware components loaded and given the nature of the immediate problem it's the only thing that seems to stand out about the source system.

So, I don't really have any particular advice to offer for diagnosing this; problems like this do not tend to reveal their true nature until either we can build up a more complete library of samples to determine what the root cause is or some process for systematically reproducing it reveals itself.

[Migration User]

Fresh install of GSS  2.5.1 (OS:Windows XP SP3) and pushed out Client Package to client machine (Windows XP SP3 fully patched). When I ran WinPE on it for a backup, I received the following:

An exception has occurred of type C0000005
X:\GHOST - X:\GHOST\ngctw32.exe 11.5.1.2266
0x77B9C4EC in \Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}\Windows\System32\user32.dll
0x77B9C43B in \Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}\Windows\System32\user32.dll
0x77B98B7B in \Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}\Windows\System32\user32.dll
0x41B9C3 in \Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}\GHOST\ngctw32.exe
0x4092AF in \Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}\GHOST\ngctw32.exe
0x409950 in \Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}\GHOST\ngctw32.exe
0x40A0E9 in \Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}\GHOST\ngctw32.exe
0x40AEA8 in \Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}\GHOST\ngctw32.exe
0x44ECA4 in \Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}\GHOST\ngctw32.exe
0x76773833 in \Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}\Windows\System32\kernel32.dll
0x77C5A9BD in \Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}\Windows\System32\ntdll.dll


The dmp file is available.

[Migration User]

I tried to install fresh copy of 2.5.1 and also tried to patch 2.5 to 2.5.1 version. Both procedures have same "error state" client result described above.

[Migration User]

The same client error (ramdisk) with  GSS 2.5.1 installed on W2K3 Server SP2.

[Migration User]

...and this renders GSS 2.5.1 build 2266 useless in our environment!
Too bad it's the only one we've got.

[Migration User]

Fresh install of Vista Ultimate sp2

An Exception has occured of type C0000005
x:\ghost -V X:\ghost\ngctw32.exe 11.5.1.2266
0x773AC4EC in
\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2fa2f6b750}\Windows\System32\user32.dll
0x773AC43B in
\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2fa2f6b750}\Windows\System32\user32.dll
0x993A8B7B in
\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2fa2f6b750}\Windows\System32\user32.dll
0x41B9C3 in
\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2fa2f6b750}\ghost\ngctw32.exe
0x4092AF in
\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2fa2f6b750}\ghost\ngctw32.exe
0x409950 in
\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2fa2f6b750}\ghost\ngctw32.exe
0x40A0E9 in
\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2fa2f6b750}\ghost\ngctw32.exe
0x40AEA8 in
\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2fa2f6b750}\ghost\ngctw32.exe
0x44ECA4 in
\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2fa2f6b750}\ghost\ngctw32.exe
0x76CF3833 in
\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2fa2f6b750}\Windows\System32\kernel32.dll
0x7753A9BD in
\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2fa2f6b750}\Windows\System32\ntdll.dll

[Migration User]

I had ti re-name to txt, but here are the files generated on my PC.  Seems fairly consistnat.   I only got imaging to work once.  Every other time it's the same failure.

Attachment(s)

NGERROR.DMP_.txt   37.31 MB 1 version

ngctw32.log_.txt   4 KB 1 version

NGERROR.TXT   1 KB 1 version

[Migration User]

cvtfm: check out https://www-secure.symantec.com/connect/pt-br/forums/exception-has-occurred-type-c0000005 for a details on a workaround on your machines.  Or, simply set your windows DHCP service as dependent on the NGCLIENT service.  You should be back in working order until we can all get  a patch or some kind.

As I've stated in other threads, this error cannot be reproduced without fail.  I have taken one good, clean image and applied it to multiple pc's.  In this case, some fail (throwing the c0000005 error with similar results to everyone else here) and others work without issue.  The only difference is that some have -very- slightly different hardware (ie: same Acer model, but with different model description in sys info.. same components but likely a slightly different iteration motherboard).

Everything else in windows works fine, so as I have stated before this has to be an issue with the ghost client only accepting null values for information returned in relation to the dhcp service.  Otherwise the above stated method should not work.  This has to be something to do with changes made by the 2.5.0 - 2.5.1 patch.. I don't know why the error would generate only when the dhcp service has been started, but it seems to be the only common factor.

So, we cannot provide Symantec with a VM compatible image for their testing purposes.. not only is it likely that the VM won't have any issues, but any company that did so would also be in breech of their os and software licensing terms..

[Migration User]

If the network configuration is the key factor, then something that may aid diagnosis is a network trace of the startup on an affected machine; this can be accomplished using port reflection on the nearest upstream switch to allow the traffic sent to the machine during startup to be captured on a second machine running Windows (using a packet capture tool like Wireshark; alternatively some switches can capture traffic for inspection themselves). This should allow analysis of the traffic generated both by Windows itself (e.g., DHCP requests and offers) and the traffic generated by the Ghost client interacting with the GSS server; that might provide some helpful context we can use to reproduce the problem here.

Note also that with respect to licensing, Symantec has appropriate development licensing arrangements with Microsoft to allow our developer and QA staff's unlimited use of *all* Microsoft products for software development and testing purposes; supplying us with a pre-configured VM image to use for diagnostic purposes would *not* violate Microsoft's licensing arrangements (third-party software would be different, but in the case of compatibility issues with specific third-party applications then suitable arrangements can be made by us).

[Migration User]

this update has been shambles. starting with a failed liveupdate that uninstalled the server Console and then crashed, up to this C0000005 error in the WinPE environments. This is beyond a joke, I cant believe this has been tested how you're claiming. Currently I'm attempting to roll back the update and go back to 2.5.0 since at least that worked.

Anyway, I have managed to get rid of this error at least for a couple of operations by re-imaging the winPE boot console with one built after upgrading to 11.5.1.2266. However after a couple of operations it seems to start displaying the C0000005 error, it could be related to the operation I am performing - imaging the group with the new boot console - but once it came back it wasnt worth dealing with.

Other issues related to this version and the C0000005 error;
*workstations that have this error will sometimes just load the winPE environment and leave a cmd prompt open waiting. You see the ngctw32.exe run 2 or 3 times and it just stops doing anything. After that at least one of those consoles wouldnt reboot back to the target OS, or reconnect with ngctw32.exe
*on PCs running the virtual winPE and containing a real PCDOS boot console they would join operations fine if they were set to PCDOS but would otherwise display a C0000005 if you selected any version of the PE PreOS. Something that wasnt a problem with 2.5
*workstations showing the C0000005 error all were working fine with 2.5.0 and were first tested without making any changes to the PreOS or other settings. All tested showed up as out of date in the server console, and were updated before operations continued. All systems that went through that process had issues. Systems I manually updated the WinPE boot console using our PXE boot ghost 'disk' initially connected fine, but developed issues as I tried to image the group.

and to top it off I dont seem to be able to roll back ghost. Have a backup of my data from before I liveupdated but for some reason when you install 2.5.0 now it crashes when the console loads. This hasnt happened before when I have restored the server console, this is absolutely dumbfounding. Looks like ghost has been turned into every other norton product. -_-

[Migration User]

Have you reimported the registry keys from your previous installation? I assume you are trying to use the old database?  If you are trying to use your old database you need to make sure you still have your database password registry entry.. I exported my entire symantec ghost registry tree before uninstallation so as to make sure I didn't lose anything important.  After reinstallation all I had to do was put the old database files back in the right spot and reimport the old database password registry entry.  If you dont have the old registry entry you may be stuck and might have to rebuild your database..

I simply rolled back our console and client installs.. 2.5.1 was way too buggy and unreliable to use in a production environment.  Also, I posted the packet captures of all communication between the client/host and posted them on another forum thread and never heard anything back.

Good luck with your rollback melts!

[Migration User]

From reading around the forums, the best option seems to be using the old 2.5.0 software instead of 2.5.1.  Sad thing is, for my client machine, I can't seem to get the hard drive's AHCI driver installed to the PreOS for 2.5.0.  Even after installing the correct driver, it still tells me that I don't have it loaded correctly.  Once I upgrade to 2.5.1 and reload the driver, it seems to work fine.  What is the best way to backup my preOS (the one that works) and roll back to 2.5.0.

The HDD driver I use is the following:

Intel(R) ICH9M-E/M SATA AHCI Controller

I've downloaded the from here.  I've also tried various other drivers and all don't seem to work for me in the 2.5.0 server software.

In addition, is there any updates from symantec on this issue?  I've tried calling technical support, but lets just say it didn't help.

-Paul

[XavierC_SA]

I am having this exact same issue described above.  We had little to no issues with GSS 2.5.0, but when I upgraded to 2.5.1, I am getting the client error which is now affecting approx. 12 computers.  We upgraded to 2.5.1 because of Windows 7, so unfortunately rolling back to 2.5.0 is not an option for us.

In my current job, I have to re-image approx. 200 computers every 3mths, which is due to increase, as we have approx. another 3-400 computers being added to our network over the next year.

I had been in contact with Symantec tech support through our maintenance agreement, and all suggestions from the support person failed.

I provided a link to this forum to the support person, and they told me that that it is being looked at by the Symantec Techs.

I have also applied the suggested work around by Korinus from another forum to selected computers that rarely get re-imaged, but as he mentioned that this will not allow re-imaging to occur on those computers, so I cannot apply it to all.

Could someone tell me if there is any hope in fixing this issue soon?  Or at least provide us with an update on this issue??

Thanks
 

[Migration User]

We are doing a win7 rollout too (and are using the 2.5.1 console I rolled back to 2.5.0) and haven't had any issues using ghost for the most part (aside from some corrupted images taked from older/failing machines).

If you want I've got a few reg hacks you can put into your 7 images that will allow for (as far as I can find) use on any hardware.  Without one of the reg hacks (and it is slightly different if you have a motherboard with a hdd controller that isn't made by intel) you will run into issues more often than not if you try to image a pc set to ide native if the image was made on a pc under sata native you will get the infinate reboot cycle because windows doesn't start the service that handles communication with ide (or ide eumlated) drives...

It is still possible to reimage the machines with the hack I posted a while back, though not using the ghost console.  You would have to rely on a PXE server with a boot image that will connect to a ghost cast session.  Easy enough to create using the ghost console, but again if you are lost I may have one you can try. 

Also, if you are moving to win7 another thing that is really worth looking into is VHD's.  We are currently in the process of attempting to create an elegant re-image process that involves ( mostly ) just the replacement of a secondary VHD on the computers and running a shutdown script that will swap bcd to boot to that secondary VHD.  A reimaging process that is transparent to the end users and allows you to re-image a lab while it is still in session.  Again, we'd love it if ghost could do something like this simply because it would save us a lot of work...

If you want to keep 2.5.1 with the temp solution I posted: get a pxe server up and start using that for reimaging purposes.  At that point you can use the console for computer management and rely on pxe with ghost cast sessions for imaging....

Good luck whatever method you go for!

[XavierC_SA]

Hi Korinus

Thanks for the offer.  I might try and fiddle with a pxe server.

My GSS Server is on a VM with multiple NICs.  I know this is a bit off topic for this issue, but I have had troubles with re-imaging saying that the client either timed out, or the server ended the session.  I have been looking around at other forums regarding this issue, and I read on one of them that the issue could be caused by having a teamed network at the server end.

Would you know if this could be true?  As you seem fairly knowledgable and I would like to try and get the most out of GSS.

Thanks in advance