Post subject: Re: Differences between checked and free builds Posted: Thu Jan 12, 2012 10:42 pm
Newbie Beta Collector
Joined Thu Jan 12, 2012 9:04 pm
When the free build discovers correctable problems, it continues to run.
Urrrh, that's not the case at all; free builds have no such checks. Checked builds on the other hand make use of ASSERT and NT_ASSERT macros to allow developers to place checks on certain expressions and if they evaluate to false, allow the option to break in to a debugger for example. Checked builds also contain any additional code included inside of #if DBG directives that can perform further tasks the developer chooses.
The checked build distribution medium contains the checked version of the operating system, plus checked versions of HALs, drivers, file systems, and even many user-mode components.
I would change that to be most user-mode components. Those components that wouldn't be compiled using a checked environment would be those that are binaries supplied by other teams outside of the Windows division or that vendors have supplied or those that perform sensitive tasks such as licensing protection or security or MPEG decoding as examples.
You can check if a system is running a checked kernel by looking at the value of certain global variables. In earlier versions of NT, the variable was ExBuildVersion, in newer versions it's NtBuildNumber.
kd> dd nt!ExBuildVersion l 1 801a6d70 f00001ff
If you look at the value in more detail, you'll see it actually contains two parts. If the first part is an 'f', it's a free build. If it's a 'c', then it's a checked build. The second part shows the actual build number. In this case, it's 511 which is the RTM version of Windows NT 3.1.
You also don't need to install the complete checked build, you can copy across only the binaries of interest. It might be that you only need a checked build of ntoskrnl.exe and hal.dll or then you might only need a checked version of a user-mode component you're troubleshooting.
If you check the Microsoft Knowledge Base, a few components are documented for which using a checked build will supply additional tracing information. For the other components, it is purely a choice made by the developer as to what steps are required to "turn on" additional features of checked components. Some components require no configuration and will generate tracing information by default. Others you need to add entries to INI files, the registry, start the component using a different command line or even break in with a debugger and change global variables.
Most of the problems with having to use checked components just to obtain tracing information go away as components start to use Event Tracing for Windows which was first included in Windows 2000.