2

I am stuck in a debugging scenario and I need help understanding how I might get more information about what is happening to my application.

The exception is thrown when I close the main form, seemingly during the last bit of processing prior to complete shut-down.

I get one of the two following exceptions, with no obvious reason why one or the other. I can simply open the app and immediately close it. One of the two will be generated. If there's a catch, it's probably that #2 appears to be more likely if I focus another running application, return to mine, and then close it.

Exception #1:

Cannot access a disposed object.
Object name: 'System.Net.Sockets.NetworkStream'.
at System.Net.Sockets.NetworkStream.Write(Byte[] buffer, Int32 offset, Int32 size)

Exception #2:

Safe handle has been closed
System.Net.UnsafeNclNativeMethods.OSSOCK.WSAEventSelect(SafeCloseSocket socketHandle, IntPtr Event, AsyncEventBits NetworkEvents)

There are two direct uses of Sockets in my application.

1) A UDPClient listener is established on a BackgroundWorker. Just a little thing we use internally to monitor database hits.

2) An HttpWebRequest that calls out to our website and gets some information.

Both of these have been in play for a while without issue, and without being changed, so I suspect they aren't guilty.

Because this is a client-server database application, there is a lot of network traffic going on, and it's possible that the database engine is where this is happening. I just don't know, and that where I need help.

Packet/traffic sniffer? Settings/setup in Visual Studio to get better information about the exception? How would you go about tracking this down?

DonBoitnott
  • 10,787
  • 6
  • 49
  • 68
  • Is the Stream of the HttpWebRequest disposed earlier than the WebRequest? Looks like to me, that you may used streamwriter and disposed it (which disposed underlying stream aswell) – CSharpie Oct 30 '13 at 21:02
  • Agree with @csharpie. I'd guess there's an event handler that uses the owner of the disposed object, ie. after the app starts closing. Check the exception call stack, or add trace output to see what happens when the app closes. – groverboy Oct 30 '13 at 23:29
  • The other possibility is that your background worker is still running at application exist, and its `Socket` is closed while you have outstanding asynchronous receives pending. – Jesse Chisholm Mar 25 '15 at 17:22

1 Answers1

3

I am presuming that you are using VisualStudio as your debugging environment.

  • Click menu item "Debug"
  • Click menu item "Exception ..."
  • Open tree item "Common Language Runtime Exception"
  • Open tree item "System"
  • Scroll down to "System.ObjectDisposedException"
  • Check its CheckBox for "Thrown"
  • Click "OK"

Now, when you debug, it will break when that exception is thrown, even if you aren't specifically catching it anywhere.

Add a try...catch around the appropriate chunk of code and deal with this too-common exception that usually isn't a real-exception but a normal code-flow event.

Example:

void OnReceiveFrom(IAsyncObject ar)
{
    try
    {
        // whatever you do
    }
    catch (ObjectDisposedException obex)
    {
        // log to debugging output window, just so you will know.
        Debug.WriteLine(String.Format("{0}: {1}: in OnRecieveFrom",
            obex.GetType().Name, obex.Message));
        // test some variable you set when your application is exiting.
        if (applicationIsShuttingDown)
            return;
        // but if it is unexpected, then re-throw it.
        throw;
    }
}
Jesse Chisholm
  • 3,857
  • 1
  • 35
  • 29
  • You could do similarly for other exception types. Figure out where they are being thrown, fix the issue if you can. Log and Deal if it can't be fixed. Re-throw what you can't recover from. – Jesse Chisholm Mar 25 '15 at 17:36
  • it breaks when this exception is thrown, but doesn't tell where the exception occurred – mrid Aug 21 '18 at 12:19