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. ]