Where do "checked" and "free" come from?

People who have MSDN or the DDK know that Windows is typically built in two different flavors, "Checked" and "Free".  The primary difference between the two is that the "checked" build has traces and asserts, but the free build doesn't.

Where did those names "checked" and "free" come from?  It's certainly not traditional, the traditional words are "Debug" and "Retail" (or "Release").

When we were doing the initial development of Windows NT, we started by using the same "Debug" and "Retail" names that most people use.

The thing is, it turns out that there are actually four different sets of options that make up the "Debug" and "Retail" split.

You have:

  1. Compiler Optimization: On/Off
  2. Debug Traces: On/Off
  3. Assertions: Enabled/Disabled
  4. Sanity checks: Enabled/Disabled

Traditionally, "Debug" is "Optimization:off, Traces:on, Assertions: on" and "Retail" is "Optimization:on, Traces:off, Assertions: off".  Sanity checks was something the NT team added.  The idea was that there would be additional sanity checks built in for our internal development that would be removed before we shipped.

So the NT build team wanted to build "Optimization:on, Traces:on, Assertions: on, sanity checks:on" and "Optimizations:on, traces:off, assertions: off, sanity checks: on" and "optimizations:on, traces:off, assertions:off, sanity checks: off".

The last was what was traditionally called "Retail" - no debugging whatsoever.  However, the question still remained - what to call the "O:on, T:on, A:on, S:on" and "O:on, T:off, A:off, S:on" build - the first wasn't "Debug" because the optimizer was enabled, the latter wasn't "Retail", since the sanity checks were enabled.

So clearly there needed to be some other name to differentiate these cases.  After some internal debate, we settled on "Checked" for the "O:on, T:on, A:on, S:on" and "Free" for the "O:on, T:off, A:off, S:on" build.  Checked because it had all the checks enabled, and free because it was "check free".

And as the NT 3.1 project progressed, the team eventually realized that (a) since they'd never actually tested the "retail" build, they had no idea what might break when they started making builds, and (b) since they had perf tested the free build and it met the perf criteria, the team eventually decided to ship the free build as the final version.



