WinCE: Debug version works, Release version crashes while reading from stream device driver

Question

i am creating a Windows CE 6.0 in Visual Studio 2005 with Platform builder. I integrated a stream device driver (via USB HID). I also have a small application that opens a connection to the device and reads data from it. When i build a Debug-Version of this Windows CE 6.0 and debug it on the device i can start the application and the communication to the device works fine. Now i build a Release-Version (no changes of Sources!) of the Windows CE 6.0, run it on the device and start the application on the device. When i try to read data from the device by ReadFile(), (i guess this calls XXX_Read() from the stream driver) my windows crashes and reboots. Its too bad, because i cant debug the CE where the windows exactly crashes... (because it does not crash in debug version ;).

What are the differences between Debug and Release Version of WinCE 6? Does anyone have a hint at which part of the Stream Device driver i need to have a closer look to solve this problem? I know that in Debug/Release the Project settings are not adopted. But i cant think of any setting that may influence the stream device driver.

Regards

Answer 1

One thing you could do is to setup Dr. Watson so that you can generate a KDMP file when the crash occurs, then you can do a post-mortem debug analysis with the KDMP file to see where the crash is happening. See the docs to get more info on setting up Dr Watson on WinCE 6.0.

Once you have generated the crash dump file (*.KDMP), you can use Visual Studio 2005 to open the KDMP file (File | Open Project/Solution). Once it's loaded, use the Target | Attach device menu option to start the post-mortem debug session (Note that you are virtually "attaching" to the device via the KDMP file, you do not need to physically access the target device while post-mortem debugging)

Answer 2

You can also leave KITL and Kernel debugger enabled in your release image. When you debug release code you will experience some strange behaviours (code not executed in order or multiple instructions executed in a single step, some variables can't be watched because they are stored into registers etc.), but you should be able to understand where your system crashes. If you have a watchdog this may be enabled only in release builds and that could explain the reboot.

Answer 3

The big difference between Release and Debug is that in a Debug build of code all variables get initialized to zero. In Release they do not get initialized at all and therefore often can end up with whatever non-zero garbage was in the storage location of the variable when it was allocated.

This is often a problem if you're creating pointers in your code and then checking them against NULL. A Debug build will tell you the pointer is NULL because it got initialized to zero. In Release it ends up non-zero, then you try dereferencing the garbage in the pointer and it causes an access violation crash.

The moral of the story: always, always initialize your variables in code. ZeroMemory/memset is your friend.