A common problem that developers run into is that when they change the build from debug to release, their application or dll no longer works, or doesn’t run at all. Here are some of the causes that I can think of:
1.       The application or driver wasn’t actually in the OS image. This happens a lot because of a handy feature of KITL and the CEShell, which is the Release folder. The Release folder is a folder on the device which is linked to the _FLATRELEASEDIR on your development workstation. When a dll or exe is needed by the system, it looks in the Release folder if it can’t be found in the Windows folder. So even if you didn’t add the file to your bib file, it will run – until you no longer have a Release folder. Check your ce.bib to see if your file is listed there, if not you need to add it to your bib file.
2.       Unitialized variable. When you compile for debug, variables will be automatically initialized, but for optimization in a release build that is removed.
3.       Timing.  Remember all those debug messages that you had? They take time and slow down the boot process and may even change the order of operations.
4.    Optimization.  With thanks to Valter Minute for pointing this one out, the following loop will work in debug, but fail in a retail build:
MY_DEVICE_REGS* regs=(MY_DEVICE_REGS* )MmMapIoSpace or other mapping function

regs->myreg|=0x1; // set the bit

while (regs->myreg & 0x01); // wait until it has been cleared

This while loop will be optimized out because the optimizer sees no reason to for the loop to run.  The solution is to add "volatile" to the definition of regs:

volatile MY_DEVICE_REGS* regs=(MY_DEVICE_REGS* )MmMapIoSpace or other mapping function

Adding volatile to the definition tells the compiler that the data pointed to by regs will change outside of the code's control.  Therefore, any reference to the data should not be optimized.

It is important to test the Release build early and often.

Copyright © 2008 – Bruce Eitman
All Rights Reserved