Debugging ASP.NET Applications Interactively on Production

Production is often like a blackbox to the developers. An ideal server system does not have Visual Studio installed. If it is your website that is hosted in such a server, I hope there are couple ways you trap critical application messages and see how your application is doing. You can write Windows Logs, which you can access from Event Viewer of Windows. You can also write logs to the file system or web service. However, none of the Windows Logs, File based and Web service based logging is interactive. You have to dig through the pile of log messages and investigate in forensic style.

DebugView for Windows

The quickest, lightest and the most interactive way you can do is using DebugView for Windows brought to us by Microsoft Sysinternals team. This tool can capture debug output on your local system as well as any computer in the network that you can connect via TCP/IP. If you are connected to work via VPN, this should ideally work as well. It is as interactive as Wireshark for network tracing and Fiddler for HTTP tracing. Let us quickly see what we are talking about. Here’s an example of what you might expect to see in DebugView view:

Output

If you drill down to the Capture options, you will find various types of messages that it can trace. You can also specify whether it should show clock time, time elapsed and process IDs.

Capture

One of the very useful features of DebugView is that you can export the messages to files, share with coworkers and they can open it using DebugView. If you intend to run tracing for longer period of time, you can specify file path where it will be saved and should it roll beyond certain size of the file.

Making Your Application Talk to DebugView

Two ways your application can talk to DebugView: Trace.WriteLine and Debug.WriteLine. Because, ideally traces are captured by the Trace listeners, it is preferable that you use Debug.WriteLine.

System.Diagnostics.Trace.WriteLine("debug: finding customer: 10928309");

System.Diagnostics.Debug.WriteLine("debug: debit method has been invoked by: 10928309, 5000");

No matter it is invoked from your referenced assemblies inside the bin folder, HttpModule, HttpHandler, WebService, class files in App_Code or codebehind files for that matter, DebugView is capable of capturing it and instantly showing it in its interactive screen.

If you doubt your application is not doing what it was supposed to be in certain scenario, or you have found it is responding slower than acceptable range/SLA, you may want to put Debug.WriteLine as many places as you want, run down the suspected scenario and trace where it is taking the most time.

Activate Debugging in Your Application

Now that you have setup the probes, it is time that you activate debugging in your application. In order to do that, you can set debug=true in the web.config file.

<system.web>      

    ...      

    <compilation debug="true"/>      

    ...

</system.web>

Alternatively, you can insert preprocessing directive on top of the class(es) that you will be debugging:

#define DEBUG

This will prevent the compiler to exclude Debug.WriteLine instructions as part of the build.

Gotchas

DebugView needs to capture Global Win32 messages, but Visual Studio already sets a system-wide hook on that. So, close Visual Studio and run from IIS. Should you have the Visual Studio debugging facility, you do not need DebugView anyway, because you can then see the trace messages in the Output window of Visual Studio.

Hope it helps.

Comments

One thought on “Debugging ASP.NET Applications Interactively on Production

  1. Pingback: DotNetShoutout

Leave a Reply