Post subject: Re: Differences between checked and free builds Posted: Thu Jun 02, 2011 2:02 pm
Newbie Beta Collector
Joined Sun Sep 06, 2009 11:47 am
Posts 46
Location Russia
Favourite OS Windows XP checked build
Win2003srv x64 I have found in a network, didn't look yet, and here x86 haven't got while. With MSDN to swing it will not turn out, sponsors aren't present
Has found recently WinXP chk, 2 hours I wait, when 3rd will be put servicepack
Post subject: Re: Differences between checked and free builds Posted: Fri Jun 17, 2011 12:59 pm
Newbie Beta Collector
Joined Sun Sep 06, 2009 11:47 am
Posts 46
Location Russia
Favourite OS Windows XP checked build
Now I look on Windows XP Media Center edition 2002 Checked/debug - anything outwardly doesn't differ from usual Windows XP, except SP. It can not MCE? Disk label - X1APCHK_EN
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
Posts 26
Daniel wrote:
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.
Daniel wrote:
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.
Users browsing this forum: Bing [Bot] and 8 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum
All views expressed in these forums are those of the author and do not necessarily represent the views of the BetaArchive site owner.