Setting the Active Debugger Process

After you complete the debugging preparations , there is one final concept that you should understand in order to debug an application properly. When you look at the Debug Location toolbar after starting any application, you can see that the Program, Thread, and Stack Frame areas are grayed-out. This signifies that no process is currently active in the debugger. The concept of an active debug process is important. The debugger can handle multiple processes simultaneously , but only a single process is actually active within the debugger at any one time. In addition, unless the debugger is actually stopped on a breakpoint, there is no active debug process. This lack of an active debug process is shown by the fact that the Debug Location toolbar has all of its areas grayed-out.

Once the application is running, you can manually set the active debugger process by using the Break All option on the Debug menu or by selecting the relevant process in the Processes window and clicking the Break button. This is the manual equivalent of setting a breakpoint and performing a program action that causes the breakpoint to be triggered.

To break into an application automatically, you add a breakpoint in the program's Source or Disassembly window and then perform a program action that causes this breakpoint to be hit. This program containing the breakpoint then becomes the active debug process. If you examine the Debug Location toolbar of a program that's hit a breakpoint, you'll see that it's no longer grayed-out ”its Program drop-down shows the name of the executable and its process ID, the Thread drop-down shows the ID of the program's active thread, and the Stack Frame drop-down shows the current call stack.