There are two types of bugs: those that you get when your pride and joy is sitting in front of you. And those that happen when a customer uses it. Guess which type is the more common – and which is the more difficult to fix!

The normal approach to this sort of problem (apart from panic) is to put some sort of tracing into the software to enable you to try to figure out what the heck the user was doing and hopefully to allow you to reproduce and fix the problem. The trouble is that usually the customer isn’t anywhere readily accessible and that getting them to send any sort of trace can be problematic. Even when you’ve got a trace, it can be time consuming (to say the least) to wade through the voluminous data to track down the bug.

SmartInspect attacks this problem by decoupling the tracing aspect of debugging from viewing the resulting data. In a similar manner to the existing .NET Debug and Trace commands, you insert SmartInspect calls where you want to detect and log some activity. However, unlike Trace and Debug, the output does not go to the Visual Studio Output window. Instead, it goes either to a log file or – even better for many purposes – directly to the SmartInspect viewer console via TCP/IP.

The SmartInspect system allows you to trace entering and leaving a method as distinct entities and this shows up on the SmartInspect console as matching indentations in the display. Similarly, you can trace thread and process activation and deactivation as separate traceable events, letting you distinguish between process flow and  the lower level, more detailed, method invocation. This can lead to information overload in the trace, so the SmartInspect console lets you define ‘views’ – filters – on the data, which should let you pick out the stuff you need quickly and efficiently. The information in SmartInspect is also presented as a collapsible tree view, so you can expand one particular node  while keeping other nodes of less interest closed up.

To see how it works, take a typical example from a (real life) piece of VB .NET code:

Sub StatusChangeEvent(ByVal dwStatus As Integer)
  Dim p As IntPtr
  SiAuto.Main.EnterMethod("StatusChangeEvent: {0:D1}", _
    New Object() {dwStatus})
  PeerGraphGetProperties(g_hGraph, p)
     ’ etc.
  SiAuto.Main.LeaveMethod("StatusChangeEvent")
End Sub

This doesn’t do very much apart from log the fact that the StatusChangeEvent method has been called and then exited. You might notice that there’s one peculiarity with the EnterMethod call. In order to display the method’s arguments as I’ve done here, you have to use the rather artificial New Object syntax shown. Gurock says that this is by design as it has found problems with using the C# params or VisualBasic ParamArray keyword.

You can customise the views in the SmartInspect console to identify information pertinent to the problem you are trying to track down. Click HERE for a larger view (in a popup window)

However, if you can’t live with that, you can do something about it: write your own version. Gurock includes the C# source code of the class library with the Professional Edition and it’s a trivial task to add your own EnterMethodFormat routine, say, with a variable parameter list.

Initially, I was a little sceptical about SmartInspect. It didn’t seem to offer very much over the usual Trace/Debug facilities available in Visual Studio. But then I started using the SmartInspect console. And I have to say, I was impressed. Very impressed. For the first time I could get an overview of what my multithreaded communications application was actually doing – where the asynchronous thread activations were occurring and, more importantly, when they were occurring. SmartInspect has very good time formatting options and you can configure the console to display the absolute time, the time difference or the elapsed time as you require. Very neat indeed.

So far, I’ve only used the basic logging and process monitoring – there’s quite a bit more you can put in such as logging SQL commands or collections or even bitmaps.  You can also configure the TCP/IP settings to send the trace data to a specific IP address. This should be quite useful for a larger project that I’m working on – one that involves a user in Australia. As you can imagine, since I’m in England, this involves some difficulty on occasion. So I’m going to try connecting SmartInspect directly to my static IP address and watching the trace in real time. I’ll update this review in a couple of months’ time with the results.

The SmartInspect Console lets you view the results of the tracing independently of the main application.

Overall, SmartInspect looks to be a very useful diagnostic tool – and I intend to have a serious go at using it to see how it performs. In essence, SmartInspect is a simple idea and has been well executed by Gurock. There’s only one small cloud that I can see – if SmartInspect is as useful as it looks to be at first sight, how long will it be before Microsoft snaffles the idea for the next release of Visual Studio?

Dermot Hogan

November 2005