Catch all bugs with BugTrap!

• Download documentation - 731.7 KB
• Download setup - 2,555.4 KB
• Download source code - 5,570.7 KB

What's new in this version?

1. .NET support - now BugTrap supports native, managed and mixed assemblies.
2. Source code - I have been criticized for missing source code many times. Full source code of BugTrap is included!
3. Thread isolation - BugTrap suspends all threads in the application and displays GUI from a separate thread. This approach improves stability and prevents new errors that could be thrown by other threads.

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 hope to make 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:

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.

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).

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:

• Trapping Bugs with BlackBox
• Post-Mortem Debugging Your Application with Mini-dumps and Visual Studio .NET
• XCrashReport: Exception Handling and Crash Reporting
• Finding crash information using the MAP file

Adding BugTrap support to Win32 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 bellow adds BugTrap support to Win32 applications:

#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:

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:

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

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

Adding BugTrap support to .NET applications

The .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 exceptions.

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

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 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 my web site for the most recent updates. All major updates are submitted to http://www.codeproject.com/

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.

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.

That's it! Happy bug-trapping!