Visual C++ Vers 2.0 README.WRI, Part 4 Integrated Debugger

The information in this article applies to:

• Microsoft Visual C++, 32-bit Edition, version 2.0 on the following platform: x86

SUMMARY

The following is based on the Visual C++ version 2.0 README.WRI file:

Applications with Multibyte-Character Names

If you are using Visual C++ version 2.0 with the Japanese edition of Windows NT 3.1, you can name development environment projects using multibyte characters, thus creating an executable file with a name that contains multibyte characters. However, if your project or path contains multibyte characters, you cannot debug this executable using the Japanese edition of Windows NT version 3.1.

Debugging Lines with Multiple Statements or Instructions

A source statement such as:

x=1; y=7; Z=3;

contains multiple statements. The debugger treats each source code line as a unit, so you cannot step into or set a breakpoint on more than one statement per line. Thus, executing the Step Over command in the source window steps over the whole source line, and executing Toggle Breakpoint sets a breakpoint only on the first instruction of the first statement.

For example, the statement:

for ( x=0; x<10; x++       ) {

You can use the Disassembly window to work around this behavior. If you open and set focus to the Disassembly window, it displays the instructions that the source line generates. Thus, you can set a conditional breakpoint at the appropriate instruction, for example, on the comparison (x<10;). Also, stepping in assembly mode (with the focus in the Disassembly window) allows stepping through the individual instructions that make up a source code line.

It is possible to break statements so that you have one statement per source line. However, if a single statement is broken over multiple lines, you can set breakpoints only on the starting or ending line of the statement.

Debugging Optimized Code

When the compiler optimizes code, it may reposition or reorganize some lines for more efficient execution. These changes can prevent the debugger from recognizing the corresponding lines of source code, making it difficult to debug the optimized code. If you are debugging during application development and you do not want to debug optimized code, you can use one of the following methods:

• Select the Win32 Debug target after you create a new project. Then build and debug the Debug target until you are ready to build a Win32 Release target. This is the preferred method for debugging code that you will optimize later.

  -or-

• Select the "Disable (Debug)" switch in the Optimizations box on the C/C++ tab of the Project Settings dialog box, or use the /Od compiler option on the command line. You can enable optimizations after you finish debugging.

  -or-

• Use the Disassembly window to debug the optimized code.

Remote Debugging Under Win32s

If you cannot run a remote-debugging session in a Win32s environment, you can check conditions such as the following:

• Confirm that there is bidirectional communication on the serial line by using an application such as TERMINAL.EXE.
• Check for a serial port conflict caused by using the MOUSE.SYS device driver in CONFIG.SYS with a serial mouse. Unplugging the mouse may not solve the problem.

Using Data Breakpoints While Running the Debuggee

While the debuggee is running, you cannot enable or set data breakpoints. The following kinds of breakpoints in the Breakpoints dialog box are disabled while the debuggee is running:

• Break when Expression is True.
• Break when Expression has Changed.

• Break at Location when Expression is True.

  -or-

• Break at Location when Expression has Changed.

Using Just-In-Time Debugging or Dr. Watson

You can use Visual C++ "just-in-time" (JIT) debugging or the Dr. Watson utility provided with Windows NT when an unrecoverable error occurs in your application.

The JIT debugging capability of the Visual C++ debugger provides more functionality than Dr. Watson. When your program terminates abnormally, Dr. Watson merely creates a static log of the state of your application at the time of the fault, and terminates the application. With Dr. Watson, you cannot debug your application while it is running.

The Visual C++ debugger provides powerful debugging features and enables you to find and fix problems while your program is still active. For more information, see "Enabling Just-In-Time Debugging" in Chapter 14 of the Visual C++ User's Guide.

However, if you need to use Dr. Watson and you want Dr. Watson's log files to contain the same level of information as they do for Windows NT debug executable files generated by Visual C++ version 1.1, then you must disable the Program Database feature.

To disable the Program Database feature:

1. From the Project Menu, choose Settings.

2. In the Project Settings dialog box, select the Link tab.

3. In the Category box, select Customize.

4. Clear the Use Program Database check box.

Using Microsoft Macro Assembler 6.11

The Visual C++ version 2.0 debugger's Disassembly window may not display lines correctly if you are assembling some modules of your Visual C++ application with Microsoft Macro Assembler (MASM) version 6.11 and using linker version 2.50. To correct this problem, you should upgrade to the MASM version 6.11a maintenance release and use the /COFF option on the ML command line.

The MASM version 6.11a maintenance release is available on the Microsoft Download Service (MSDL), phone 206-936-6735.