A Debugging Stub for Automated Tests (DebugStub

Environment: Win32 (Windows NT, 2000, or XP)

Description

This article provides a simple program that acts as a debugger while running another user-specified application.

Here's what it does:

  • Send a log of debugging events to STDOUT.
    This includes DLL loading information, thread creation/destruction info, exceptions and fatal errors (page faults), and so forth.
  • Intercept and handle crashes of the debugged application.
    Instead of letting the system display an error message requiring user interaction, the debugged application is immediately terminated, and the debugger exits with a specific return code.

What I Use It For

The software development team I lead uses a server that automatically runs a set of tests every time a developer does a check-in of his code changes.

This includes:

  • Building the affected application in both debug and release modes.
  • Building and running some automated tests.

During these automated tests, we may detect and report problems using any technique. But sometimes, the whole application may crash because of a page fault or other fatal error. When this happens, the system normally suspends the crashed application and waits for the user to confirm what should be done (for example, debug or terminate the application).

Because these are fully automated/scripted tests running on a rarely accessed machine, this user intervention is not desirable.

The most elegant way to avoid it, on Win32, is to pretend to the system that we are debugging the application. Additionally, this allows the test script to access an execution log (written using OutputDebugString), which is integrated in an error report.

Usage

A single source file is attached to this article. It is the C++ source code of a console application that you should compile with your favorite compiler (I had used MSVC6): DebugStub.exe.

Once compiled, the application can be tested as follows:

  • Drag and drop any application (not a shortcut) onto DebugStub.exe.
    Note that this will not allow you to see any error message, and does not allow you to pass any parameters to the application.
  • Lauch it from the command line:
    • Make sure you know how to launch the debugged application from the command line, passing parameters as appropriate.
    • Just insert DebugStub.exe (or a full path as appropriate) at the beginning of the command line, and the other application will run as usual but under DebugStub's control.
    Any application can be debugged this way (it does not need to be a console app); you just need to understand how to launch it from the console.

About This Implementation

I do not have much to say about the source code. All the system calls are public and documented Win32 APIs. However, I had found it difficult to put the pieces together and handle the essential cases appropriately, so I think you may find it useful.

Note, however, that this example has been coded very quickly. It is only Good Enough For What I Want To Do With It™. You will probably want to tune the output for your own needs.

 
--
 Ivan Vecerina, Dr. med.  <>  http://www.post1.com/~ivec
 Brainbench MVP for C++   <>  http://www.brainbench.com

Downloads

Download source -- 8 KB


Comments

  • There has a good Debugger Tool.

    Posted by pengch on 03/31/2004 02:15am

    There has a good Debugger Tool. Try it now.
    Auto Debug Tool

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Live Event Date: October 29, 2014 @ 11:00 a.m. ET / 8:00 a.m. PT Are you interested in building a cognitive application using the power of IBM Watson? Need a platform that provides speed and ease for rapidly deploying this application? Join Chris Madison, Watson Solution Architect, as he walks through the process of building a Watson powered application on IBM Bluemix. Chris will talk about the new Watson Services just released on IBM bluemix, but more importantly he will do a step by step cognitive …

  • Live Event Date: October 23, 2014 @ 12:00 p.m. ET / 9:00 a.m. PT Despite the current "virtualize everything" mentality, there are advantages to utilizing physical hardware for certain tasks. This is especially true for backups. In many cases, it is clearly in an organization's best interest to make use of physical, purpose-built backup appliances rather than relying on virtual backup software (VBA - Virtual Backup Appliances). Join us for this eSeminar to learn why physical appliances are preferable to …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds