Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / web / HTML

Catch All Bugs with BugTrap!

4.34/5 (84 votes)
31 Jan 2009MIT5 min read 1   9.1K  
A tool that can catch unhandled errors and exceptions, and deliver error reports to remote support servers

What's new in this version?

  • 64 bit support - now BugTrap natively supports Win64
  • Multi-monitor support - BugTrap may capture screenshots from several monitors
  • Other enhancements - Tons of features/options added since last update. See app history for details

Introduction

Some time ago, I was working on a multi-tier application with quite complex logic. The application was handling medical information, and it was important to correctly synchronize data under all circumstances. I put extra code to make the application as stable as possible, and added automatic backups and self-recovery. Do you think it solved all problems?

No, I was still searching for a tool to handle problems, seen by customers, remotely. How could I assist them and debug the problem if I lived on the other side of the globe? Eventually, I found this excellent Jim Crafton article about a tool capable of intercepting unhandled errors. That was a solution!

Unfortunately, the original black-box was not customizable, it didn't support mini-dump files or Unicode strings, and it didn't have any server. In spite of these limitations, it was an excellent starting point because I knew exactly what kind of a tool I wanted. I started working on my own tool in the hope of making it flexible and customizable, and a powerful solution.

Overview

Usually, it's very frustrating to receive a message from your customer saying that your program doesn't work. Most users may not let you know what's incorrect in your application and which piece of code went wrong. Windows has a built-in handler for unhandled errors, however, this default handler might be useless when errors happen on the customer side, because you rarely want to send your error report to Microsoft:

Default Win32/64 error handler

BugTrap solves this problem by overriding the default error handler. BugTrap gathers error details such as address, call stack, and the computer environment. It's also possible to add an arbitrary number of custom log files, with additional information on the default error report, using built-in or external logging functions.

BugTrap may save error reports on the disk, or automatically deliver error reports to the developer's computer by e-mail, over HTTP, or through a fast low-level TCP-based network protocol. The BugTrap server automatically manages the error reports repository, and notifies developers about any new errors.

Network diagram

BugTrap stores error descriptions in log and mini-dump files. Mini-dump files may be opened in Microsoft Visual Studio .NET and in WinDbg. The BugTrap package also includes a CrashExplorer utility that can extract symbolic information from MAP and PDB files. There is a special BugTrap version for .NET applications (currently under development).

Simplified dialog

Dialog with error details

Preview dialog

All details are available in the BugTrap documentation. The documentation is also included as part of the Setup. If you like to know how BugTrap works, you may read these articles:

Adding BugTrap Support to Win32/64 Applications

BugTrap is redistributed as a dynamic-link library (DLL). Two versions of the BugTrap DLL are available: the ANSI version, and the Unicode version.

DLL name Character encoding
BugTrap.dll ANSI multi-byte character strings
BugTrapU.dll Unicode strings

The code below adds BugTrap support to Win32/64 applications:

C++
#include "BugTrap.h"

#pragma comment(lib, "BugTrap.lib")      // Link to ANSI DLL
// #pragma comment(lib, "BugTrapU.lib")  // Link to Unicode DLL

static void SetupExceptionHandler()
{
    BT_SetAppName(_T("Your application name"));
    BT_SetSupportEMail(_T("your@email.com"));
    BT_SetFlags(BTF_DETAILEDMODE | BTF_EDIETMAIL);
    BT_SetSupportServer(_T("localhost"), 9999);
    BT_SetSupportURL(_T("http://www.your-web-site.com"));
}

The SetupExceptionHandler() function may be called from InitInstance() or main(), depending on the type of your application.

When your application experiences a problem, the user is prompted by BugTrap to submit an error report to the BugTrap server. The error report includes many details of the user environment. The report also includes a complete stack trace for the call that caused a problem.

With BugTrap, you can debug the problem using two different approaches.

1. You can open post-mortem mini-dump files in Visual Studio:

Minidump file in Visual Studio

2. You can use the built-in utility CrashExplorer:

When BugTrap is building stack traces, it searches for the PDB file – a file that holds debugging information. If this file is available, BugTrap is able to show function names and line numbers next to each address. Obviously, the PDB file makes the stack trace much nicer, but most developers prefer not to distribute PDB files to end users because PDB files could simplify program reverse engineering.

Therefore, BugTrap doesn't require PDB files on user computers. Instead, it saves raw function addresses to the log:

Dialog with no source information

So, the end user doesn't have any clue what's behind these hexadecimal numbers.

CrashExplorer reverts back all functions names and line numbers based on the PDB/MAP file and addresses in a log:

CrashExplorer restores function names and lines numbers from MAP or PDB file

Adding BugTrap Support to .NET Applications

.NET version of BugTrap is redistributed as managed library: BugTrapN.dll. This DLL consists of managed and unmanaged code. Such design lets BugTrap support pure managed .NET assemblies as well as mixed C++ assemblies that could throw managed .NET exceptions and native Win32/64 exceptions.

BugTrap for .NET exposes both managed and unmanaged (native) interfaces. Managed interface is accessible from C# or VB.NET code:

C++
ExceptionHandler.AppName = "Your application name";
ExceptionHandler.Flags = FlagsType.DetailedMode | FlagsType.EditMail;
ExceptionHandler.DumpType = MinidumpType.NoDump;
ExceptionHandler.SupportEMail = "your@email.com";
ExceptionHandler.SupportURL = "http://www.your-web-site.com";
ExceptionHandler.SupportHost = "localhost";
ExceptionHandler.SupportPort = 9999;

Unmanaged interface is accessible from native Win32/64 code and was discussed earlier. It is possible to use any interface or even both interfaces in the same application.

Updates

I periodically fix errors and add new features. This frequency of such updates depends on your feedback. You may check https://github.com/bchavez/BugTrap for the most recent updates. All major updates are submitted to The Code Project.

Building Notes

Most developers may go ahead and download the Setup - it installs all necessary files and components. However, some professionals enjoy building all components from scratch. Those developers may download BugTrap source code from here.

I have been trying to make BugTrap DLL as compact as possible. Therefore BugTrap DLL does not use MFC/ATL/WTL. I have been using pure C and C++. In particular, you will find several classes from my own library: collection classes, IO streams, built-in XML parser, etc. BugTrap DLL depends on zlib. I have included it in the archive to simplify building.

CrashExplorer depends on STL, Boost and WTL. Both libraries must be pre-installed on your computer.

Thank you!

I appreciate support, help, contributions, and even simple feedback that I am getting from many of you. BugTrap could not be in a position to meet the demands of modern software without this.

That's it! Happy bug-trapping ;-)

License

This article, along with any associated source code and files, is licensed under The MIT License