Application exceptions on close
-
In some of our larger applications (VB.NET), we keep getting an application exception as the program is shutting down. This seems to be untraceable, but maybe I'm missing something. Here's what the message says:
[ProgramName.exe - Common Language Runtime Debugging Services] Application has generated an exception that could not be handled. Process id=0xa6c (2668), Thread id=0x9f8 (2552) Click OK to terminate the application. Click CANCEL to debug the application.Here are the facts we know: 1. Never happens in development mode (when debugging in the IDE). 2. The process ID and thread ID's I mentioned above vary. 3. Is somewhat random, but occurs more often than not. 4. Always occurs during the shutdown of the application. 5. When I place tracing statements in the code to write out messages to a text file so I can determine which line of code is blowing, it's always on or after the END statement. 6. There appears to be NO negative result on the data or the operating system after we acknowledge the error. 7. The error is definitely NOT coming from any error handler I've got in place; I'm assuming it's generated by the .NET framework. 8. It usually seems to happen on machines that don't have any debugging tools, so clicking on CANCEL doesn't really do anything. I got it once on a machine that had the .NET IDE loaded on it; clicking cancel just told me there was no code at that point that could be debugged. The other day, the application that does this the most did something slightly different when it ended, but the effect was the same. This occurred once and has never duplicated, so it might be a red herring. This time the message box said:[WindowsFormsParkingWindow: ProgramName.exe - Application Error] The instruction at "0x77fcc813" referenced memory at "0x00000010". The memory could not be "read". Click on OK to terminate the program.Does anyone have any ideas or clues on how to start finding and eliminating this? While it doesn't seem to hurt anything, it sure does make it look like my app is broken to the customer. Thanks for any help. Mike Mestemaker -
In some of our larger applications (VB.NET), we keep getting an application exception as the program is shutting down. This seems to be untraceable, but maybe I'm missing something. Here's what the message says:
[ProgramName.exe - Common Language Runtime Debugging Services] Application has generated an exception that could not be handled. Process id=0xa6c (2668), Thread id=0x9f8 (2552) Click OK to terminate the application. Click CANCEL to debug the application.Here are the facts we know: 1. Never happens in development mode (when debugging in the IDE). 2. The process ID and thread ID's I mentioned above vary. 3. Is somewhat random, but occurs more often than not. 4. Always occurs during the shutdown of the application. 5. When I place tracing statements in the code to write out messages to a text file so I can determine which line of code is blowing, it's always on or after the END statement. 6. There appears to be NO negative result on the data or the operating system after we acknowledge the error. 7. The error is definitely NOT coming from any error handler I've got in place; I'm assuming it's generated by the .NET framework. 8. It usually seems to happen on machines that don't have any debugging tools, so clicking on CANCEL doesn't really do anything. I got it once on a machine that had the .NET IDE loaded on it; clicking cancel just told me there was no code at that point that could be debugged. The other day, the application that does this the most did something slightly different when it ended, but the effect was the same. This occurred once and has never duplicated, so it might be a red herring. This time the message box said:[WindowsFormsParkingWindow: ProgramName.exe - Application Error] The instruction at "0x77fcc813" referenced memory at "0x00000010". The memory could not be "read". Click on OK to terminate the program.Does anyone have any ideas or clues on how to start finding and eliminating this? While it doesn't seem to hurt anything, it sure does make it look like my app is broken to the customer. Thanks for any help. Mike MestemakerI'm going to make a book recommendation: John Robbins' Debugging Applications for Microsoft .NET and Microsoft Windows[^]. He covers a great deal of information about how to debug the trickiest problems. (Note for VB6 users: I recommend the previous edition of this book, if you can find it - this edition doesn't cover VB6). At a guess, you possibly need to turn on Native Debugging, or use WinDbg with the Son-of-Strike (SOS) debugger extension, for debugging .NET programs. Perhaps you have a finalizer that's causing an exception? You could also try using the CLR SPY Debug Probes tool[^] to see if there's anything odd going on, if you're doing any interop. -- Mike Dimmick
-
I'm going to make a book recommendation: John Robbins' Debugging Applications for Microsoft .NET and Microsoft Windows[^]. He covers a great deal of information about how to debug the trickiest problems. (Note for VB6 users: I recommend the previous edition of this book, if you can find it - this edition doesn't cover VB6). At a guess, you possibly need to turn on Native Debugging, or use WinDbg with the Son-of-Strike (SOS) debugger extension, for debugging .NET programs. Perhaps you have a finalizer that's causing an exception? You could also try using the CLR SPY Debug Probes tool[^] to see if there's anything odd going on, if you're doing any interop. -- Mike Dimmick
Any subclassing going on? You must always release any subclassed windows before ending your application... '--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd