.NET Production Debugging

Question

I've had a Windows app in production for a while now, and have it set up to send us error reports when it throws exceptions. Most of these are fairly descriptive and help me find the problem very quickly (I use the MS Application Exception Block).

On a few occasions I have reports that are issues that I can't reproduce, and seem to only happen on a few client machines.

I don't have physical access to these client machines, what are some strategies I can use for debugging? Would it be better to build some tracing into the code, or are there some other alternatives?

Thank you.

Edit: I should have been more clear: The error reports that I get do have the stack trace, but since it's production code, it doesn't indicate the exact line that caused the exception, just the method in which it was thrown.

Answer 1

I always use this module from Jeff for unhandled exceptions, sending me an email with stacktrace etc.

Answer 2

I'd make use of the event log. Take a look here:

http://support.microsoft.com/kb/307024

Answer 3

You are on the right track. You need to create a tracking module which logs actions/exceptions locally.

You can then have a button or a menu option that the user can click to either automatically email you this information the moment the issue occurs, or they can have the option to get hold of the file so that they can transfer it to you in any other way.

You can even build-in a diagnostics code to run an integrity check on the system and sends you a report (maybe it runs all your unit tests to see if they work on that system).

Answer 4

One option is to generate a (mini-)dump file as close to the point where the exception is thrown as possible. This article talks about how to do this from managed code.

You could then load the dump file into Visual Studio or WinDbg and examine it with the aid of SOS

Answer 5

Smart Inspect from Gurock Software has come in handy many times for me. It is very easy to put into a .NET application and gives you extremely powerful control when analyzing log files. It has log levels that allow you to turn off certain functionality except in certain cases so you don't lose performance.

They even have server software that your software can connect to to save logs when you do not have full access to the machines. For example, you could have a server running at www.yourdomain.com. Your software would have a configuration option to turn on debugging. Smart Inspect would be configured to send the log data to your server (And optionally to a local file) so that you could get live logging no matter where the software is being run.

Smart Inspect is very easy to configure and has many features that you can use to help. I've use it to debug high impact multi-threaded server applications on the fly without taking down the machines. It has all the hooks to keep track of different processes, threads and machines.