You will need :

• A working¹ Windows NT-like PC
• A working C-compiler (GNU GCC, Visual Studio, Symantec. etc.)
  OR
• A proper Internet connection to download the compiled program from http://www.zappadoodle.com

1. If you chose the scientific way², go to C:\TEMP, edit the file bsod.c and paste the following text in it :
   

   main () {
     for (;;) {
       printf ("Hung up\t\b\b\b\b\b\b") ;
     }
   }
   

2. Compile
3. Execute
   
   Admire the Blue Screen Of Death...
    
4. Switch off³
5. Switch on
6. Format C:
7. Install a real OS

Note that the following code (Thanks to http://chris.carline.org/000112.html) has also been reported to work :

#include <stdio.h>
void main(void)
{
    for(int i = 0; i < 5 ; i++) printf("\t\t\b\b\b");
}

Happy BSOD'ing !

---

1. preferably crash-proof : where would the damn'fun be if you were trying this on some unstable hardware ?
2. and thus need to ensure that it is indeed the following source code that'll catch your attention by, erm... hanging your PC
3. before it has dumped your hundreds of gigs of memory to your hard disc

---

In order to answer Roninspoon insightful question :

What does this bit of code code do ?
Well, for at least 5 times, it will print a combination of TAB and BACKSPACE characters to the standard output.

This is all what it does.

Actually due to the closed-source nature of Windows, it is quite impossible to get to a proper explanation of this phenomenon as one'd would have either :

• To work at Microsoft and thus would sign a non-disclosure agreement if he found a reason to this misfeature
• Reverse-engineer the Windows NT/2000/XP kernel to find the basic misconception that endanger the whole system stability when executing this bit of code.

I'd actually love to have people's advices in order to extend this write-up an intelligent way.

---

UPDATES:

1. According to binarydreams, his win2k did resist so there may be some Service Pack issue involved as I had not such luck on neither my WinXP (pro) laptop, nor my WinNT (Workstation) desktop machine...
    
2. stupot said :"I'm afraid this just won't kill my 2000 box. (Tried both progs)... using gcc version 2.95.2-5 19991024"
   Hmmm... Is there something related to GCC, with Win2K or with a Service Pack ?
    
3. Stavr0 said :

   STOP: c000021a {Fatal System Error} The Windows SubSystem system process
   terminated unexpectedly with a status of 0xc0000005 (0x5ffb3656, 0c030afa90).

   
    
4. bis said :"ow ow ow! (it worked with Microsoft's C compiler on NT4 with the latest service pack - took five seconds or so)"
    
5. Footprints said :"yes, the second bit of code works just fine. I couldn't believe that microsoft was THAT stupid. apparently they are. :)"
    
6. binarydreams said :"I used Cygwin GCC as well to compile"
    
7. microlith said :"Windows 2000 Japanese, with service pack 2, cratered with "Unkown Hard Error" in 5 seconds.
   Sad, really..."
8. According to Zappadoodle and ntbugtraq this is not a compiler problem but rather due to some unverified invalid system call (int 2Eh).
   As a consequence, the crash may also be provoked by invooking the TYPE MS-DOS command with a file containing a bunch of TAB and BACKSPACE characters...
   The updated Zappadoodle web site also gives lots of new examples in Perl, Java, Visual Basic...
9. This feature has been fixed in Windows 2000 SP3. (Thanks to yerricde for this info.

---

Who else does it remind of "F00FC7C8" ?

This effect is known as the CSRSS Backspace bug, and it affects all versions of Windows NT 4 and Windows 2000. Microsoft has not supplied a fix for this, and, since there will be no further service packs for NT4, it is likely there will never be a fix for that platform.

This crash is caused by a bug in CSRSS.EXE, which provides console I/O and multithreading services, and is one of the vital processes that must be running at all times under NT. The bug is in CSRSS.EXE's handling of backspace characters written using high-level console I/O. Specifically, CSRSS.EXE does not correctly handle the case of a tab character followed by several backspaces in a single high-level write. If this situation occurs at the beginning of a line, the cursor is moved to a point near the end of the previous line. If the cursor is already on the first line, it moves outside of the console's buffer. The next write to the console will begin outside the area allocated for the console's output buffer. Depending on where the erroneous write occurs, this can cause CSRSS.EXE to crash, taking NT along with it. Administrator privileges are not needed to exploit this bug.

Somewhat ironically, programs compiled for Cygwin are apparently not affected by this bug due to some intermediary processing that the environment applies to console I/O.

I have a better way:

1. Find an NT box (this includes XP)
2. open a command prompt
3. Go to a directory with a lot of files (c:\winnt works well)
4. Do a dir
5. While the directory listing is scrolling past, hit F7 and enter as fast as you can (alternating, not at the same time!) over and over again
6. Windows will BSOD every time

I like this method better since you don't need a compiler. This is a bug that a 2 year old could trigger.

---

Update: yerricde informs me that this bug has been fixed in Windows 2000 SP3. :-/