Monday, February 27, 2012

DotNet Watcher - To find out eaten exceptions at runtime

One of my current .Net project, which started from the VB 6.0 days has lot many areas where exceptions are eaten using empty catch blocks. As the project is in Agile methodology where people gives more important to delivery than quality, we cannot blame developers for writing these type of code. On a build day, if the app shows an exception dialog, the best way they are finding is the empty try catch block and handle the consequences as bug.

When we went to MSFT for reviewing the app, this caused so many troubles and they introduced us their internal tool which captures the eaten exceptions. That was really helpful for debugging the application in production environment. There are so many tools available public to track the same but this tool is so simple and easy to use.I was really excited and wanted to blog about the same.But not sure whether there were any permission or other license related issues as the tool is Microsoft internal.

Days were happy when we were on .Net 3.5.But when we migrated our project to .Net 4.0, the MSFT tool stopped its support. It was targeted to the .Net 2.0 base run time and we were forced to recompile against .Net 4.0. The process of reflecting of the tool and google started in parallel and the reflecting wins and we got the tool in 4.0. But the interesting thing I got during the google is a link to Mike Stall's .Net blog which explains the basics of that tool.Yes.I can blog about the tool as the details are already available to public.

How the tool works


The tools works based on MDbgCore.dll1 engine provided by Microsoft. It can either start an application in the attached mode or attach itself to a running process. Then it hooks to the debug points and other operations that are happening on the target application. Once a hooked operation happens it passes the control to our debugger host application where we can print or log the details.


Coding a Debugging host 


From the programming aspect the things are more clear. You need to refer the MDbgCore.dll to your application. Then create an instance of MDbgEngine to start or attach to a process which will give you MDbgProcess instance. The processInstance.Go.WaitOne() will wait for the notification from the target application. Once a notification comes, it will be an instance of BuiltInStopReason derived class.Handle that accordingly.
            MDbgEngine debugEngine = new MDbgEngine();

            if (int.TryParse(args[0], out processId))
            {
                proc = debugEngine.Attach(processId);
            }
            else
            {
                proc = debugEngine.CreateProcess(args[0], ""DebugModeFlag.Debug, null);
            }
            while (proc.IsAlive)
            {
                // Let the debuggee run and wait until it hits a debug event.
                ManualResetEvent handle = proc.Go() as ManualResetEvent;
                handle.WaitOne();
                object o = proc.StopReason;
                // Process is now stopped. proc.StopReason tells us why we stopped.
                // The process is also safe for inspection.            
                ExceptionThrownStopReason m = o as ExceptionThrownStopReason;
                if (m != null)
                {
                    ProcessException(m, proc, callback);
                    continue;
                }
            }

Note : Important thing here is you need to run this in a separate thread or use async delegate to avoid application waiting endlessly.  This was not in the sample provided by Mike Stall :-).

Modifications I did


Mike Stalls blog explains the basics such as how to attach to the target application and print the exception. I took it little further to have a UI around. Also planning to add more scenarios such as capturing when the classes are being loaded along with capturing eaten exceptions.

Intended audience

Mainly the developers who are coding in .Net for years but don't know how the .Net application works internally. Then the developers who are in same state of mine where they had to deal with so many eaten exception. Finally developers who are interested in writing their own debugging tools .I know there are so many apps available which does the same .But seems little difficult to make suitable for our purpose.

Source code


As I am planning to add more features I am not attaching it with this blog post.You need to go codeplex for the sample ie the application named DotNet Watcher. This is my first published project in codeplex.

1 Locate the dll at :\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\MdbgCore.dll

1 comment:

Matthew Chan said...
This comment has been removed by the author.