Runs on Windows 9x, ME, NT4, 2000, XP,Vista and Windows7
Runs another Windows program (the "debuggee") in closely controlled conditions so that you can find bugs.
Gets the debuggee's symbols (and those of its Dlls) either as embedded in
the file (CodeView or
COFF format) or from .dbg file or .pdb file. Can also get symbols from most
.map files if necessary.
Displays code and data labels in disassembly
even if they are in Unicode
(as can be done using the "Go" tools)
Single steps through the debuggee's code, that is, the processor
executes a single instruction at a time, which you can watch in the codepane
Meanwhile you can watch how this affects the debuggee's registers and
flags
and how it affects the stack by reference to esp
or by reference to ebp
enabling you to view stack parameters and local data.
You can execute and jump over procedure calls instead of single-stepping
into them.
There is a comprehensive log which works on three levels:-
The main logpane displays major events in the debuggee, exceptions,
api errors and user input
The event/message logpane displays other debuggee events such as changes
to windows and threads. It also displays all messages with details of the
parameters, source and destination in the sequence in which they occurred.
The instruction logpane displays each instruction actually executed
and also the changes to the main registers after each execution
The depth of the log levels which are recorded depends on how you run
the debuggee. If you single-step through the code (using the F5 or F6 key)
or run the debuggee fully trapped (using the F7 key) all three levels are
recorded. If you run the code without the trap (using the F8 key), only
the event/message pane is recorded. If you run the debuggee in the
"background" (using the F9 key) then unless there is an exception no log
events will be recorded.
The sequential log is a separate logpane which shows all events
and messages in abbreviated form in strict sequence
This can be viewed while you are single stepping or carrying out debuggee
actions, so you can see the events and messages generated.
You can view the depth and position of current execution using the stacktrace
This is useful when single-stepping or when a breakpoint has been reached, or an exception or API error
has occurred. The stacktrace for each thread can be viewed
Exceptions cause GoBug to come into the foreground and the debuggee freezes.
The exception is reported in the log
At your leisure you can examine the internals of the processor and of the debuggee
to see what happened, and at your option the code which caused the exception can be jumped over or other action taken
If your code gets into an infinite loops you can try to break into it using
the hot key or using the "traffic light thread control".
Threads can be viewed and controlled individually using the
thread buttons
and the "traffic light thread control"
You can single-step through more than one thread to see how Windows
switches processor time, memory, stack and register values between the threads.
You can set various types of breakpoints. This allows you to carry out
tests at the breakpoint or single step from there to test that particular
part of your code. You can set code breakpoints (run to a particular
code address, run to particular procedure, run to end of the current
procedure, or run to a new thread) or message breakpoints
(run to any message, run to a particular message, run to a particular type
of message, or run to a message to a particular window procedure).
When the break occurs GoBug comes into the foreground and the debuggee is frozen.
Exceptions in the debuggee always cause a break.
You can set GoBug to break on API errors in the debuggee.
You can set GoBug to break on messages arriving in a window procedure (the "single-step
message break").
You can change the (ordinary) register values or flags at run-time to
correct errors or to check your code. You can also change the contents
of the stack, so you can test sending different parameters to the APIs.
You can view and change the contents of
the MMX registers
the floating point registers
the 3DNow! registers
the XMM integer registers
the SSE floating point registers
and the SSE2 floating point registers
You can search memory for specific strings and values and promenade
memory generally, and then view the results
or you can view comprehensive information about the debuggee and its Dlls
as loaded
You can inspect all accessible areas as code by using a code inspector
and you can view individual opcodes in the codepane and in code inspectors.
Data inspectors can show data by area
or by symbol
Code and data inspectors can be created in various ways, for example by
reference to symbols
, addresses within the loaded executables
, or by register value.
You can set up special symbol inspectors allowing you to view only those
symbols which are of interest at any one time
You can view and extract the debuggee's and its Dll's resources
GoBug has a full keyboard and mouse interface. It can be controlled using the main menu or
shortcut keys.
Also context menus help you quickly to reach the function you need
All or any information in GoBug's panes and windows can be dumped to a file (ANSI or Unicode) and
can also be printed. This includes a partial or full disassembly of the debuggee.
GoBug properly displays Unicode symbols, section names and resource names and deals properly
with Unicode file names (you can use Unicode in this way using the
"Go" tools).
GoBug has a full and comprehensive help file with sensible and useful index.
This can be viewed from my free web site.
It also comes with its own demo program, Testbug (this is also available free).
Your licence includes a right to all Win32 GoBug Version 2.xx updates and to support by e-mail.
GoBug Version 2.03.01
(mouseover the flying eyes for screenshots)
