[펌] BugTrap 상세 설명

1. 첨부의 *.pdf 의 설명이 아래것보다 더 자세함.

BugTrapDoc.zip

2. 우측의 Go to the article at CodeProject 이 원본인듯.

---

출처 : http://www.intellesoft.net/bugtrap1.shtml

BugTrap for Win32/64 & .NET (part 1)

Go to part 2

Go to the article at CodeProject

Our business is based on IT consulting and it's vital for us to provide our clients with stable products. In real life every more or less complex system includes effective code as well as developer mistakes (bugs). Though in theory it's acceptable when a program is stable enough to satisfy most user needs, there is no user who likes general protection faults, access violations and other kinds of unexpected errors.

IntelleSoft is concerned about all bugs - big and small, serious and trivial. Our software is developed using numerous error preventive approaches, including safe programming, redundant data validation, self-recovery in critical code parts, etc.

Moreover, we are interested in tracking and fixing those errors that still have not been handled and might violate normal program execution. If you expect an error, you would rewrite the code to avoid a potential problem. But what would you do with unexpected errors? You just finished debugging your application, and it seems to be working as expected. You might think that your code is perfect (well, almost perfect) but user downloads your program and somehow it stops working. Usually it's especially difficult to find the reason of such errors because they are unpredictable by their nature. It's impossible to predict the sort of the problem and the piece of code that causes the problem. A lot of errors may occasionally happen on remote customer machine and at best developers may receive a screenshot of system error message. Indeed user cannot tell the developer what's wrong in program code!

Right in this case BugTrap comes to the play. Rather than making assumptions about possible errors or modifying program source code, BugTrap automatically substitutes system error handler and monitors any exceptions not handled in the program. As soon as any error takes place, BugTrap catches it and prompts a user to send bug report to the developer:

So what errors can BugTrap handle? - In short, it can handle all types of errors!

1. All sorts of access violations and general protection faults:

typedef int (*TFunc)(const char* pszParam); TFunc pFunc = (TFunc)GetProcAddress(hDll, "NoSuchFunction"); (*pFunc)("This is one of possible developer mistakes"); // Access violation

2. Unlike most other tools, BugTrap intercepts unhandled C++ exceptions and unwinds stack trace to the throw statement. BugTrap natively recognizes MFC, ATL and STL exceptions.

std::vector<int> arr(10); for (size_t i = 0; i <= arr.size(); ++i) arr.at(i) = 0; // Array subscript is out of range

Error report may be automatically delivered to product support by e-mail, HTTP or light-weight TCP-based network protocol:

Advanced users and programmers may immediately preview report, save it to the file, or use enhanced graphical interface to examine the problem:

On the next page you may see how error report can be used to find and fix the problem.

Go to part 2

Go to the article at CodeProject

Downloads

Documentation

Setup

Source Code

---

BugTrap for Win32/64 & .NET (part 2)

Go to part 1

Go to the article at CodeProject

Error report includes huge amount of useful information including error reason, error location in program source code and comprehensive description of user computer environment which is vital for repeating the problem on developer's side. A developer can customize the amount of extracted information, hide or show program code and even add custom log files with arbitrary contents.

BugTrap supports three completely independent approaches for detecting error location in the source code:

• Minidump files
• Automatic PDB file analysis
• Automatic MAP file analysis

Every approach has its own advantages and specific, therefore BugTrap natively combines them together.

1. Minidump files can be opened directly in Visual Studio .NET and an error can be seen "on the fly". It looks just like normal debugging of interrupted program:

2. PDB files are ideal for product testers and SQA groups because you don't have to debug the problem. Error details are available for quick review in BugTrap dialog:

Note that the support of PDB files can be disabled in order to hide program source code on customer side.

3. And finally CrashExplorer may restore stack trace on developer computer from raw exception addresses stored in error log and standard application's MAP or PDB file generated by Microsoft Visual Studio C++ compiler:

• Supported platforms: Win32/64 and .NET
• Supported environments: Visual Studio 6/.NET/2005/2008
• Supported operating systems: Windows 98/Me/NT 4/2000/XP/Vista