Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

While looking for a Windows XP download in the MSDN subscriber portal, I noticed this:

enter image description here

So, what is the Debug/Checked version?

share|improve this question
up vote 31 down vote accepted

The debug/checked version is used for debugging device drivers. It contains run-time checks for error conditions and has run-time optimizations removed.

share|improve this answer
Incase it isn't clear enough: This means that the debug/checked versions will run slower than the ones designed for consumer use. – Hengjie Nov 5 '12 at 2:40

In particular, interpreting the explanations, using a Debug/Checked version is only likely to help you if you are writing kernel-mode components (most likely drivers), or if you are relying on some third-party kernel-mode components that you believe might be buggy under the conditions that you place them in.

That is to say: the vast majority of developers (i.e. those developing application software — software that users interact with, regardless of whether it's "managed" or "unmanaged", command-line or GUI-based; in short, user-space code) don't need this at all, and shouldn't use it, because it is slower than mainstream versions of Windows.

So if you're not sure whether you need it, you almost certainly should avoid it. Conversely, if your work would benefit from it, then you would already be well aware of it (e.g. from wherever it was that you learnt how to go about kernel-mode development).

share|improve this answer
Speed is utterly irrelevant during most testing. The reason most application developers don't use checked builds is that none of their code will even launch due to all the asserts. If all developers had to produce working code on checked builds, we'd be much better off. – EKW Aug 28 '15 at 20:18
@EKW Speed is utterly irrelevant... Not true. A lot of tricky bugs only come up when things start working fast enough to create the conditions for them. Especially subtle threading errors, async callbacks, etc. Sometimes you can even see it visually when running some ancient 16 bit application, e.g. very annoying flickering repainting. – Evgeni Sergeev Aug 29 '15 at 7:17
Hence "most cases." Eventually, you need to verify against a free or retail build of the OS. Applications generally, fail to make correct calls to OS functions or handle exceptions properly more often than they have concurrency issues, however. – EKW Aug 29 '15 at 19:16
Yeah, maybe applications on the moon. – Evgeni Sergeev Aug 30 '15 at 12:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .