Debugging a Program

To debug a Windows CE program, the program must be running in either an emulated or remote Windows CE environment. Under emulation, the Windows CE debugging process is similar to the Visual C++ debugging process. However, to debug a Windows CE program, the program is copied to the object store (during the build process) and executed in a simulated Windows CE environment on your desktop computer.

The remote debugging model varies, depending on the connection between the remote device and the desktop computer. The Windows CE Toolkit for Visual C++ 5.0 builds all binaries on the desktop computer and then downloads the binaries to the remote device.

To prepare to debug a program on a remote device

Make sure the remote device is properly connected to the desktop computer.
On the Tools menu, click Remote Connection Server or any of the remote tools to establish a connection to the remote device.
On the Build menu, click either Set Active Configuration or Configurations, and then click the Debug option for the platform you want to target.
On the Build menu, click Debugger Remote Connection.
In the Remote Connection dialog box, select a target platform from the Platform drop-down combo box and click OK.
On the Build menu, click Update Remote Output File to load your program onto the remote device.

Note If you enable Always Download on the Build menu, your program will be automatically loaded onto the remote device during the build process.

To debug on a remote device

On the Build menu, click Start Debug.
Select Step Into if you want the debugger to stop at the WinMain entry point
-or-
select Go if you want the debugger to stop only at soft or hard breakpoints.
The debug subsystem will download and initialize on the device, and a series of loads will run until a breakpoint is hit. The integrated debugger is then connected to the device and can control the debug session.
Perform the debug procedure.
To exit safely, when the debugger is stopped at a breakpoint, click Stop Debugging on the Build menu.
When you exit safely, the debug cycle of building, downloading, debugging, and exiting can go on indefinitely.

Note If you stop the debugger when it is not at a breakpoint, you may leave the remote device in an undetermined state. The debugger can only unload the debug subsystem when the device is at a breakpoint.

Remote debugging differs from native debugging in the following ways:

All exceptions from any process on the target machine are caught by the debugger. By default, the debugger stops when it catches an exception.
The project directory, and any project subdirectories, are at the top of the remote symbol mapping order.
Debug\Stop debugging behavior is continued on exit.
There is no asynchronous communications with the target — no asynchronous stop, breakpoints, memory updates, etc.
There is no support for single button stepping out of routines. An alternative is to set a breakpoint or run to cursor on the call stack routine calling the current routine.

Tips You can enable and disable breakpoints while the debugger is running. The procedure is the same if you set the breakpoints before debugging. Use the hand icon to set or remove a breakpoint where the cursor is positioned, or click Breakpoints on the Edit menu, and specify the line number.

To optimize performance while single-stepping, close any unnecessary windows in the debugger.

Click Step Into if you have not set a breakpoint in your executable. If you start debugging using Go, and no breakpoints are set, you may lose control of the target device and may have to restart it.

Verify that the host machine and the remote device are connected by checking for a connection icon in the icon tray of both taskbars.

If your remote device loses its connection during debugging, there are several ways to attempt reconnection: unplug and replug the PC-link, run Repllog.exe on the remote device, or cycle its power.

If your workspace contains both EXE and DLL projects, select EXE as the active project when debugging.