Windows CE 6 and Visual Studio 2008 Debugging Gotchas

Getting remote debugging to work with Visual Studio 2008 and Windows Embedded CE 6 (or whatever it’s called today) can be a frustrating experience. Here are a few tips that help to avoid various gotchas.

First, if you’re going to debug with Visual Studio 2008, you’ll probably need new versions of ConManClient2.exe and cmaccept.exe, together with various DLLs, installed on your device. The versions of these tools already installed on the device are probably meant to be used with Visual Studio 2005. Visual Studio 2008 requires newer versions of these, otherwise an attempt to connect to the device will fail with an error message telling that the ConManClient2 on the device is not compatible. These files can be found in C:\Program Files\Common Files\Microsoft Shared\CoreCon\1.0\Target\wce400\<arch>. Note that you might also have a C:\Program Files\Common Files\Microsoft Shared\CoreCon\5.01\bin\target directory. However, the files from that directory won’t work. Copy them to your device (e.g., by FTP) or put them onto a USB drive. Once the files are on your device, you’ll need to start ConManClient2 and cmaccept. An older version of ConManClient2 might already be running on your device, so stop it first, by running ClientShutdown.exe. I use a script to do this:

rem StartDebug.cmd
"\Hard Disk\ClientShutDown.exe"
start "\Hard Disk\ConManClient2.exe"
echo "Press return to launch cmaccept"
time
"\Hard Disk\cmaccept.exe"

Replace “Hard Disk” with the name of the folder where the executables are located. Note the call to time — it’s only purpose is to delay starting cmaccept.exe until ConManClient2 in ready. Normally, one would use the pause command for this purpose, but, funnily, on Windows CE, pause simply writes “Press any key to continue…” and then immediately continues, without waiting for any key to be pressed… Has anyone filed a bug report on this?

Once cmaccept runs, you should be able to connect to the device, provided the device connection has been set up properly (Tools > Options > Device Tools > Devices).

Next thing you might notice is that you can start remote debugging from within Visual Studio, but your breakpoints do not work. Also, you won’t see any source code when you break execution (Debug > Break All). In this case, check your linker settings in the project properties. Make sure that under Linker > Advanced, the setting Randomized Base Address is set to Disable Image Randomization (/DYNAMICBASE:NO). Sounds logical, doesn’t it. Once you’ve found the setting.

Happy remote debugging!