.NET Runtime 2.0 Error

[hermbagger]

I have written a server in C# using the .net 2.0 socket class. The
server will run fine accepting incoming connections and handling
connected sockets (up to 10 at a time) just fine. It may run for 2
weeks without a hitch, then all of the sudden, without any
notification, the server will just disappear and not be in the Task
Manager and all connected clients get disconnected. In essence, it
crashes without any warning, or notification. The only remnants of
the server are in the Event log (windows server 2003) which reads
this:

EventType clr20r3, P1 application.exe, P2 1.0.2978.18228, P3 47c3c8c9,
P4 system, P5 2.0.0.0, P6 4333ae87, P7 2bba, P8 42, P9
system.argumentnullexception, P10 NIL.

Has anyone run into this problem? What can be done to try to pinpoint
where this argumentnullexception is not handled in my code? This
message is not very clear at all and doesn't provide any of the
necessary information to debug the problem.

Thanks.

 

[Jon Skeet [C# MVP]]

I have written a server in C# using the .net 2.0 socket class. The
server will run fine accepting incoming connections and handling
connected sockets (up to 10 at a time) just fine. It may run for 2
weeks without a hitch, then all of the sudden, without any
notification, the server will just disappear and not be in the Task
Manager and all connected clients get disconnected. In essence, it
crashes without any warning, or notification. The only remnants of
the server are in the Event log (windows server 2003) which reads
this:

EventType clr20r3, P1 application.exe, P2 1.0.2978.18228, P3 47c3c8c9,
P4 system, P5 2.0.0.0, P6 4333ae87, P7 2bba, P8 42, P9
system.argumentnullexception, P10 NIL.

Has anyone run into this problem? What can be done to try to pinpoint
where this argumentnullexception is not handled in my code? This
message is not very clear at all and doesn't provide any of the
necessary information to debug the problem.

Make sure each of your threads has a top-level try/catch which logs
exception details.
That way you should be able to see what's happened.

It's possible that you could also subscribe to
AppDomain.UnhandledException to log the exception - I'd hope that
would work in services, but I wouldn't like to say for sure.

Jon

 

[DSK Chakravarthy]

Dude,

Before i help you to resolve the issue. Help me to understand your code.
1) Did you plan to recycle the connected objects to the server
2) Apart of the eventlog, do you have any internal message communication
mechanism implemented between the clients as well as clients to Server
3) Do you have any communication mechanism implemented between the methods
of either server class as well as client class

Once i understood the problem, may be we can arraive at a solution.

Chakravarthy

 

[hermbagger]

1. I do recycle the connected object to the server, reusing "empty"
objects for new incoming connections
2. I have an internal message communication between the server and
clients only. Clients have no communications between each other. I
also have a logging system which keeps log of all clients/server
communication
3. I dont understand what you mean by this.

 

[DSK Chakravarthy]

There are many reasons that made me seek your information.

Point 1) if you have the code or any process of recycling the objects, you
would really know when the objects are killed and removed from the stack.
Point 2) Usually, the null reference comes to place when the objects are
alive and the relation between the caller and consumer objects are loosed
coupled rather tight coupling. So, try to debug how the caller and consumer
are tightly coupled
Point 3) if you have the communicationmethod between the methods / classes
well defined, you are having a perfect plan to understand why the server
component is terminating.
Point 4) Pl read the log file that is available on the day of the
termination of the app. Use your own event logging to write the exception /
or reason that caused to terminate the app.

Rewrite your server component for a trail run to test with the custom event
logging and then do a trace log for the IIS server.

HTH
Chakravarthy