Video Screencast Help

Error C000005

Created: 15 Sep 2011 • Updated: 15 Sep 2011 | 5 comments
noe's picture


I restore Ghost Client Agent on a desktop running 64bit Windows 7 sp3 using Symantec Ghost. The restore was successful. However the Ghost Client crashed. I tried to reinstall the Client. The same result occured.

i use  the GSS Console.

 I'm also posting the NGerror dump ERROR

Symantec Ghost Client Agent

An exception has occurred of type C0000005

Thank you


Discussion Filed Under:

Comments 5 CommentsJump to latest comment

Thomas K's picture

Moving this thread to the Ghost Solution forum for you.

EdT's picture

The C0000005 error is a known issue and requires the 2298 patch - you can search on C0000005 in this forum to view past postings.

However, to get the patch, just follow the instructions in the sticky posting at the top of this forum. Have your support agreement details to hand when contacting Symantec support.

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

Nigel Bree's picture

Actually Ed, you're making a big assumption here and have jumped to a conclusion ahead of the evidence - admittedly, Technical Support people tend to jump to the same conclusions, but it's actually not the right way to handle these.

To explain this again: C0000005 is a Windows translation of the x86 processor general-exception situation; it always indicates ***a*** bug, and therefore always needs investigation, but it is a ***generic error code*** - it's the fall-back for all the error cases that aren't specifically detected as other things (exactly like the 36000 error in Ghost, which is the translation of exactly the same underlying "something's wrong" trap from the processor).

This is why the processes in question go to a great length to capture the specific circumstances in which the error occurred, in the NGERROR.TXT file, as well as capturing a memory snapshot of the entire running process in the file NGERROR.DMP (the content of the NGERROR.TXT are also displayed and placed on the clipboard, to encourage those to be reported instead of just a useless "the program crashed").

The NGERROR.TXT file contains a list of the internal functions in the program which were being executed at the time of the fault, which provides the context for the error, and it's only by matching those that it's possible to determine whether a specific instance of the fault is or is likely related to a known cause and thus may or may be fixable by a specific patch.

Thus, the right thing to google is the text of the stack backtrace; it should be that the topmost line is the most recently-called function in the program and therefore is the most specific context, and so if there has been another report of an error *with the same underlying cause* that should find it. Given that the list of called functions is generally just a tiny piece of text, it's easy to post and it should always be supplied with a report like this to match it against a particular cause (for all the known fixes)

This is almost exactly what Windows Error Reporting does internally, by the way - by mashing up the internal numbers in the stack backtrace leading to a failure, it derives a "fingerprint" for the fault which it can then look up via a webservice to see if it's marked as known fixed, completely unknown, or has been marked for extra data collection (in which case it will upload a minidump file for developer inspection).

[ The main reason we don't have similar automation to WER (before WER existed) is that although I considered writing some automation around this, we backed away from any contact inside the Ghost product to Symantec systems due to the kind of technically illiterate hysteria that tended to surround such things in the late 1990's and early 2000's; even as it was, we'd periodically be contacted by customers accusing us of "monitoring their systems" and other drivel because they had no real idea how IP worked, and would assume the IP multicast used by GhostCast on their local networks was us siphoning data from their networks back to us. In that kind of evironment where even the most innocent contact back to Symantec-run systems would be deliberately misreported and misconstrued to damage the company's reputation, we couldn't afford to go there. ]

EdT's picture

>Actually, there is no evidence that this is a known problem


Have a look back through past postings. The release of patch 2298 was accompanied by a mass update of postings discussing the C0000005 error to advise posters that this patch had been released to address the error. for example:

Whereas I have no doubt whatsoever as to the accuracy of your problem analysis, it does appear that this specific issue was quite widespread to the extent that a specific patch was written to fix it. This would suggest that there was plenty of evidence that this was a known problem.

Of course there are users for whom this patch did not work but in the main it did appear to fix the issue, hence my suggestion that the original poster should contact tech support, who I believe do check that the details of the issue match the release notes of the patch in question. As the ultimate point you are making is that each issue needs further investigation, then opening a call with support does allow this process to take place assuming the techs are suitably well informed.

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

Nigel Bree's picture

Again let me reiterate, there is no 'the C0000005 error'. As I said, it is a generic error code, not a specific one, and you are assuming that *this instance* of the reported problem has a similar cause to the prior reports. While it's a reasonable guess that after this length of time in the field it's probably a fixed problem - and why I'd expect that Technical Support probably will just fire off a patch at the first hint of C0000005 rather than go through the proper diagnosis procedure - that's still all it is, a guess, not supported by evidence.

 this specific issue 

It's not a specific issue, because this is not a specific error code. As it happens, for the 2.5.1 series of releases one particular cause is dominant, which has a very specific symptom yielding a C0000005 error - one with a very specific stack trace where the actual code that is faulting is in WINUSER.DLL - but there have been others with different causes and there will almost certainly be other ones with more obscure causes which turn up over time.

While as it happens all the code in GSS is pretty stable now, and fresh errors which haven't been seen before are unlikely, it's still really not appropriate to make assumptions about the causes of errors when it costs so little time and effort to verify things properly.

Whereas I have no doubt whatsoever as to the accuracy of your problem analysis,

Sure, given that I not only designed and wrote the programs which use this error reporting, I maintained them for years and I know the correct procedures to follow for accurate diagnosis...

An accurate interpretation of the signficance of a specific instance of C0000005 can ONLY be determined by examining the stack backtrace; it is not correct to assume that any instance is the same as a previously reported one except by matching the stack backtraces included in the error report. It may well be that this instance is new; it may well be that it is not; given that it takes merely a second or two with an eyeball to tell, it's still best to follow the correct procedure to verify the diagnosis.

The same error code has been used (and been reported in) every GSS version prior to 2.5.1 as well, just as 36000 errors have appeared in pretty much every version of Ghost ever made. However, in each release (or platform, as interations with other software can cause these too) there are *different* root causes which lead to that error code being reported, precisely *because* it's the last-resort catch-all which finds things that weren't anticipated.