Home/ Questions/Q 8381853
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T16:47:23+00:00

Today we had a customer run into a problem with a Windows service that

  • 0

Today we had a customer run into a problem with a Windows service that is part of one our products after they downloaded and installed a newer version of the product.

They are running the service on a Windows Server 2003 R2 (Service Pack 2) machine, which has .NET 2.0 installed on it (and this is the most recent version of the .NET Framework on that server).

After they installed the product update and restarted the service, it crashed almost immediately with the following error information logged to the Windows Event Log:

Event Type: Error
Event Source:   .NET Runtime 2.0 Error Reporting
Event Category: None
Event ID:   5000
Date:       8/13/2012
Time:       11:46:23 AM
User:       N/A
Computer:   
Description:
EventType clr20r3, P1 our-service-name-redacted.exe, P2 2.6.31.0, P3 4fcd090b, P4 mscorlib, P5 2.0.0.0, P6 4889dc80, P7 e38, P8 1e8, P9 pszqoadhx1u5zahbhohghldgiy4qixhx, P10 NIL.

Now, a few other customers are running the same version of the Windows service without any issues (on different versions of Windows), and I tested the service on a virtual machine running Windows Server 2003 R2 (Service Pack 2) and did not encounter this problem, but it happens consistently for this single customer.

So, this isn’t a “what’s wrong with my code?” question: I’m more interested in two things about this error information that I find odd:

  • The faulting module (P4) is mscorlib
  • P9, which is normally supposed to name the exception that occurred as far as I understand things, contains what looks like garbage data (or some kind of obfuscated information perhaps?)

Is there a general explanation for this? I tried Googling but not much luck, since it’s hard to search for “P9 garbage” and similar and get anything useful. In particular, I’m really curious what the “gibberish” value for P9 could indicate. For example, could this be a hint that they have a corrupted installation of .NET, or does this “gibberish” actually mean something?

Also, I am somewhat surprised the faulting module is mscorlib and not one of the our own assemblies, which makes me wonder again if the customer’s .NET installation is corrupted, or a virus or other malware is lurking on their server.

So, as mentioned, are there any commonplace explanations for this rather odd error report and the P9 “gibberish,” or any particular troubleshooting steps I should try beyond trying to get a crash dump and debugging in WinDbg?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The exception information in P9 is hashed if it would be otherwise too long to fit within the field (I’m not sure what the length of the fields are, but apparently they’re limited).

    However, unless you’re unlucky, it’s quite likely that the hash code will have been encountered by plenty of people in the past – so you can do searches based on the hash, and you’ll likely find people who already know what type of exception it actually was. In this case, it appears to be a COM exception.

    Finally, all the the module information tells you is where the exception originated. It is not at all uncommon for code that you call into to throw exceptions, and it would be an unusual .NET program that didn’t have quite a few calls into mscorlib. It’s especially not surprising when we (now) know that it’s a COM exception.

    • 0