Answer:
The BugTrapper Console is generally used for creating TCI files (Trace Control Information files which the user sets to tell the Black Box what to trace) and viewing Code Level Black Box log files however, yes, you can trace an application with the Console as BugTrapper is imbedded with a Code Level Black Box. In BugTrapper, simply click on 'new executable', 'run new executable' or 'attach to running executable', create your TCI, and the imbedded Black Box will begin tracing immediately.

Question 8

Can I trace and record with the BugTrapper Console as I would with the Code Level Black Box?

Answer

The BugTrapper Console is generally used for creating TCI files (Trace Control Information files which the user sets to tell the Black Box what to trace) and viewing Code Level Black Box log files however, yes, you can trace an application with the Console as BugTrapper is imbedded with a Code Level Black Box. In BugTrapper, simply click on 'new executable', 'run new executable' or 'attach to running executable', create your TCI, and the imbedded Black Box will begin tracing immediately.

Question 9

Can BugTrapper work in Dr.Watson mode by just dumping the info when the FAULT occurs?

Answer:

Yes, if you set the filter to "empty" (unselecting everything in the 'Trace Options' window), BugTrapper will work like Dr.Watson and only dump when the crash occurs. The information will be represented as a symbolic stack and not in hexadecimal format so working with it is greatly simplified. In addition by using BugTrapper you will get other information including references to the source, all local variables, and all system information regarding the computer such as version of all DLLs involved, environment variables, hardware and software information.

Question 10

I am looking for a solution to detect a memory leak in our application. Will BugTrapper help to accomplish this task?

Answer:

BugTrapper is not necessarily aimed toward memory-related problems. For example, with it you may identify a problem that occurs only at some remote machine, which is related to the environment of this machine (e.g. file permissions). On the other hand, it will not pinpoint the exact location of a memory related issue, such as overwrite or leak. BugTrapper will show you the complete execution path, but you still need to analyze this log in order to locate the problematic issue. In this way, BugTrapper is used for memory leak detection. For example, one of our customers noted that a class destructor did NOT appear in the log while a thread was "killed" using TerminateThread - this call did not unfold the stack, and therefore the destructor was not called. Because this was dependent on a specific multi-threading context switching, BugTrapper was the only solution that clearly showed the root cause of this problem.

Question 11

Would you use BugTrapper as a profiler?

Answer:

