Windows® Internals, Sixth Edition, Part 1

You can then add the name of any facility after the switch to display the policy value for that facility. For example, to look at the limitations on CPUs and available memory, use the Kernel facility. Here’s the expected output on a machine running Windows 7 Ultimate:C:\>SlPolicy.exe -f Kernel SlPolicy v1.05 - Show Software Licensing Policies Copyright (C) 2008-2011 Winsider Seminars & Solutions Inc. www.winsiderss.com Kernel ------ Processor Limit: 2 Maximum Memory Allowed (x86): 4096 Maximum Memory Allowed (x64): 196608 Maximum Memory Allowed (IA64): 196608 Maximum Physical Page: 4096 Addition of Physical Memory Allowed: No Addition of Physical Memory Allowed, if virtualized: Yes Product Information: 1 Dynamic Partitioning Supported: No Virtual Dynamic Partitioning Supported: No Memory Mirroring Supported: No Native VHD Boot Supported: Yes Bad Memory List Persistance Supported: No Number of MUI Languages Allowed: 1000 List of Allowed Languages: EMPTY List of Disallowed Languages: EMPTY MUI Language SKU: Expiration Date: 0

Checked Build

There is a special debug version of Windows called the checked build (available only with an MSDN Operating Systems subscription). It is a recompilation of the Windows source code with a compile-time flag defined called “DBG” (to cause compile-time, conditional debugging and tracing code to be included). Also, to make it easier to understand the machine code, the post-processing of the Windows binaries to optimize code layout for faster execution is not performed. (See the section “Debugging Performance-Optimized Code” in the Debugging Tools for Windows help file.)

The checked build is provided primarily to aid device driver developers because it performs more stringent error checking on kernel-mode functions called by device drivers or other system code. For example, if a driver (or some other piece of kernel-mode code) makes an invalid call to a system function that is checking parameters (such as acquiring a spinlock at the wrong interrupt level), the system will stop execution when the problem is detected rather than allow some data structure to be corrupted and the system to possibly crash at a later time.

EXPERIMENT: Determining If You Are Running the Checked Build

There is no built-in tool to display whether you are running the checked build or the retail build (called the free build). However, this information is available through the “Debug” property of the Windows Management Instrumentation (WMI) Win32_OperatingSystem class. The following sample Microsoft Visual Basic script displays this property:strComputer = "." Set objWMIService = GetObject("winmgmts:" _ & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2") Set colOperatingSystems = objWMIService.ExecQuery _ ("SELECT * FROM Win32_OperatingSystem") For Each objOperatingSystem in colOperatingSystems Wscript.Echo "Caption: " & objOperatingSystem.Caption Wscript.Echo "Debug: " & objOperatingSystem.Debug Wscript.Echo "Version: " & objOperatingSystem.Version Next

To try this, type in the preceding script and save it as file. The following is the output from running the script:C:\>cscript osversion.vbs Microsoft (R) Windows Script Host Version 5.8 Copyright (C) Microsoft Corporation. All rights reserved. Caption: Microsoft Windows Server 2008 R2 Enterprise Debug: False Version: 6.1.7600

This system is not running the checked build, because the Debug flag shown here says False.

Much of the additional code in the checked-build binaries is a result of using the ASSERT and/or NT_ASSERT macros, which are defined in the WDK header file Wdm.h and documented in the WDK documentation. These macros test a condition (such as the validity of a data structure or parameter), and if the expression evaluates to FALSE, the macros call the kernel-mode function RtlAssert, which calls DbgPrintEx to send the text of the debug message to a debug message buffer. If a kernel debugger is attached, this message is displayed automatically followed by a prompt asking the user what to do about the assertion failure (breakpoint, ignore, terminate process, or terminate thread). If the system wasn’t booted with the kernel debugger (using the debug option in the Boot Configuration Database—BCD) and no kernel debugger is currently attached, failure of an ASSERT test will bugcheck the system. For a list of ASSERT checks made by some of the kernel support routines, see the section “Checked Build ASSERTs” in the WDK documentation.