Click here to Skip to main content
14,332,022 members

Catch All Bugs with BugTrap!

Rate this:
4.32 (83 votes)
Please Sign up or sign in to vote.
4.32 (83 votes)
31 Jan 2009MIT
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:

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

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

Share

About the Author

Maksim Pyatkovskiy
United States United States
No Biography provided

Comments and Discussions

 
AnswerRe: Manually trigger BugTrap Pin
Maksim Pyatkovskiy22-Aug-06 5:04
memberMaksim Pyatkovskiy22-Aug-06 5:04 
GeneralBugTrap dialog not being invoked Pin
Dave Calkins18-Aug-06 2:42
memberDave Calkins18-Aug-06 2:42 
GeneralRe: BugTrap dialog not being invoked Pin
Maksim Pyatkovskiy18-Aug-06 5:36
memberMaksim Pyatkovskiy18-Aug-06 5:36 
GeneralRe: BugTrap dialog not being invoked Pin
Dave Calkins18-Aug-06 11:32
memberDave Calkins18-Aug-06 11:32 
GeneralRe: BugTrap dialog not being invoked Pin
Maksim Pyatkovskiy18-Aug-06 13:02
memberMaksim Pyatkovskiy18-Aug-06 13:02 
GeneralRe: BugTrap dialog not being invoked Pin
Dave Calkins18-Aug-06 19:05
memberDave Calkins18-Aug-06 19:05 
GeneralRe: BugTrap dialog not being invoked [modified] Pin
Plamen Petrov20-Aug-06 21:11
professionalPlamen Petrov20-Aug-06 21:11 
GeneralRe: BugTrap dialog not being invoked Pin
Maksim Pyatkovskiy21-Aug-06 6:37
memberMaksim Pyatkovskiy21-Aug-06 6:37 
Plamen, I am very thankful for your bug report and for minidump file that you sent me.
I have one idea that could explain why sometimes you see standard Windows error dialog and why dbghelp.dll was not able to restore the stack trace.

Visual Studio 2005 has a new option called "buffers security check". When this option is enabled, the compiler inserts special "cookies" after each block in the heap, even in the Release mode. When you perform memory allocation, heap manager validates heap and checks if these cookies were not changed since the last heap access.

When your application experiences memory overrun and overwrites allocated heap blocks, heap manager resets unhandled exception handler (i.e. it blocks BugTrap), generates context record and passes this record to the standard OS exception handler. You may find this code in Visual C++ Runtime library, in file "gs_report.c". As a result, BugTrap, or any other exception handler doesn't have any chance to report the problem. I don't know why Microsoft did this.

This scenario works if memory corruption is not too severe. If changes in memory are deeper, they could impact heap control blocks, the stack or the global variables. In this case heap manager or any other code in your application may fail before "cookies" validation. In this case an access violation is passed directly to BugTrap. I understand that this is pretty inconvenient, but this is how it works, and FYI memory overruns are THE MOST difficult in detection. Recently I was debugging a project with extremely horrible code (the original developer didn't know what to do with their program) and it had the same problems. I had all tools in place: Visual Studio debugger, Global Flags, the latest version of BoundsChecker. Unfortunately all these tools were not as helpful as I would expect and human's brain still plays the major role in this process.

Based on your minidump file I have noticed that you had also experienced a problem in the heap manager. It is very likely that this problem was caused by the memory overrun. It is also possible that the new dbghlep.dll has some bugs, or it differently handles certain scenarios. However, it is also possible that some stack information was corrupted as a result of this or another memory overrun. This could lead to the inability of dbghep.dll to restore the stack trace. This seems to be very real because dbghelp.dll was able to restore stack traces for the remaining threads (you may check this in errorlog.xml). Hopefully you have a midnump file and this could be analyzed in Visual Studio or in the WinDbg. Either tool could use PDB files and provide you with more information.

Thanks again for your report.
GeneralRe: BugTrap dialog not being invoked Pin
Dave Calkins21-Aug-06 5:09
memberDave Calkins21-Aug-06 5:09 
GeneralMissing Debug Info [modified] Pin
Plamen Petrov16-Aug-06 3:25
professionalPlamen Petrov16-Aug-06 3:25 
GeneralRe: Missing Debug Info Pin
Maksim Pyatkovskiy16-Aug-06 6:21
memberMaksim Pyatkovskiy16-Aug-06 6:21 
GeneralRe: Missing Debug Info [modified] Pin
Plamen Petrov16-Aug-06 21:22
professionalPlamen Petrov16-Aug-06 21:22 
GeneralRe: Missing Debug Info [modified] Pin
Plamen Petrov16-Aug-06 22:52
professionalPlamen Petrov16-Aug-06 22:52 
GeneralRe: Missing Debug Info Pin
Maksim Pyatkovskiy17-Aug-06 6:40
memberMaksim Pyatkovskiy17-Aug-06 6:40 
GeneralRe: Missing Debug Info [modified] Pin
Plamen Petrov17-Aug-06 22:50
professionalPlamen Petrov17-Aug-06 22:50 
GeneralRe: Missing Debug Info Pin
Maksim Pyatkovskiy18-Aug-06 5:55
memberMaksim Pyatkovskiy18-Aug-06 5:55 
GeneralRe: Missing Debug Info Pin
Plamen Petrov18-Aug-06 10:01
professionalPlamen Petrov18-Aug-06 10:01 
GeneralRe: Missing Debug Info Pin
Maksim Pyatkovskiy18-Aug-06 11:34
memberMaksim Pyatkovskiy18-Aug-06 11:34 
GeneralRe: Missing Debug Info Pin
Plamen Petrov20-Aug-06 21:04
professionalPlamen Petrov20-Aug-06 21:04 
Generalmake screenshot application only Pin
ssuk2-Aug-06 20:31
memberssuk2-Aug-06 20:31 
GeneralRe: make screenshot application only Pin
Maksim Pyatkovskiy3-Aug-06 5:34
memberMaksim Pyatkovskiy3-Aug-06 5:34 
GeneralCan't set support details [modified] Pin
VJ_Mavrick27-Jul-06 5:00
memberVJ_Mavrick27-Jul-06 5:00 
GeneralRe: Can't set support details Pin
Maksim Pyatkovskiy27-Jul-06 5:33
memberMaksim Pyatkovskiy27-Jul-06 5:33 
GeneralCustom Help Pin
Simon Brown25-Jul-06 23:28
memberSimon Brown25-Jul-06 23:28 
GeneralRe: Custom Help Pin
Maksim Pyatkovskiy26-Jul-06 4:49
memberMaksim Pyatkovskiy26-Jul-06 4:49 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Article
Posted 29 Jun 2006

Stats

1.6M views
8.6K downloads
292 bookmarked