A good explanation about why checked build?
Don Burn: ...the checked build of Windows when they pry it from my cold dead workstation.
This artical is abstracted from?WHDC website by Don.
The checked build of Windows is the Rodney Dangerfield of Redmond, "It don't get no respect," even from many people in Microsoft. To illustrate this, install the checked build on a system and there is a good chance you will assert in a popular Ethernet card's NDIS miniport driver. This bug has been there for many years, but since running clean on a checked build is not required by WHQL, the bug has not been fixed.
Even many people who use it will argue that they do not need all of it, and use tricks to install only the HAL and kernel from the checked build. Yes, using the partial checked build can be a useful technique, but the user is missing much of the power of the system.
Nonetheless, the checked build is one of the most powerful tools available to a developer. First, there are thousands of ASSERT statements in Windows that will only be active with the checked build. The driver verifier does not test most of these assertions so you need the checked build. If a piece of software (be it a driver or an application) cannot run cleanly through all these assertions, then something is wrong. In my last ten years working with Windows, every major vendor I have encountered has shipped system software that fails assertions on the checked build. Imagine how reliable things would be if all these asserts had been fixed before shipment.
Assertions are only one reason to use the checked build. Just as important is the large amount of debug information that the checked build can display. Microsoft has an excellent knowledge base article Howto: Enable Verbose Debug Tracing in Various Drivers and Subsystems that shows how to get debug prints that will help diagnose many problems. Almost all of this information requires the checked build since it uses DbgPrintEx. Even the knowledge base article does not tell the whole story: look up DPFLTR_TYPE in the wdm.h or ntddk.h and you will find that there are 93 different component Id's whose diagnostic prints can be enabled.
So grab a copy of the checked build, and use it fully before you ship a product. Consider complaining the next time you can't get the checked build of a beta drop from Microsoft. Finally, if you hit an assertion in another vendor's product, file a bug. In the end, the system you make more reliable may be your own.