Debugging using the log
The log as a debugging tool
Continuing until exception then viewing log
Animating over a code fragment then viewing log
Checking messages
Avoiding duplication
Checking thread creation and termination
Viewing thread interaction
Checking loading and unloading of Dlls
Checking for API errors
Sending the log a string

The log as a debugging tool
The log is a valuable tool which allows you freedom to continue the debuggee until something goes wrong and then to view what happened in the log. When using GoBug in this way you may find it easier to make Gobug "on top". This will provide easier access to the log when you want to view it. If you are using the sequential log this can also be made "on top". More about GoBug "on top". There are some examples of how to use the GoBug log in this helpfile.

Continuing until exception and then viewing the log
When an exception occurs, GoBug always breaks and the log will show information about the exception:

Here on the first line of the log is the exception type, the eip where the exception occurred and the thread. On the second line is the instruction which caused the exception and the function in which the exception occurred (if known). The values of the main registers immediately before the exception then follows.
To make best use of the log, you will need to decide what action to use until the exception. You can see that the exception details in the log are little more than is available anyway in the panes when GoBug breaks upon an exception. It is a snapshot of the situation immediately before the exception. However if you have single-stepped to the exception, or used F7 to run and log or Crtl-F5 to animate to it, then there will be much more information available in the log than in the ordinary panes as to what caused the exception. This is because the log then shows the history of execution leading up to the exception. This can be useful. Suppose for example that there is an exception in an oft-called procedure. You would probably need to know what called the procedure in order to identify the cause of the exception. This can be seen from the log but not from the ordinary panes.

Here the user has scrolled back the log by one line and is ready to see what led up to the exception by clicking on the "plus" box just before the exception.
For more about exceptions see exceptions caused by the debuggee.

Animating over a code fragment then viewing the log
Animating (using Crtl-F5) is a convenient way to obtain a record of execution over a section of suspect code, or code whose execution you wish to check. Set a breakpoint at the beginning of the code fragment, and press Crtl-F5. Watch the codepane until execution has reached the end of the code fragment. Press F5 to stop animating. View the log.

Checking messages
Understanding the messages and how they are used by the system is central to Windows programming and you can follow their sequence in the event/message log pane and also in the sequential log. For example you may want to adjust the size and position of a subsidiary window when its owner is resized by the user but you have yet to decide upon which message you should do this. The action of moving or resizing a window results in a whole series of messages and you can follow all these in the log. The simplest way is to press F8 when the debuggee starts. This allows the debuggee to run, but the hooks are retained so that GoBug can log the messages. See .. view messages in the event/message log pane, or in the sequential log pane.

Avoiding duplication
Being able to monitor the sequence of messages to all your windows means you can check against duplication. It sometimes happens even in the best planned code, that unexpectedly the same message may be sent by the system and processed by your window procedure a second time when this is not necessary. This might occur for example if you code for the refreshment of a window on the happening of any event, but in fact the system does this automatically.

Checking thread creation and termination
The log shows whenever a thread is made and whenever it is terminated (the termination code is also shown). In any multi-threaded program it is a good idea to check that this occurs properly in all circumstances, since you do not want your program to continue threads which are no longer being used!

Viewing thread interaction
The log allows you to view how the system allocates messages and processor time to the individual threads in your program. You can watch this when you single-step, but by using F7 action (run/hook/trap/full log), you can view this in the log in more realistic circumstances. Understanding this will help to ensure you are not misled by preconceptions about thread timing, and will act as a reminder that each thread of your program must be able to act independently.

Checking loading and unloading of Dlls
When a Dll (or Exe for that matter) is loaded into, or unloaded from, the address space of the debuggee, this will appear in the log. Note that the Dll is not necessary actually written to another part of memory in this process. If it is already in use by another application it will already be in memory. In that case, the system simply provides that the Dll can be read from, and its data section written to, using a virtual address in the debuggee's own address space.

Checking for API errors
Details of API errors are kept in the log and shown in all logpanes. For more about API errors see API errors.

Sending the log a string
You can arrange for the debuggee to call the API OutputDebugString on the happening of an event in the debuggee. This string will appear in the log (in all log panes). This is useful if you want to monitor something in the debuggee but you do not want to write to the screen on the happening of the event. This might be, for example, because the event you are monitoring involves a screen paint which will be interfered with if you use a tester window. For more about tester windows see Add a visible tester to your code at the point of error.