Capture output window messages in VS 2010

Question

To capture the messages written in output window in VS 2010 , trying to intercept a message leading to a bug.

the message that i'm trying to intercept :

A first chance exception of type 'System.Runtime.InteropServices.SEHException' occurred in OpenNETCF.Desktop.Communication.dll
Disconnect

after that when i connect the device the app freezes, with no exception.

How i could capture output window messages or redirect them to a string ? can i intercept when i will use this app in production mode ?

I have tried to capture console Messages but i got nothing apart the console.writeline called from the app , so i think that these messages are not console.writeline calls.

Answer 1

If you are debugging the application then to get the debugger to break when a specific exception is first raised (1st chance exception/thrown) you can tick just the specific exception you want, instead of the whole set of exceptions in Runtime.InteropServices.

See the screen shot below:

If your application isn't currently running in a Debugger, then you can get a debugger to attach to the already running process...by using "Attach to Process"...however, that is not normally done in a production environment.

If you want to analyze your application in a production environment ie you can't stop your application or run it in a debugger...then the best way to do that is when the exception occurs to get a "dump" created of the process...which you can then analyze offline in either WinDBG or Visual Studio by loading the saved .dmp file.

The best way to set things up is so that a "full dump" file is automatically created when the exception occurs by using DebugDiag.

• http://blogs.msdn.com/b/kaushal/archive/2012/05/09/using-debugdiag-to-capture-a-dump-on-first-chance-exception.aspx

It's also possible to manually do a "mini-dump" of your application process by right clicking on the process in Task Manager and doing create Dump File. Doing manually however, means you are a lot slower at capturing the state close to the time of the exception, and also a "mini-dump" is less useful than a full-dump.

There's a good tutorial here on how to diagnose problems in a production environment:

• http://channel9.msdn.com/Series/-NET-Debugging-Stater-Kit-for-the-Production-Environment