Comments (26)

  1. Anonymous says:

    So, are there still sanity checks in the Free build?

  2. PatriotB says:

    "After some internal debate, we settled on "Checked" for the "O:on, T:on, A:on, S:on" and "Free" for the "O:on, T:off, A:off, S:on" build. Checked because it had all the checks enabled, and free because it was "check free"."

    Wait a sec… but they both have "S:on" (sanity checks on)… shouldn’t they both be checked, and the differentiation be on the assertions?

  3. No, the point is that the sanity checks are always on, the original intent was that they’d be removed for retail, but that never happened.

    The checked/free differentiation is about traces and asserts.

  4. David, yes, the sanity checks are still there. The concept of a "retail" build in it s original form no longer exists.

  5. Anonymous says:

    Out of abject curiosity, is this only true in NT and derivatives, or does this include programs like office, exchange, etc as well? I know anything built in .Net would have various sanity checks as well.

  6. Anonymous says:

    Can we get an example of a sanity check you’re likely to find within Windows?

  7. Anonymous says:

    > And as the NT 3.1 project progressed, the

    > team eventually realized that (a) since

    > they’d never actually tested the "retail"

    > build,

    With more modern versions the opposite seems to be the case. For example maybe I’m the only person who tried to install Visual Studio 2005 July CTP onto a checked build (couldn’t do it) or the earlier beta 2 (got most of it done). And maybe I’m the only person who noticed some of the messages displayed in WindBag by mmc.exe and some other stuff under a checked build. Obviously the kernel itself does run under a checked build so some teams are still dogfooding a checked build, and some driver writers mention how much they depend on checked builds. Can you persuade some of the other teams how valuable it would be to do the same?

  8. Anonymous says:

    I think this is the first post from you about internal stuff that I had absolutely no clue about. I had no idea whatsoever. And I’d never thought to ask anyone.

    Thanks for the info.

    I wonder why there is no "Windows Lore" wiki somewhere. I haven’t even seen anything like that internally. Without one, what will the rest of us do when the mothership comes to take you and Raymond away?

  9. Anonymous says:

    How does one decide what becomes an assertion and what becomes a sanity check? Aren’t both assumptions that will cause undefined behavior if violated?

  10. Anonymous says:

    Just curious…..

    Most test teams inside Microsoft use the fre builds (x86fre, ia64fre etc) for feature verification / BVTs / Sanity Passes.

    Which brings me to these ……….

    1- How often does your test team use a chk build for automated testing? Not as often as you possibly think…

    2- I don’t think the chk build is ever used for selfhosting or deployment purposes.

    3- Most teams use test hooks (e.g. registry keys) to turn on debug messages / traces / spews on fre builds. Plus you always have private symbols available for debugging. So what real advantage does a chk build have over a fre build?

    4- Then why do the build labs go through such pains to generate the checked builds for each feature branch (vbl_???_???). And that too on a daily basis. It clearly doesn’t find much usage…..

  11. Manip, I can’t come up with any examples, mostly because after 15 years any examples are long gone – the conditionals that made the "extra checks" are long gone so the concept is meaningless at this point.

    AC: We don’t use checked builds that often, but we run all our stuff checked – for some components that are relatively self contained (like the audio subsystem), it’s totally possible to drop a checked set of binaries onto a retail system. The checked build was always intended for testing purposes, not deployment/selfhost test (although I know some people who selfhost on checked builds (brave souls them)).

    And the reason that checked builds are built and tested is that the checked builds catch problems daily.

  12. Anonymous says:

    Oh sorry, I misunderstood. I thought Windows had generic sanity checking in it today…

    Although it kind of does if you compile using Visual Studio 2005 but not things that the programmer has to worry about.

  13. Manip, there are all KINDS of sanity checks in the OS. But they’re all just part of the normal OS, they’re not specifically called out.

    At one time there were #if !RTL conditional compilation macros around the "sanity checks", the #if checks have been removed because we’re never going to turn the RTL flag on.

  14. Anonymous says:

    One project I worked on (within MS but not the OS group) called the variation of optimizations:on and assert/spew/etc:on "Armor". I have no idea where that term came from though. Armor builds tended to be the ones that most people used on a day-to-day basis and they only dropped to Debug builds when the optimizer just got to funky with the code to figure it out without a lot of pain.

  15. Anonymous says:

    I worked on Microsoft’s Windows 2000 QA team back in the mid 1990s. We rarely tested the checked builds, but I would occasionally. The checked builds were sloooooow, like 20x slower than the free builds!

  16. Anonymous says:

    (I posted this previously but it seems to have gone in to the bit bucket)

    A project I worked on (at MS but not in the OS group) used the term "Armor" to refer to the optimizations:on and assert/spew/etc:on case. I don’t know the history behind this term though.

    Most devs used armor builds for day-to-day work and only dropped to debug builds when the optimizer was particularly unforgiving with respect to the debugger.

  17. Anonymous says:

    I understand. I just place sanity checks in their own category, I mean when you for example read in data and want to check IF(Number(Data)) that isn’t a "sanity check", that is a validation check. A sanity check is when you have had the data within the program for a while and just add a random check to make sure whatever you’re processing is what you think it is.. But something that you NEVER intend to trip off.

  18. Anonymous says:

    >> we settled on "Checked" for the "O:on, T:on, A:on, S:on"

    Is it still true today? Currently DDK setenv.bat file sets O:off for "Checked" build.


    rem set up an NT checked build environment


    /Od – This option turns off all optimizations

  19. Anonymous says:

    Here’s an sampling of various goofy bugs we’ve had to deal with in the CLR Debugging services over the…

  20. Anonymous says:

    > we settled on "Checked" for the "O:on, T:on, A:on, S:on"

    Is it still true today? the DDK build environment sets /Od for checked build and disables compiler optimization.


  21. Wei, that’s the DDK, not what’s MS builds.

    The optimizations are turned off because optimizations will mess up debugging. We live with the inconvenience internally because it catches optimizer bugs, but that’s a concious choice that we made internally.

  22. Anonymous says:

    Thursday, September 01, 2005 2:22 PM by Chris

    > The checked builds were sloooooow, like 20x

    > slower than the free builds!

    Yes, but they catch 20x as many bugs.

    Does someone really read reports sent by Windows Error Reporting? If so, ask them if it would have been 20x slower for developers and testers to dogfood Microsoft’s own code on a checked build than it is for analysts to interpret the reports.

  23. Anonymous says:

    Wednesday, August 31, 2005 9:48 PM by Norman Diamond

    > Obviously the kernel itself does run under a

    > checked build

    Liar. Did you even think of trying Windows XP SP2 checked build in any environment other than guest machine under Virtual PC? Uhhh, OK sure you did, there’s that 7 year old desktop machine on that desk next to you and it worked, but did you even think of trying a 5 year old machine with devices more powerful than the Virtual PC emulations? And how are you going to find if newer drivers even exist when Internet Explorer aborts every time you try to do a Windows Update?

    You should think about things like that before you post. "Obviously" indeed. You know how much you hate it when you find yourself lying.

Skip to main content