NET Runtime 2.0 Error Reporting, Event ID: 5000, EventType clr20r3, P1 msadapter.exe, P2 5.0.0.0, P3 4648d13f, P4 mscorlib, P5 2

Question

We are getting the following error what would be the root cause.

 

Our application is divided into 2 projects.

 

1- C# assembly.

2 - Managed c++ library (assembly)..

 

What could be the reason for this.

Is it null pointer exception or some other related to Interoperability assembly mscorlib.dll

 

This is the event viewer log:

 

Event Type: Error
Event Source: .NET Runtime 2.0 Error Reporting
Event Category: None
Event ID: 5000
Date:  5/15/2007
Time:  5:55:20 AM
User:  N/A
Computer: MSADAPTER
Description:
EventType clr20r3, P1 msadapter.exe, P2 5.0.0.0, P3 4648d13f, P4 mscorlib, P5 2.0.0.0, P6 4333ab80, P7 32fc, P8 10, P9 system.objectdisposedexception, P10 NIL.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Answer 1

The event log entry is not that useful.  You should look at the code that generated the event log entry (if it is yours).  The only meaningful information I can glean from it is that somebody called the Dispose method on an object and it threw an exception.  The debugger should help you debug this easily as it'll trap all exceptions so you can get a call stack.

 

Michael Taylor - 5/16/07

http://p3net.mvps.org

Answer 2

Thanks Taylor,

 

The code is ours and we are running a stress test on our application for a period of 10 hours. After the first  2 hours this crashed. Ours is gateway application which accepts requests and responses. There would be lot of requests and responses getting processed in the gateway.

 

Yes there are some dispose methods being called from code , I will look into that. Do you need more event log, Yesterday also we got some more error.

Moreover the error contains mscorlib.dll -- > does this do anything here...Is this interoperability assembly which is used to call managed c++ from c#, Please confirm.

 

Thank you.

Answer 3

Interop is a general area of concern when disposing of things.  It is possible that you are passing a managed, disposable object to unmanaged code.  While the unmanaged code is using it the GC cleans up the object.  This will cause a crash and it'll probably come from within the CLR itself.  You need to make sure that any reference types that you pass to unmanaged code are pinned first.  This ensures that: a) the object doesn't get moved around in memory and b) doesn't get GC'ed.  When the unmanaged code is done with the object then you should be sure to unpin it.  Be careful about pinning though as it can cause fragmentation in the heap.

 

Michael Taylor - 5/16/07

http://p3net.mvps.org

 

Answer 4

Hi Taylor,

 

Thank you very much. I have just checked and we are not passing any managed disposable objects to unmanaged code.

As you told you can debug the application using debugger, but how to do this.

 

Because we are running a release build and that too on a performance testing scenario...which runs for 10 hours. Please tell me how a debugger can be used in this case to reproduce the scenario and find out the issue.

 

-Ramesh.

Answer 5

We should agree upon terminology first.  A release build of an assembly is an assembly that is built without debugging information (or very little).  All optimizations are enabled and code reorg can happen.  Entire regions of code can be removed if needed.  Debugging does not require a debug build.  You can debug (as in run under the debugger) any application irrelevant of how it was built.  The biggest issue however is that release builds lose a lot of information (in unmanaged code at any rate) so it can be more difficult to map the running code back to the actual source code.

 

You'll need to install the debugger on the target machine.  After that you have a couple options to get you started.  Perhaps the easiest is to start your application normally and attach to it through the debugger (Debug -> Attach to Process).  You are now effectively debugging your app.  Remember that, since this is a release build, the source code won't line up quite right and the call stack may be off but it should give you an idea of what is going on.

 

I think you'll find, though, that the problem probably occurs in debug builds as well.  Therefore you might first want to try duplicating the problem by running a debug build on the server (through the debugger).  When the exception occurs you'll get a more meaningful call stack.  At this point you are not sure whether it is the OS, the box or your code so the goal is to try to narrow the thing down.  Understandably you are trying to do performance testing but for now you should not worry abou the performance (it'll be dismal) and just try to identify the problem.  Once you've fixed the problem you can resume performance testing. 

 

As for the managed disposable objects I should clarify.  You must pin any managed reference object that you pass to unmanaged code as a pointer, not just disposable objects.  The HandleRef class can be used to simplify this work.  It effectively pins a reference object in memory until it is disposed of.  It is commonly used in interop code.  Reference objects that are passed by value do not need to be pinned.

 

Once you've narrowed down the problem to a specific area of your code then post back what you've found and hopefully someone will be able to help you further.

 

Michael Taylor - 5/16/07

http://p3net.mvps.org

Answer 6

Thanks, I will try that and get back to you.

 

-Ramesh.

Answer 7

Hi Ramesh Potu,

  We are marking this issue as "Answered". If you have any new findings or concerns, please feel free to unmark the issue.

Thanks for your understanding!

Answer 8

Hi Ramesh Potu,

  We are marking this issue as "Answered". If you have any new findings or concerns, please feel free to unmark the issue.

Thanks for your understanding!

Hi,

In which scenario this error will come? How can i reproduce this error?

Thanks

Answer 9

Ramesh,

You have to Apply Permissions from “Microsoft .Net Framework Configuration” from the Administrative Tools,  ( Configwizard.msi ) if you don´t have this console installed.

-          Expand the items “My computer”, “Runtime Security Policy”, “Machine”, “Code Groups” and “All Code”.

-          Right click on “Internet_Zone”, “Properties”; Click on “Permission Set” and choose “Full Trust”.

-       Apply, OK. It´s done.

 

 

Luis Dominguez.