Hey guys. I came across this just recently, but I'm not sure if you guys are aware of it. It crashes csrss.exe (thus W2K, NT, XP) through the command console. I tried writing the same program in Perl, and it did in fact crash my system. I did not see a BSOD, just automatically froze for a millisecond then rebooted. <br /><br /># The Perl code was very simple:<br /><br />while($x=1) {<br /> print "testing\t\b\b\b\b\b\b\b";<br />}<br /><br />csrss.exe seems to have a problem handling many backspaces after a tab when being displayed in the command console. As this loops infinitely, it tries to access memory within the scope of this string value, and causes csrss.exe to crash. Any programming language that has access to the command console, and execute programs, can do this. As long as it is displayed, it will crash, so even a text file in the console will do so. There are some instances when the bug will not be replicated. For more info check out the following.<br /><br /><br /><br />

Dani AI

Generated

Short summary and context: this is the well‑known console bug that reported — writing a TAB followed immediately by many BACKSPACE characters to a Windows console could crash the Client/Server Runtime Subsystem (csrss.exe) and take the machine down. It was widely discussed in 2001–2002 and, in practice, stopped reproducing once Windows 2000 Service Pack 3 and Windows XP Service Pack 1 were rolled out. (jdebp.uk)

What actually goes wrong: csrss.exe’s high‑level console code had a bounds‑checking error. When a BACKSPACE immediately follows a TAB near the start of the first console line, the cursor arithmetic could be moved outside the console buffer and a subsequent printable character could be written out of bounds, causing an access violation. Because csrss is a critical user‑mode system process, its failure forces a system halt. (jdebp.uk)

How it was reproduced and when to be careful: the bug is triggered by sending a TAB then many BACKSPACEs as part of a single high‑level write to a console (for example, displaying a prepared text file with TYPE). Low‑level console output routines (and some tools that interpose their own handling) do not invoke the faulty code path, which explains inconsistent reproduction. Do not test this on production machines — it can crash the OS and lose unsaved work. (jdebp.uk)

Practical mitigations if you still encounter old unpatched systems: install the relevant service pack (W2K SP3 / XP SP1), avoid printing raw control characters from untrusted input, or sanitize output in your tools. Example: a tiny Python filter that removes backspace characters (and expands tabs) before printing:

# sanitize_console.py
import sys
def sanitize(s):
    return s.replace('\x08', '').replace('\t', '    ')
for line in sys.stdin:
    sys.stdout.write(sanitize(line))

Pipe suspicious text through a sanitizer like this before displaying it in an old console. For developers, prefer low‑level console APIs or explicit sanitization of input to prevent accidental triggers. (jdebp.uk)

Recommended Answers

All 3 Replies

heh - niiice ...
btw, if you're having a problem getting the forum to recognize a full link, surround it in

&#91;url&#93;http&#58;//blah&#91;/url&#93;

This way the link doesn't break off before the URL ends

Whoops. I meant out of the scope, not within the scope.

Good news (if anyone cared, lol). Microsoft has fixed this problem in SP3. Took them long enough. :)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.