Start, restart, close, change the debuggee
Starting a debuggee
Starting a debuggee using the command line
Going to the starting address
Restarting the debuggee
Closing the debuggee
How GoBug closes the debuggee
Changing the debuggee
Adding command line parameters to the debuggee
Debuggee sessions

Starting a debuggee
The open file dialog will appear when you start GoBug. Use this to find the debuggee you want to start with the debugger. You can only start "exe" files (not DLLs since the code in these can only be called by a process which is already running). If you have used GoBug before the previous last ten programs you have started using GoBug will appear in the drop down combo box.

Starting a debuggee using the command line
You can bypass the creation of the open file dialog by specifying a debuggee in the GoBug command line. This enables you to start debugging more quickly. You could make a batch file containing the GoBug command line and run that from an MS-DOS window.
Use the following syntax in the command line:-

GoBug path+filename [parameters] 
Here you provide the debuggee's path and filename. If you do not give an extension, "exe" is assumed. Providing parameters is optional but if they are provided these are assumed to be parameters of the debuggee, so that you can see the debuggee's response to certain command line options.

Going to the starting address
When a program is started by GoBug it is allowed to run to the starting address. This is the entry point for the code which you specified to the linker at compile time (note will some assembler and linker combinations this is done automatically). When loading the debuggee the system carries out some processing, and loads the DLLs required. However, the debuggee itself does not execute any code. For this reason GoBug skips over this process. It would be possible to stop earlier, so that loading of the DLLs could be monitored. Let me know on JG@JGnet.co.uk if this would be useful.

Restarting the debuggee
Choosing "file, restart debuggee" menu item will close the debuggee which is currently open and GoBug will then reload it and go again to the entry point and then stop. This is useful if you want to go back again to the point where an error occurred.

Closing the debuggee
Choosing "file, close debuggee" menu item will close the debuggee which is currently open. Then you can use the file menu to open a new debuggee.

If the debuggee is running it can also close in the normal way. If this happens GoBug displays the following box:-

If you want to view the contents of the panes or otherwise inspect the debuggee before closing GoBug's panes you can do so. When you are finished click on OK to close GoBug's panes, or choose "Restart" to restart the debuggee.
If you close GoBug whilst debugging, the debuggee will close first, then GoBug will close.

How GoBug closes the debuggee
Since the debuggee was started by GoBug, it can also be closed by GoBug. Unless the debuggee closes itself or you close it, GoBug has to close it. GoBug tries several ways to do this, in sequence, and the methods tried are displayed on the status line. After most debug sessions GoBug can close the debuggee cleanly and without problems. However, sometimes these efforts fail. For example it may be that the debuggee has caused an exception. In that case GoBug will if necessary try to jump over the exception so it does not recur during the close process. However that might cause other problems for the debuggee. Or it may be that the debuggee is caught in a continuous loop affecting the messaging process. If the debuggee has more than one thread it is important that all the threads are closed. GoBug tries the following methods to close the debuggee as cleanly as possible:-
1. Sending WM_QUIT to the threads of the debuggee. This works if the debuggee has established (or normally does establish) a message queue unless the messaging process has failed.
2. Causing the debuggee to call ExitProcess. This is done by diverting the debuggee's execution to that API and is used if the debuggee has no message queue or if WM_QUIT has failed.
3. Closing the creator. Here the GoBug thread which created the debuggee is closed, which tells the system to close all child processes too.
4. Calling TerminateProcess. This is not a favoured method because the system is unable to inform any Dlls which may have been loaded into the debuggee's address space. Also if earlier attempts to close have failed it is quite possible that there is some corruption. For this reason GoBug warns you about possible problems in a message box.
In a multi-threaded program GoBug may take longer to close the debuggee than in a single-threaded program, because each thread needs to be dealt with.

Changing the debuggee
Choosing the "file, change debuggee" menu item will close the debuggee which is currently open and permit you to choose another debuggee (or the same one again) using the open file dialog.

Adding command line parameters to the debuggee
You add these in the open file dialog. This may be useful if, for example, you want to test the debuggee's response to certain command line options. You can also add debuggee parameters if you specify the debuggee in GoBug's own command line, thereby bypassing the open file dialog see starting a debuggee using the command line.

Debuggee "sessions"
Gobug keeps a record (in the GoBug ini file) of the last ten debugging "sessions", including what breakpoints were entered and what data, code and symbols were inspected by the user during the session. A "session" is debuggee specific, so if you debug the same program again these records appear as options in the menu items. Note that changing the command line parameters for a particular program will cause a new session to be recorded. However, re-compiling or re-linking the program will not do so. This means you can try to correct an error and then easily find the same breakpoint as before. The record of a breakpoint in the ini file is (if possible) kept by symbol name rather than by address, so that the breakpoint will still be available after re-compiling as long as the symbol name is not altered. However, where the record is kept by address the record may not be useful if the address has moved in the re-compiling process.