Single-step, trace, jump over and run
Single-step (trace into) (F5)
Single-step into Windows code
Single-step and animate (Ctrl-F5)
Single-step (jump over) (F6)
Run/trap/hook/full log (F7)
Run/hook/part log (F8)
Run in the background (F9)
Using the mouse instead of the keys to change the action
Using the traffic light control to change the action

Single-step (trace into) (F5)
Provided the codepane is "active" (not looking grey), and provided GoBug has the keyboard focus, you can single-step by pressing F5. Single-stepping performs one execution of the processor only. The results appear in GoBug's panes. The current position of the EIP register, that is the current instruction place, is shown in the codepane (large arrow). If F5 is pressed at a "CALL" instruction processing will continue at the procedure which is being called. That is to say the instruction place will go trace into the CALL. If F5 is pressed at a "JMP" instruction, then processing will continue to the destination of the jump. If F5 is pressed at a conditional jump instruction (for example, JZ, JNZ JC), then processing may jump with the instruction or may not do so, depending on the state of the flags. The EIP pointer arrow will change direction and colour to show what will happen. When single-stepping, GoBug makes a full log of events, messages, executed instructions and register values. The events and messages are logged using a hook which is inserted in the debuggee's context. The executed instructions are logged when the debuggee enters the debug loop. You have then view the log to see a history of the debuggee's actions. See more about the log.

Single-step into Windows code
Pressing F5 when the instruction is at a CALL to a Windows API and then tracing into the API may cause problems. In Windows 9x and ME, there is a special code stub which throws out any debugger trying to single-step into the code. GoBug gets round this stub (if F5 is pressed) by replacing the code at the appropriate place in the stub. However, the fact is that some Windows 9x and ME Dlls check continuously whether they are being debugged. If so, they throw the debugger out, usually by calling ExitProcess on behalf of the debuggee (terminating it). In addition to this some Dlls thunk down to Win16 code. This will be executed, but does not appear properly in GoBug's codepane. Because of these difficulties in Windows 9x and ME GoBug shows a warning dialog before you enter a system Dll.
Windows NT/2000/XP has no special code stub and usually there is no problem single-stepping through the system code on thise platforms.
However, all the Windows Dlls are written in high level language (not assembler) so that there is a great deal of "baggage" and unecessary code in these Dlls making them very difficult to read. So although you can single-step through Windows code, you may find it a pointless exercise. GoBug is designed to debug your code not that of others.

Single-step and animate
Pressing Crtl and F5 causes the process to "animate". This is equivalent to you pressing F5 (after a slight delay) every time the debuggee comes into the debug loop. All CALLs are traced into, except for the APIs. Animate is useful if you want to watch quick progress to the point of an error in your program. Clicking anywhere in the main window or pressing any key when GoBug has the focus will stop the animation.

Single-step (jump over) (F6)
Provided the codepane is "active" (not looking grey), and provided GoBug has the keyboard focus, you can jump-over a CALL and some other instructions by pressing F6. When you jump over a CALL instruction you don't single-step in the called procedure but continue single-stepping the other side of it. The called procedure will be executed in full, however. You will usually be informed in the codepane and in the log about API errors within the called procedure, but there will be no accurate details of the error. Exceptions, however, will stop the debuggee within the CALL. When you jump over a CALL, GoBug does not log the instructions carried out inside the CALL. However it does log events and messages occurring inside the CALL. Windows calls ought to be jumped over using F6 to avoid getting into Windows code, which may interrupt the debugging process (see above). Other instructions which are jumped over using F6 are the "repeat" instructions which use REP, REPZ or REPNZ. Again these are executed in full, but are not logged. Note that you cannot use F6 to jump over a LOOP instruction. This is because, depending on the code, there might be another exit from the loop. Instead, you can set a code breakpoint at the expected loop exit point and press F9, which will have the same effect.

Run/trap/hook/full log (F7)
This mode permits the debuggee to execute instructions continuously, and there is no need to press a key each time. The debuggee will appear to be running normally, although more slowly than usual. What happens here is that each instruction comes into GoBug's debug loop and as the instruction leaves the loop, GoBug sets the "trap" flag in the processor so that the next instruction comes back to the loop. This enables each instruction to be fully logged in this mode. Also the GoBug hook is set in the debuggee's context so that all events and messages are also logged. The F7 mode therefore allows you to run the program until a fault condition occurs and then you can view the debuggee's history in the log. When in F7 mode, the code is not followed into the system Dlls in shared memory. This ensures there are no problems arising from Windows' objection to this. However, sometimes such Dlls are loaded not in shared memory but in the debuggee's own context. In those cases F7 action will go into the Dlls, and the debuggee will appear to run much more slowly than usual.

Run/hook/part log (F8)
This mode permits the debuggee to execute instructions continuously, but it will run much faster than F7 mode because the trap flag is released. The instructions are not logged, but messages and events are logged because the hook is set in the debuggee's context. In F8 mode the debuggee runs more quickly than in F7 mode, but slower than in F9 mode. F8 mode is useful if you are not interested in view the instruction log, but you do need the message log. Note that since the trap flag is released in this mode it may be difficult to get execution back into the debug loop. To achieve this you may need to set a breakpoint, try to regain control of the wayward thread or restart the debuggee.

Run in the background (F9)
In F9 mode, the debuggee runs so quickly you cannot tell that it is being debugged. Instructions do not go into the debug loop because the trap flag is released. The hook is also released so there is no log of the events and messages either. If left in this mode, the debuggee would run quite normally until an exception occurred (when GoBug then takes over) or until closure. You would use the F9 mode if you wanted to run the debuggee normally until an exception occurred. Note that since the trap flag is released in this mode it may be difficult to get execution back into the debug loop. To achieve this you may need to set a breakpoint, try to regain control of the wayward thread or restart the debuggee.

Using the mouse instead of the keys to change the action
You can use the "action" menu to do this.

Using the traffic light control to change the action
Click on the traffic light button on the toolbar (also accessible from the "action" menu or by pressing Crtl-T) and then click on the appropriate large radio button controls. Press "Apply" to carry out the change or "Cancel" to do nothing.