4.1.3  Using the Free and Checked Builds of Windows NT

The DDK provides two versions of the Windows NT operating system, called the free build and the checked build. Getting Started explains how to install each version.

The free build of Windows NT is the retail version that end users buy. Free binaries are built with full optimization and contain a minimal set of debugging symbols, such as function entry points and global variables.

The checked build is shipped only with the DDK; it is used in debugging drivers and other system code. Checked binaries provide error checking, argument verification, and system debugging code not present in the free binaries.

Much of the additional code in the checked binaries is in the form of ASSERT (see Section 4.3.3.1) macros that test an expression. If the expression evaluates to FALSE, the macro generates a kernel debugger error message and breaks into the debugger. This lets you immediately determine the cause and location of the error. For example, recursive acquisition of a spin lock (where a thread tries to acquire a spin lock that it already owns) hangs the system in the free build of the operating system, but generates a breakpoint on the checked build of the operating system.

Use the free and checked builds of Windows NT as follows:

·Use the free build on the host machine, running WinDbg.

·Use the free build to develop and build a driver. Performance suffers in the checked build due to the additional code that is executed.

·Use the checked build on the target machine to test and debug a driver during the initial phases of its development.

·Use the free build on the target machine to test and debug your driver during the final phases of its development. The final testing of your driver must be done on a free version of the driver running the free build of Windows NT.

The extra protection of the checked build of Windows NT carries some penalties. Because of the additional error checking code and debugging information, the checked binaries are larger and run slower than the free binaries. This can conceal synchronization or other timing-related problems, such as race conditions, that become apparent only in the free build.

If you run the checked build of Windows NT without having enabled kernel debugging (refer to Section 4.1.4), unexpected system shutdowns can occur. This is because the additional checks in the checked build increase the likelihood of encountering a breakpoint. A kernel-mode breakpoint with kernel debugging disabled is an unhandled kernel-mode exception, so the system calls the KeBugCheckEx function and shuts down.

However, if kernel debugging is enabled, a breakpoint freezes all threads in the target system except for the component that communicates with WinDbg. This lets WinDbg connect to a running target machine that has kernel debugging enabled, even after a breakpoint has been encountered. See Section 4.1.9 for details.