Ghost Solution Suite

Hello, I am at my wits end with this problem I have installed ghost console multiple times on virtual server 2008x64 / 2008x86/ 2008R2 with no error at all. I install on a physical Dell R710 server and all I get is Faulting application ngserver.exe version 11.5.0.2113, timestamp 0x480dabac, faulting module ntdll.dll, version 6.0.6002.18005, timestamp 0x49e03821, exception code 0xc0000005, fault ofset 0x0003e13d, process id 0x600, application start time 0x01ccf75785f32896.

The output of NGERROR.TXT is as follows An exception has occurred of type C000005 C:\Program Files \Symantec\Ghost - C:\Program Files\Symantec\Ghost\ngserver.exe 11.5.0.2113 C:\Windows\System32\ntdll.dll!RtlAddAccessAllowedAce+0x158 C:\Windows\System32\ntdll.dll!RtlAddAcccessAllowedAce+0x68

C:\depot\ghost\gsstrunk\ghost\configureagent\library\src\aio\pipeio.cpp#224:Library::Aio::PipeListener::beginAccept C:\depot\ghost\gsstrunk\ghost\configureagent\librayr\src\win\pipeservice.cpp#574:Library::Win::PipeService::statrtListen C:\depot\ghost\gsstrunk\ghost\configureagent\server\server.cpp#269:ConfigureService::initalize

I believe with the x64 OS install the last few depot messages were not on there. I've opened all UAC, I tried three different OS's. for the life of me I can't figure out why the Virtual machine server 2008 x64 works just fine and my physical Dell R710 doesnt

No-one's ever reported anything similar to my knowledge, and that particular code has been in the field for about 5 years running on just about every Windows edition there is, so if I was still at Symantec I'd attack this by getting you to e-mail me the NGERROR.DMP file that was written alongside the NGERROR.TXT to allow me to start debugging this (that dump contains a partial memory snapshot of the program, along with the precise versions of every DLL in the system at the time - important since the fault is actually occurring buried inside the Win32 API code, not in my program code).

Unfortunately, with me having been laid off long ago, I don't believe there's any way to get this looked at nowadays without going through the official technical support process; and since they'd have to escalate that to a developer  to get it analysed, that process doesn't really work unless you have a support contract and are willing to be really patient (on the order of 6-8 weeks). Quite often when I'd directly resolve things reported on the forums, if it got reported to support at the same time there'd eventually be an escalation assigned to me after around two months which would be a mangled form of the same bug, and these days there's no way to bypass that and deal with the maintenance guys in India direct.

It's probably a good idea to LiveUpdate to GSS 2.5.1 just in case (bwcause if you contact support they'll almost certainly ask you to do that, and if so I'd recommend taking a backup of your console database so you can revert to 2.5.0 more easily) but I don't recall any changes at all in this particular area from 2.5.0 to 2.5.1

Apply 2298 patch update to fix this issue . Contact tech support to obtain the same

KB Article

Ghost 11.5 / 11.51 client crashes upon system start up with a c0000005 error.

http://www.symantec.com/docs/TECH132035

Since I actually created the fix referred to by the support staff above (although it wasn't released until some months after I was laid off), I'd just note that the symptoms reported here are quite different, and that as per the forum sticky that patch isn't available to anyone who doesn't have a support contract, and you're also forced to contact technical support as I already advised.

I'd also note that the linked KB article is bafflingly incorrect as to the true nature of the fault (as you'd except since it was prepared by technical support folks); as I explained here on these forums at some length once a customer had helped give me access to a system affected by this to resolved the underlying cause, the actual root cause has nothing whatsoever to do with IP address acquisition.

Instead, the *actual* root cause of the problem addressed in build 2298 is due to the complete lack of a valid hardware SMBIOS UUID in affected systems (which in any modern computers is always due to a firmware or manufacturing process fault), and generally it can be resolved using a manufacturer tool to reflash the SMBIOS data. When a system has no valid SMBIOS UUID at all, the ngctw32.exe executable uses various fall-back techniques; one of those dates back to Windows 95 and due to other changes in GSS 2.5.1 that fall-back code path has this effect.

However, this code fault is in a different executable to the one affected by the SMBIOS fault, and it is presenting as a fault in a completely different system DLL, there's no evidence that those two faults are related - hence why the correct diagnosis procedure is to use the NGERROR.DMP file which contains the evidence.

There is one small piece of evidence presented here that might indicate a relation to the no-valid-SMBIOS fault, which is the mention that the fault does not occur in a Virtual Server environment; this is hardly definitive, but I would note that virtual environments like VMWare, VirtualBox and Virtual Server all create emulated SMBIOS data that is always well-formed, whereas manufacturers of physical hardware often fail to accomplish this. However, given the number of items that don't match, it's important to retain the evidence which can be used to diagnose the root cause, i.e. the NGERROR.DMP file, so that in the event this is a different fault (as indicated by the very substantial difference in symptoms) it will be possible for it to be properly diagnosed and resolved.