This tool appears automatically in the Debugger world, where it is initially set up to look at the normal Cedar environment, which was outloaded to disk when you swapped to the Debugger world. The tool can be created with the "Debug" command. If you give the command with no arguments, it creates a tool for inspecting the environment in which the tool is executing. If you give the command with the name of another machine as argument, it creates a tool for teledebugging that machine. The environment which the tool is looking at is called the tool's "client". Most of the tool is concerned with looking at the parallel processes of the client; there are also a few facilities not related to processes.

At the bottom right corner of the menu are the "Screen" and "Kill" commands. These have no effect if the client is the currently executing environment. In the Debugger world, the "Screen" command swaps back to the client to allow you to look at the client display (for about 20 seconds, or until you press the "swat" key); when teledebugging, thgis causes the machine which is being debugged to show the client's screen. In the Debugger world, the "Kill" command is similar to pressing the boot button; when teledebugging, it is similar to pressing the boot button on the machine which is being debugged. At the bottom left of the menu are "List LoadState" and "List Context". "List LoadState" enumerates the currently loaded configurations in the client. If you type the name of a configuration as the text beside the "Context" button, then click "List Context", it will enumerate the modules in that configuration.

The process facilities are based on the concept of "freezing" a process at some point on its call stack. This means that the process continues execution normally, but when it returns to that point on its call stack, the process will stop executing until it is thawed. Of course, there is the special case where you freeze the process at its current frame, so it stops executing immediately. The DebugTool allows you to freeze and thaw processes, and to look at the frozen frames of processes (even while the rest of the process is still executing). There is no way to look at a process (or part of a process) that isn't frozen. There are four "Freeze" buttons: "All", which freezes all processes at their current frame; "Ready", which freezes all ready processes at their current frame (i.e. processes that aren't suspended for a monitor lock, condition variable wait or fault); "Process" which freezes the process whose number (PSB index) is given in octal as the text beside the "PsbIndex" button on the right of the viewer. Finally, the "Context" button will freeze all processes associated with a perticular configuration or module, freezing them at the boundary of the context. More precisely, "Context" enumerates all processes, and determines every process that has somewhere on its call stack a frame within the specified module or configuration; each such process is frozen at the point where control would return to within the module or configuration; any process currently executing (or waiting or faulted) within the module or configuration stops executing immediately. If you click the RIGHT mouse button on the "Freeze Context" button, then the entire call stack of each such process is frozen.

For each process that is frozen, the DebugTool displays three buttons, labelled with "Adjust", "Thaw", and a description of the process's current state. The state says things like "ready" or "waitingCV" or "pageFault", followed by the name of the frame at which the process is frozen and the priority of the process. There is no way to look at non-frozen frames of the process. The "ready", "waitingCV", etc. are wrapped in parentheses if the process's current frame is not frozen (i.e. if the process is still executing). If you click the LEFT mouse button on the process-state button, DebugTool gives a brief summary of the process's call stack (from the point at which it is frozen). If you click the RIGHT mouse button there, DebugTool will create an action area for that process, which allows you to look at the frozen parts of the call-stack in more detail. The "Thaw" button associated with a frozen process will un-freeze the entire process. If you click the LEFT mouse button on the "Adjust" button, it will change the point at which the process's call-stack is frozen to be the boundary of the module or configuration specified in the text for "Context" at the right of the viewer. Clicking the RIGHT mouse button there will freeze the entire call stack of the process. You can't thaw or adjust a process while it has an action areaproceed the action area first.

If you resume an outloaded client (for example, by proceeding the action that invoked the world-swap debugger) while some processes are frozen, they really are frozen when the client resumes. This can be important when debugging parallel computations, but it can be dangerous. In particular, beware of resuming the client while critical system processes are frozen!

You will find the DebugTool more pleasant if you use the full power of its process enumeration facilities. You should very rarely need to use "Freeze All". Almost always, you know what set of modules or configurations you're debugging; if you freeze just the processes associated with them, DebugTool will do the filtering for you and you won't have so much trouble deciding what process to look at.

There are still numerous bugs. If the Debugger world breaks, however, you still have a chance to look at your outloaded client. If the Debugger world has been invoked by a client and you haven't resumed the client at all (e.g. UserScreen), you can restart the debugger without losing the client outload by booting your Debugger volume with the "W" switch. The Debugger world does this automatically in the situation where it has been inloaded twice. Alternatively, you can reinstall the Debugger world by booting your debugger volume with no switches, in which case after outloading itself the debugger will boot your physical volume.

Just like Cedar, the Debugger world often manages to find the correct symbol table automatically using the version maps. However, this is unlikely to be true for the modules you're debugging. The Debugger world will not automatically look at files on the client volumeyou'll need to fetch them explicitly onto the debugger volume using BringOver, or the the Copy command.