BugTrapper does not provide profiling statistics which are readily available to you via conventional profiling tools (i.e. how much time was spent in a particular function that was called, the averaged execution time for a function and for all of its descendents, etc) However, when using time stamps in BugTrapper, you are able to discern when the function was called and how much time was spent in it (this, again, is not averaged). In addition, you can convert a trace log into ASCII or RTF format. Then, you can parse the log and get profiling statistics (e.g. how many times the function was called during the program's execution and how long each invocation of the function took). Thus, this information can be used to profile an application.

Question 12

Do I need to be local administrator to be able to attach to a service?

Answer:

Yes. You need to have the right to start/stop whatever process you are attempting to use BugTrapper on. Because Services is an administrative right executable, you need administrative rights for tracing this process. We have a special component for tracing services from startup called Remote Controlled Black Box (Service).

Question 13

Is there a way that I can trace and record multiple executables simultaneously?

Answer:

Yes. Simply prepare a TCI file for the multiple executables.

Question 14

How does BugTrapper work with multithreaded applications?

Answer:

BugTrapper is particularly invaluable when you work with multithread applications. It can trace and record applications compiled in release mode and it does not break the thread's synchronization and hardly affects the application performance. It is the only solution for tracing and debugging multi-threaded and time-critical applications.

Question 15

Can BugTrapper show a handled exception?

Answer:

BugTrapper shows you where the exception occurred and the kind of exception. This is shown in the exception tab of the trace detail pane as well as the trace tree pane itself. BugTrapper allows you to easily navigate through the trace tree pane by using the exception tab. You can also assign global trigger exception with a resulting action such as stack dump. For each exception you will be able to see the kind of exception and sequence of function call that lead up to it. If the exception occurred in Kernel mode, you will be able to see it on WIN NT or WIN 2000.

Question 16

When a program exits because of an exception it will be nice to know the type of exception.

Answer:

With Visual Basic applications, the exception will appear automatically as a runtime error (type of exception) and the number of the runtime error. For C++ applications, in order to get the exception information, you must select the trigger exception with an assigned action for example "stack dump".

Question 17

BugTrapper can capture bugs that crash an executable, but is there any way to trigger a dump of the cyclic trace file based on variables and/or execution paths within the executable being recorded? We just had a problem where one transaction in 30000 was giving an error once or twice a day. It would be very difficult to have someone sit there and watch for the error condition and then perform a quick manual dump of the log file.

Answer:

As a matter of fact, we do support such a feature in "Triggers and Actions". Basically, what 'Triggers and Actions' allows you to do is perform an event based on a certain trigger. For example: if function X is called, stop tracing until function Y is called, or, dump the contents of the call stack (stack dump) if function C is called (this is beneficial because now the call stack will be available even without a crash), or dump log file if a certain condition is met, etc.

Question 18

Do you have to have the matching source code that was used to create an EXE while you are analyzing a Black Box log file generated by that EXE. Given that development is always ahead of what's in the field, the source on a developer's system never matches the source that was used to create an EXE being run by an end user. Does a developer have to roll back the source code on his/her system to match that of the EXE that generated a log file in order to step through (or back through) that log file?

Answer:

Each TCI file that you create will be build dependant, as are the PDB files for that build. If you would like to do line tracing on the existing build, you should also archive your source code. If you change your source code and re-compile, you cannot get the information from old PDB files because the symbolic information may or may not be there. Thus, it will require you to use the new PDB (or vice versa, old builds require their old PDB). Most of our customers do not have a problem with this. They simply archive the old builds (EXE+PDB+source) and are able to read logs that are made from customers using these executables.

Question 19

Is it true that I can record and trace functions even without source-code?

Answer:

Yes you can. When you record with a Code Level Black Box, you don't require the source code at all. You require the source code when you want to read the Black Box log file and you want to see the source code of the traced functions. You also need the source code when you want to define line tracing for particular functions, or to analyze the log file with line tracing (when you want to see variable values, go step by step forewords and backwards, etc.).

Question 20

How can the Code level Black Box trace system DLLs with parameters and return values using only the DLL itself without debug information?

Answer:

We have a "magic" PDB, which will cause the Black Box to record the parameters of system functions. This will work with all versions of these DLLs (NT/Win9x or different versions), as long as the interface (parameters type) remains the same. The parameters practically never change, because this will cause applications that are running today to stop running.

Question 21

Does the Code Level Black Box record applications in release mode?

Answer:

Yes, the Code Level Black Box can trace and record applications in both debug and release modes.

Question 22

What NT APIs does BugTrapper use for time stamps?

Answer:

BugTrapper uses QueryPerformanceCounter().

Question 23

What do I see if I use a DLL from a 3rd party vendor?

Answer:

You can trace the exported functions from 3rd party DLL without corresponding arguments. In cases when the DLL contains C++ functions, it is with arguments.
go to the topQuestion 25 Does BugTrapper detect both VC++ and Win32 exceptions?
Answer: Yes, BugTrapper supports both. Win32 exceptions are exceptions that are normally considered crashes. This occurs where the O/S kills a program for doing something it shouldn't have been doing. VC++ exceptions are intended exceptions thrown by the programmer (like in a try block piece of code), and could include exceptions caught by the C++ runtime library. These are not real crashes, but are handled by either the program itself or the runtime library. If a WIN32 exception is thrown (AKA- crash), BugTrapper displays it as a crash--No red F. If any other exception is thrown, BugTrapper displays a red F.

Question 24

Is it possible to display the contents of a char* type as a dump of hex values? If so how do I do it?

Answer:

Our hex output option does not work with char* data. If you have a char that is above 255, you will get the hex value for it: example: char* str;str = (char*)malloc(100); strcpy(str, "garbage string");*str = 279;(the value of str will now read "\o35arbage string")You will have to do the conversion yourself for data smaller then 255.

Question 25

When reviewing the contents of string variables (e.g. char strbuf[256];) that have been traced by BugTrapper, it appears that only the first 16 bytes/chars are available. Is this true? If not, is it possible to see the entire buffer? We believe that we are having problems with improperly (not NULL) terminated strings, but we can only see the first 16 bytes of many of the buffers. Can this be changed?

Answer:

Currently, there is a limitation for arrays. They are limited to 16 bytes. If you would like to see the values of your char arrays, the current work around is to assign it to a local variable of type char*. Example:... char strbuf[256]="This is longer than sixteen bytes for sure!";char strbufptr*; .../*watch this line in BugTrapper with the strbufptr traced*/strbufptr = strbuf;

Question 26

When using chars, wchars, and CStrings I sometimes only see the address of the string in the variable trace window and not the string itself. Is there a way I can see the actual contents of the string too? I assume I will have the same problem when looking at pointers to integers, floats, and other variables as well.

Answer:

BugTrapper currently has a third level pointer restriction so you have no direct method of seeing the third level value. The reason for this limitation is similar to why BugTrapper cannot see an entire linked list via one, say head, pointer. It would take up a lot of time (degrade performance of your program's execution time) and would quickly saturate the log buffer to trace down to the end of the linked list (and may be impossible if there are circular lists, etc.). Currently, the only way to be able to see your pointer's value with BugTrapper is to create a local variable in that function and assign it to your char*. This will let you see what value is in your char*.

Question 27

Our application uses all Unicode. When I record our application with the Black Box and use BugTrapper to view it, the best I can do in displaying these variables is to see the first word in hex. Is there any way to display these as Unicode?

Answer:

The great news is that BugTrapper works great with LPWSTR. In order to do this, you should go to the BugTrapper trace options when defining your TCI, and select the advanced tab at the bottom of the screen. This will take you to another dialog box in which you should select "display Unicode strings". Again, this feature works correctly with wchar_t* and LPWSTR. Unfortunately, it does not properly display const wchar_t* or LPCWSTR. When the Code Level Black Box records an application's execution, amongst other things the TCI will specify how to record this information for later display in the BugTrapper console.

Question 28

I'm using BugTrapper to record an OLE Automation out-of-process server. However, when I try to attach, the process is not visible in the Attach dialog. Yet the process is displayed in the Windows NT Task Manager

Answer:

In order to have this process included in the attach dialog you must have the administrator permission. You will see the process in NT task manager but you must have the proper permissions to execute this process in order for it to be included in the attached dialogue.

Question 29

I'm in the Trace Option window and I see the subject line. Once I open up KERNEL32.DLL, why can I select 'GetFileAttributesA/W()', but cannot select 'GetCurrentThread'.

Answer:

Most functions that don't have check bars are inline functions. You can trace inline function in debug build, but you cannot trace them in release build, since they don't exist any more (they are substituted by compiler optimization). In addition, there are few functions in system DLLs that are not allowed to be recorded. Our list of prohibited functions can be found in BugTrapper under 'untr.dat'. Note: This file should not be deleted or modified in any way.

Question 30

How can BugTrapper produce a stack dump for an assertion?

Answer:

Assertions are not really crashes, so you will not see this type of stack display from BugTrapper. If you would like to see which functions caused an assertion, simply put a trace marker for this assertion function. To do this, go to the trace options dialog box and do a search for '_assert'. Once you find it, place a check mark on it to record it. This will ensure that it will be recorded once a function in your application calls an assertion. You should note that this will only work on the debug builds since assertions are not used at all for Release builds.

Question 31

How can I view local variables?

Answer:

Simply trace the required function lines and select the desired local variables.

Question 32

Can I add a command line option to the executable via BugTrapper (without running the executable first and then attaching it)?

Answer:

Yes, use add executable and write your option(s) under Traces Options-Advanced-Program arguments.

Question 33

In the trace detail pane, I see function calls with their arguments and return values. However, I do not see the value of [out] parameters after the function returns, only before it is entered. How can I see this information?

Answer:

If you trace a function then you only see the parameters when you enter the function. Upon return we show the return value. However, you can easily work around this issue by using line tracing. Simply trace the last line in your function, and specify that you want to record the parameters at this point. In order to activate line tracing, right-click on the function in the trace tree, select "locate in trace options", and than check the required lines in the right (source) pane. You can specify which variables to trace for each line at the bottom right pane (there is a clever default).

Question 34

Is there a possibility to partially collapse branches?

Answer:

Yes, in the Trace Tree pane you have a popup menu (right_mouse_click) for any function marked with '+" or "-". One of the menu options is to Collapse/Expand all such functions.

Question 35

Is there a limit to the size of the call stack?

Answer:

There is no limit to the size of the call stack. In the Trace Options you can select which functions you want to record. Also in the Trace Options you can 'Add DLL', and select any functions from your own DLL. In the 'View - Options - Advanced' you can change the default 'Shared memory size' from 1MB to any size (provided you have the disk space).

Question 36

I finished the relevant tracing of my process and want to go on with the execution of my program without being attached to BugTrapper. How can I detach BugTrapper from my program?

Answer:

Easily. You can detach BugTrapper from the process just by removing your application from the list of attached processes.

Question 37

We have a service that we want to record (it starts before user log in), but the Code Level Black Box does not see the startup of the service. The user starting the service has administrative rights and can start the Black Box after the service has started. The tracing seems to work then. Our problem is that it is the startup of the service that we want to trace.

Answer:

The Black Box can catch all applications which are started after the Black Box. This is applicable for Services also. In order to record a service which is launched before log in, you must use the Remote controlled Black Box (Service) and assign dependencies.

Question 38

When I trace my program with the Code Level Black Box, there is a performance impact. Is there anything I can do to reduce this?

Answer:

Each function you trace adds approximately 70 microseconds of overhead time. So if you decide to trace a lot of functions, you will experience some performance degradation. We recommend you trace the functions that are interesting to you; this procedure is called "tuning". For example: If you see a function that repeats often and is of no consequence to the problem you are analyzing, then simply delete it from the trace tree (de-select it from the trace options) or hit the delete key while it is highlighted in the tree trace pane.

Question 39

How many lines can be recorded in a cyclic buffer of 1MB?

Answer:

From 700 to 50,000, depending the number and size of variables of your application.

Question 40

I need to trace functions whose arguments are large objects. I really need to have some 100,000 functions in the trace. How can I increment the size of the cyclic buffer for getting more trace information? Will this influence the performance of my application?

Answer:

The standard 1MB memory buffer allows you to trace around 20,000 lines. In order to increase size of cyclical buffer go to "view", "options", "advanced" tab and change shared memory size. This change will take effect only after restarting BugTrapper or the Black Box. This new buffer size will be stored in the TCI. This change should not affect the performance of your application, unless you have very strong restrictions on the free memory of your computer and your application will have to use swapping. Note if the size of the argument is greater than or equal to 32k, then BugTrapper will not show the argument

Question 41

Does generating my executable in release mode with debug information in PDB format influence the size or performance of my application?

Answer:

In most cases you will have an insignificant increase in size (around 100 bytes), with no influence on performance.

Question 42

What are the components of the Code Level Black Box?

Answer:

The Code Level Black Box is made up of the following components:· Code Level Black Box.· Remote Controlled Black Box. · Remote Controlled Black Box (Service).· Control Center for Remote Controlled Black Boxes.

Question 43

I have the Code Level Black Box running and I am trying to launch the Remote Controlled Black Box but I am receiving an error message. Why?

Answer:

You cannot launch more than one instance of BugTrapper Console or its Black Boxes at the same time. Simply close whichever component you are not currently using and try launching again.

Question 44

Can I automatically install the Code Level Black Box along with my application?

Answer:

Yes. Please contact Mutek at support@Mutek.com for the technical and licensing issues related to this.

Question 45

What do I need at a remote site to record an application?

Answer:

All that is required on a remote machine is the Code Level Black Box and the TCI file that was created from the matching application(s).

Question 46

Can I record multiple copies of an application on different machines that are all writing to a remote database?

Answer:

Yes, start the Code Level Black Box on every machine where the application process is running and create code level trace logs with time information. Make sure that each machine is synchronized as the Black Box takes its time stamp from the local machine. Open the Trace Options window - Advanced - Select Time stamps. This will display the time a function is called and the time it returns. Comparing log files with time information will show when each application is contacting the database.

Question 47

Tracing multiple applications (exe), do we need multiple Black Boxes, or can it be done via one Black Box and one TCI file.

Answer:

A trace must be done with one Black Box and one TCI file where you include all the processes that you want to record.

Question 48

If you have the Code Level Black Box running, will it replace Dr.Watson as your default debugger?

Answer:

No. In previous versions we replaced the default debugger, but with the latest release of BugTrapper and the Code Level Black Box we do not replace the default debugger.

Question 49

I'm trying to use BugTrapper and the Code Level Black Box with a DLL that is dynamically linked to my application. I created the TCI only for this DLL and sent the EXE, DLL and TCI file to the customer where the Black Box is running. I receive an empty Black Box log file ("Myapp started; Myapp finished.") from the customer's site yet there are no error messages. I am sure the DLL was properly loaded and executed. Why am I not receiving any trace information for my DLL?

Answer:

The problem is that you have created a TCI for the debug version of the DLL and then sent the release version to the customer's site. So the TCI does not match to the DLL. You should create the TCI to correspond to the exact image at the customer site. You can also make two different TCIs, one for debug version and one for release.

Question 50

I've been trying out the Code Level Black Box, and it seems that the only way the Black Box can attach itself to a process is if the process is listed as an application in the NT task manager. If you wish to record a process that is only listed in the "Processes Tab" of NT task manager, there is no way to attach the Black Box to it. Is this correct?

Answer:

No, that is not correct. What you can trace are processes listed on the "Process Tab". Please note that if you want to use the Code Level Black Box to perform an online trace on system services, you must log in as the local system administrator or must belong to the local system administrator's group. The same permissions are required in order to perform an off-line trace of a Windows NT service using a log file generated by the Code Level Black Box at a remote site. Attach BugTrapper to the desired process, generate the TCI file and specify the TCI file to the Code Level Black Box. You will see the Code Level Black Box icon blinking, this means that it's tracing.

Question 51

How large is a Black Box log file if I leave the Code Level Black Box tracing my application for several days at the remote site without dumping the buffer to the log file?

Answer:

The Code Level Black Box does not write to the log file unless the application crashes, exits, the Black Box is closed, a manual dump is forced, dump by timer is used or any action caused by a trigger is made to occur. When any of these situations take place, the Black Box will dump the content of the cyclic memory buffer (1MB by default) and the stack to the log file. And each successive write to the log file will be appended to it increasing its size uniformly each time there is a reason to write to the hard drive. If the Code Level Black Box is closed (not minimized), and reopened, a new log file with the same name will overwrite the previously created log file. Please note that the size of the cyclical memory buffer can be changed in the BugTrapper TCI.

Question 52

How does BugTrapper look for PDB files? How can I specify where my PDBs are located, in BugTrapper?

Answer:

Here is how we search for PDBs: BugTrapper looks for the DBG and PDB files in their original places (where they were initially generated), or in the same path as the EXE is. It also looks for them in the system files. The system files are determined as follows: For each of the environment variables _NT_ALT_SYMBOL_PATH, _NT_SYMBOL_PATH and SystemRoot, BugTrapper looks under them (if they are defined) for a directory symbols\exe or symbols\dll for finding debug information of EXEs or DLLs.When you have changed the location of your PDB files, BugTrapper will ask you to provide it with the new location of your PDB files. This will allow you to specify where your PDB files are located. If you are using the Code Level Black Box, you will not need to have your PDB files at the remote site, thus their location is not relevant. If using the Black Box paradigm, the PDB files will be used to open the log file once it is created and there you may specify where they are locally.

Question 53

I build my product from the command line. All .CPP files are compiled into .lib's and then the .lib's are linked into the .exe. I am not using the IDE at all. Can you tell me how to compile the release version in a way that I can still use BugTrapper? My builds are currently outputting both PDB's and DBG's but BugTrapper says, "Cannot find debug information for..." or "Unknown format of..."

Answer:

BugTrapper supports PDB format only. To compile your application with PDB you need to add following flags, for compilation: /Zi (Generate PDB debug info) Or /Z7(Generate C7 compatible) And for link: /debug (Generate debug info) /pdb:"/" (put debug info in PDB file) /pdbtype:con (eliminate separate types) For release builds, we recommend to add to the link: /OPT:REF to make the executable file smaller see: http://www.mv.com/ipusers/robbins/FAQ.html#OPTREF_bug NOTE- BugTrapper will support DBG format but only in cases when it is an intermediate file between the executable and the PDB. Such a situation could occur after using "Rebase Utility".

Question 54

When I've stopped recording, BugTrapper has the PDB for the application locked so I can't rebuild. Is this intentional? When I stop debugging, the PDB is released. When I stop recording in BugTrapper, the PDB isn't released. I have to close BugTrapper.

Answer:

You are correct. When BugTrapper has the PDB loaded, you cannot rebuild your application because the PDB is locked. However, you should note that this is not a solely a BugTrapper issue. The Microsoft PDB API only allows exclusive access to a PDB from one application at a time. Thus, if you try to do this same operation with the debugger, you will experience the same phenomenon. You can also close the current session in BugTrapper by selecting to start a new TCI file. This will clear the executables pane and release the PDB.

Question 55

How can we create a TCI for our DLLs? Our DLL's are used with different applications on different sites so we have no standard .exe file.

Answer:

In order to record your DLLs you must create a dummy EXE with the same name as the actual applications (can even be an empty program, which you have to compile without PDB information). This means that if you want to trace your DLLs and they are possibly used by more than one application, you must have a dummy EXE for each application. Add each dummy EXE and use "Add DLL" in "Trace Options" to add your DLLs and define the trace you want. Save the TCI file. You can then run the Code Level Black Box with this TCI, and it will trace the DLLs. However if you do not know the name of EXE file(s) which will use your DLLs, or you only know some of them, then there is no way to trace the instances of the DLLs that were used by these unknown applications.

Question 56

I have to recompile my sources quite frequently. I would like to save time, and not to rebuild my TCI file each time. How can this be done?

Answer:

Use BTConvText utility (BtConvText.exe). This utility enables to convert *.TCI file to ASCII file *.bct. After you rebuild the executable you can convert it back to TCI. Read BtConvText.doc manual in the same directory.

Question 57

Do the TCI or log files contain symbolic information?

Answer:

No. For application security reasons, the format of these files has been designed in such a way that symbolic information will not be available at remote sites.

Question 58

Can I create a TCI file on a Windows NT machine and then use that file to record on the customer's Windows 95/98 machine?

Answer:

All Black Box and BugTrapper logs are compatible between machines operating on Windows 95/98, WinMe, Windows NT 4.0, and Windows 2000. You will have no problem at all creating and using a TCI on these operating systems.

Question 59

I am using the Code Level Black Box and get the "TCI does not match image" message. What does this mean?

Answer:

The Black Box is probably trying to attach to an executable that is somehow different than the original. This can occur for a few reasons:1. The revision of the executable is different from the one whose trace information is stored in the TCI.2. A secondary application was launched using the same name as the TCI.3. A different mode (debug or release) than the original was used i.e. the TCI was made for debug, but the customer is using release mode.

Question 60

I get the error message "DLL does not match image".

Answer:

The problem is that you are creating a TCI for the debug version and then sending the release version to the customer site. Once the Black Box is launched with the release version, the TCI file will look for the original debug version of the DLL (using the TCI, the Black Box identifies the process according to name and time stamp when compiled). Therefore you should create the TCI to correspond to the exact image at the customer site.

Question 61

What does the error message 'DBG not found' mean?

Answer:

BugTrapper does not search DBG files. Only Microsoft creates their DLLs with DBG files; all other users are interested in exported functions from these DLLs. If this is changed, then all other users will be forced every time to answer redundant question about DBG's location. If you receive this error message, there are 2 Workarounds: 1)Use environment variable _NT_SYMBOL_PATH (and place DBG/PDB in corresponding sub-directory 'symbols'). For example, _NT_SYMBOL_PATH = C:\Dir1; D:\Dir2. Then place your PDB in C:\ Dir1\Symbols or D:\Dir2\Symbols. 2)Place the DBG & PDB in the DLL's directory.

Question 62

When a Black Box log file is loaded from a remote site, I receive an error message that several DLLs (found in System32) have an invalid format.

Answer:

Check that you have the exact same version of DLLs executables on both systems. If they are not exactly the same, then you will not see some traced functions from these DLL's.