Trace options

You can control how much information to gather during each call selected for tracing. To make your choices, select Tools - Options in the main menu, or click on this icon in the toolbar:

The following window will appear:

Explanation of options:

• Enable tracing: use this option to turn tracing on or off.
• Show Exception Info: enable this option if you want to know about the exceptions triggered in case of abnormal exit.
• Enable timestamps: use this option of you want to measure the execution time of the traced calls. You can also access this option using this toolbar icon:
  

• Call OutputDebugString(): enable this option if you want to see the result of calling OutputDebugString() in the Windows kernel.

• Call GetLastError(): with this option enabeld, Auto Debug will call the Windows kernel function GetLastError() on completion of every call it traces. It will allow you to see whether any non-fatal system errors were encountered during a call. If GetLastError() returns a non-zero value, Auto Debug will automatically call FormatMessage() to display the text of the error message. This behavior is similar to that of the Visual C debugger invoked with the err,hr- option. This screen shows how a call to GetLastError() will appear in Auto Debug:

• CPU Registers : include the contents of the CPU registers before and after each call. (this option is only available to registered users)
• Presumed Number of Arguments: the number of machine words in the stack to remember. There is a performance benefit for selecting a smaller number, so if you do not expect many arguments, use a smaller number. Take into account the size of each argument: for example, if you expect a double-precision floating-point argument, which occupies two machine words in a 32-bit system, it will use 2 places in the stack (that is, two resumed arguments, so you will need to increment this number by 1 for each double-word argument. (this number is limited to 5 in the trial version)
• Presumed Parameter Length: specifies how much memory to dump at the addresses pointed to by pointer-arguments. (this option is only available to registered users)

Presumed arguments explained:

Since we cannot always know (for want of source code, in a typical scenario) how many arguments each function has, and in the case of pointer arguments, how large is the memory area holding the data addressed by those arguments, we have to make uniform assumptions about these numbers.

For example, if you set the number of arguments to five, while most of the functions you trace have a smaller number of arguments (or, to be precise, their arguments occupy less than five positions in the stack), Auto Debug will save the first fvie positions in the stack before and after each call, but it will not tell you which of these five values (param[0 .. 4]) are the true argument values. You will have to figure it out based on the function prototype (which Audo Debug does get right in most cases). So if a function has one argument of type long, and if it uses the typical C calling convention, you will find that argument's value in param[1], while all other param[] entries will have nonsense values in them.

If the argument is of type int (or short), it will occupy only the two least significant bytes in param[1], while the senior two bytes may hold nonsense values.

You may run into a function that uses eight arguments, and if the number of presumed arguments is set to five, the last three will not be registered. In that case, if those arguments are important to know, you can increase this number and re-run the trace, but it is always better to start with a smaller number and increase it as necessary, because there is a performance penalty associated with a large number of arguments. It is possible to run out of memory with this number set too high.

Similarly, if you expect certain arguments to point to strings or to other structures in memory, anticipate how many bytes of memory to dump for each argument, if you want to read such data. Auto Debug has no way of knowing the size of the data, so once again, you will have to presume a certain size that will allow you to read (or at least recognize) most such objects, then increase it in subsequent runs if it is not sufficient. Like with the number of arguments, there is a risk of running out of memory with this number set too high.