-1

Users reported that they exit from their application without any error, I have lot of these error in Event Viewer:

EventType clr20r3, P1 main.exe, P2 1.0.0.0, P3 4f6b05ad, P4 system.drawing, P5 2.0.0.0, P6 4333aeaf, P7 17e, P8 20, P9 system.argumentexception, P10 NIL.

EventType clr20r3, P1 main.exe, P2 1.0.0.0, P3 4f6b05ad, P4 microsoft.visualbasic, P5 8.0.0.0, P6 4333d6d8, P7 5e, P8 1e1, P9 34ssps20bdj3nj0wmit5kamzhvglfzcc, P10 NIL.

EventType clr20r3, P1 main.exe, P2 1.0.0.0, P3 4f6b05ad, P4 microsoft.visualbasic, P5 8.0.0.0, P6 4333d6d8, P7 85, P8 a2, P9 system.componentmodel.win32, P10 NIL.

We have Terminal Server on Windows Server 2003, and I have about 500 errors in a day like above.

Any suggestion?

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
Mehran Meidani
  • 341
  • 1
  • 13

1 Answers1

2

It looks like you are getting some unhandled exceptions. If a .NET application encounters an exception which is not caught by a Try/Catch block and there is no debugger to display it, the application will terminate.

Add some exception handling and logging to your application so that you can see all the details of the exception. I recommend using the exception object's ToString method when you display or log it because that will show the exception type, message, and stack trace for the exception and all of its inner exceptions as well. Once you have that information, it should be easier to determine what's going wrong and how to fix it.

To add the exception handling, if you are using VB's application framework, then go to the "Application" tab of your project properties page and click the "View Application Events" button. In the MyApplication class, add an event handler for the UnhandledException event, such as:

Private Sub MyApplication_UnhandledException(ByVal sender As Object, ByVal e As UnhandledExceptionEventArgs) Handles Me.UnhandledException
    MyLog.WriteEntry(e.Exception.ToString())
End Sub

If, however, you do not use the application framework, go to your application's entry point metion (Sub Main) and put a Try/Catch block around all the code in that method, such as:

Public Sub Main
    Try
        ' ...
    Catch ex As Exception
        MyLog.WriteEntry(ex.ToString())
    End Try
End Sub

These examples assume you have a MyLog class with a shared WriteEntry method. Obviously you would need to implement your own logging in such a class.

Steven Doggart
  • 43,358
  • 8
  • 68
  • 105
  • If it's a user-mode application, there should be a default, top-level exception handler that shows an error. If not, check to make sure that you're not overriding the default and hooking up a new top-level exception handler that is swallowing the error. But yes, it never hurts to implement logging...just don't do it by wrapping the main method in a try/catch block, use the unhanded exception hook instead, that's what it's there for. – Cody Gray - on strike Jul 31 '12 at 17:55
  • @CodyGray By "unhandled exception hook", are you referring to the `MyApplication.UnhandledException` event? – Steven Doggart Jul 31 '12 at 17:58
  • Yes, that's the one. That's the best way to log errors for debugging purposes. Wrapping everything in an empty catch block just hides the error, and hoping to recover from any and all unknown exceptions is irresponsibly optimistic. I discussed that once before [here](http://stackoverflow.com/a/4827646/366904). – Cody Gray - on strike Aug 01 '12 at 21:06
  • @CodyGray I certainly didn't mean to give the impression that it should just eat the error and continue on. I meant catch and log any unhandled exceptions before allowing the application to close. The reason I mentioned the try/catch in the Sub Main was because that MyApplication class and it's events don't even exist if you don't use the application framework. – Steven Doggart Aug 02 '12 at 01:12