Partager via

Troubleshooting: Debugging a Driver (Windows Embedded CE 6.0)

  • Article

1/6/2010

The following table shows descriptions and resolutions of problems you may encounter while debugging your driver.

Description Resolution

You want to debug or run specific modules, but you do not want to include them or cannot include them in your run-time image.

Establish a debug connection to your platform, and then place the modules in the %_FLATRELEASEDIR% on your host computer.

The terminal emulator on your development workstation is not receiving output from the serial port on your target device.

Ensure that you have the correct connection setting. The following list shows the correct connection settings:

  • Typically 38400 bits per second.
    For more information on receiving messages from the serial port on your target device, see Configuring HyperTerminal for BSPs.
  • 8 data bits.
  • No parity.
  • 1 stop bit.
  • No flow control.

You cannot set breakpoints.

Ensure that your .dll, .pdb, and .map files are in the release directory for your project.

For more information on release directories, see Troubleshooting: Building a Driver.

You can set a breakpoint by modifying the executed code. Breakpoints insert an invalid instruction, and the debugger takes control. You cannot debug a .dll or .exe file that is executing out of flash memory or ROM unless you perform one of the following tasks:

  • Force your code to execute from RAM. One way to do this is to add the compress flag to the section for your module in the .bib file. The system will automatically uncompress your module into RAM before executing its instructions. For more information on .bib files, see Binary Image Builder File.
  • You can move the module to the FILES section of your .bib file. For more information on the FILES section of a .bib file, see FILES Section.
  • If you have target control enabled, you can leave the module out of the image and it will be downloaded from the %_FLATRELEASEDIR% automatically. For more information on target control, see Target Control Window.
  • If hardware debugging support is available for your target device, such as through a JTAG probe, you may be able to debug ROM-based modules without copying them to RAM.

Platform Builder does not recognize your breakpoints.

Ensure that the run-time image is in a break state. If you have a connection to your target device and your run-time image is running, from the Debug menu, choose Break. You can now set breakpoints. You can also set breakpoints before downloading your run-time image to the target device.

If this solution does not work, insert the DebugBreak macro in your source code where you would like execution to stop. This causes a breakpoint exception to occur in the current process so that the calling thread can signal the debugger in all cases.

You want debug messages from system DLLs.

From the Target menu, choose Debug Zones. A list of the currently loaded DLLs appears. Choose the DLL that you want to debug, and then a list of debug zones will appear. Select the debug zones that you want to activate. The debug tab in the output window displays the debug messages.

You can set debug zones under the HKEY_CURRENT_USER\Pegasus\Zones registry key on the development workstation.

You can also set debug zones under the HKEY_LOCAL_MACHINE\DebugZones registry key on the target device. This will work even if you have not enabled target control. Either of these methods allows you to set default values for the debug zones so you can retrieve debug information when the module is loaded for the first time. If you have access to the source code, you can edit the ulZoneMask value in the dpCurSettings data structure contained in the module, and then recompile the source code.

For more information, see Registering Debug Zones.

See Also

Tasks

Troubleshooting a Device Driver

Other Resources