Error with .Net Runtime 2.0 on Windows Service

  • Thread starter Thread starter Microsoft News
  • Start date Start date
M

Microsoft News

I need some serious help. I am getting the following errors in my event
log:

Source: .NET Runtime 2.0 Error Event ID: 5000
EventType clr20r3, P1 orionnetreg.exe, P2 1.3.2548.24224, P3 458d8320, P4
system, P5 2.0.0.0, P6 4333ae87, P7 374c, P8 124, P9
system.objectdisposedexception, P10 NIL.

Source: .NET Runtime 2.0 Error Event ID: 5000
EventType clr20r3, P1 orionnetreg.exe, P2 1.3.2548.27502, P3 458d9cbd, P4
system.data, P5 2.0.0.0, P6 4333aea2, P7 1946, P8 25, P9
system.invalidoperationexception, P10 NIL.


The first one I might have fixed because it has gone away but the other
error keeps happening. I took a window service created in VB .Net 2003 that
had worked like a charm. What the service did was expose a Remoting DLL
that a windows application called and it had a timer that would trigger
every so often and then the service would make some calls to some web
services created with WSE 2.0. I updated the code to .Net 2005, then
updated the web services calls to WSE 3.0 and had no errors or anything. I
reinstalled the service and started it up with no problem. Then after the
windows application connected to the Remoting calls the service would DIE
with the error at the top. After a lot of work and testing I realize that
the problem was some COM DLLs that had not registered correctly so after
Unregistring them and re-registering them that error went away.

Then I deployed my service out to my customers computer after 10 days of
letting it run and testing on my server. My server is Windows 2003 Small
Business Standard server with all of its UPDATE.

I installed it on 9 customers servers. All different servers, some Windows
2000, some XP Pro, and some Windows 2003 Small business standard. 7
repeatly have the second error listed above, the only two that do not have
the issue, one is a Windows 2003 server and the other is a 2000 server. I
have tried putting logging into the code, it logs fine but then dies for no
reason. I can not find when it dies, and the message above is CRAP!!!! (For
give my frustration)

We have tried everything, my server and two other work with no problem. But
I don't know why these messages are only showing up on some servers and I
can not get any reliable message to tell me what is going on. I see that it
has something with System.Data, and that it is some System.Invalid Operation
Exception but I can not get any more dumpped out.

Anyone out there who can help me with this. We are dead in the water if we
can not fix this. It seems to be something with .Net 2.0 but
WHAT????????????

ALL HELP appriecated.

Clyde
 
Mike

Thanks for the help, we will try that tool and see what we find out. I
think we have a clue about what is going on but not sure how to prove it.
When the window service is running and no one is making calls to the
Remoting DLL then there is no errors. But when users start using the
Remoting DLL calls then we get the error. The error seems to be random when
it occurs. I wonder if the issue is that the Window Service was created in
..Net 2005 and the Remoting DLL was created in .Net 2003?

If Microsoft reads these post, I wonder if they can tell me if .Net 2005
does not like working with .Net 2003

Clyde
 
I don't think Microsoft responds to anything in these newsgroups unless
you are an MSDN subscriber, or they do it on their own time.

Just FYI.

Robin S.
---------------------------------------------
 
I would susggest to put top level "try catch" block and log extended
information on the exception like stack info and line number of the code
where it happens.
I would look at that code and make sure that all error situations handled
properly etc.

If that wouldn't help I would try to mitigate the problem at the top level
catch block.

Regards,
Valentin Ivanov.
 
I came across this the other day that might help...

“Just to complicate things, in v1.0 and 1.1, an unhandled exception did not always mean that your application would die. If the unhandled exception occurred on anything other than the main thread or a thread that began its life in unmanaged code, the CLR ate the exception and allowed your app to keep going. This was generally evil, because what would often happen was, for example, that ThreadPool threads would silently die off, one by one, until your application wasn't actually doing any work. Figuring out the cause of this kind of failure was nearly impossible. This may be why Jeff thought it worked before...he just always saw crashes on non-main threads.

In v2.0, an unhandled exception on any thread will take down the application. We've found that it's tremendously easier to debug crashes than it is to debug hangs or the silent-stoppage-of-work problem described above.”

See http://msdn2.microsoft.com/en-us/library/ms228965(VS.80).aspx for more information and try adding the legacyUnhandledExceptionPolicy flag in the .config file to see if that helps.

EggHeadCafe.com - .NET Developer Portal of Choice
http://www.eggheadcafe.com
 
Back
Top