Classic VB Corner

Executing Debuggables

How do you track down what's really going on inside your compiled EXEs?

• By Karl E. Peterson
• 11/17/2008

Almost undoubtedly, you've been using Debug.Print ever since you started using Classic VB. It's often the single most valuable debugging tool in your toolbox, as you can use it to generate a running stream of status messages without interfering in any way with the normal course of execution. But just as surely as you've used this useful tool in the past, you've also wished it wasn't limited to the IDE.

Fortunately, Win32 offers us the OutputDebugString function, which performs almost exactly the same function as Debug.Print does. This function is incredibly easy to use and can be wrapped up as an almost functionally equivalent replacement for Debug.Print as such:

Private Declare Sub OutputDebugString Lib "kernel32" _
  Alias "OutputDebugStringA" (ByVal lpOutputString As String)

Public Sub DebugOutput(ByVal Data As String, _
  Optional ByVal CrLf As Boolean = True)
  ' Output to the ether... Someone may be listening... 
  Debug.Print Data;
  Call OutputDebugString(Data)
  If CrLf Then
    Debug.Print
    Call OutputDebugString(vbCrLf)
  End If
End Sub

Debug.Print "Trailing semi-colon ";
Debug.Print "suppresses linefeed."

To achieve that same effect with our DebugOutput routine above, I added an optional parameter that assumes you want the CrLf output but allows you to override it. Unfortunately, there's no way for us to entirely emulate the DOS legacy Print command with it's ability to embed successive strings using semicolons and commas, so you'll need to patch up any implied concatenation. Migrating such statements from Debug.Print to DebugOutput requires this sort of tweak:

Debug.Print "The value: "; x
DebugOutput "The value: " & CStr(x)

But where does that output go when you're running an EXE? Well, here are two very handy (and free!) tools I'd like to recommend. Either can read the output from OutputDebugString. My favorite is DBWin32, written by Grant Schenck, because it supports all 32-bit Windows platforms. If you've ever downloaded the SysInternals suite, you may already have DebugView, which was written by Mark Russinovich and requires at least Windows 2000 to run. Something I never noticed until writing this column is that the two don't play nice together -- only run one at a time for best results.

Both utilities allow you to save the results to a text file, but DBWin is a bit friendlier in this regard, as it operates in an MDI manner, effectively isolating the output from each process into its own child window. DebugView does offer you the ability to filter what output it displays, though, so you can still isolate just what you want. (And, yes, this can be an issue, as Windows is full of debug code!)

Granted, you can always rig your application so it outputs all the debugging information to a text file or database. But that's a tremendous overhead to bear for what should be extremely rare circumstances. Sending this information off into the ether, though, is nearly harmless from an efficiency perspective, as it incurs virtually no overhead. And it's there when you need it. Just be sure that your debugging messages are something you're willing to allow others to see. Anyone who ever runs tools like DBWin32 or DebugView can see this output. And now, so can you!