Bug which crash Windows 2000 and XP
Masaru Tsuchiyama
He found the bug which crash or reboot Windows 2000
and Windows XP.
If the following code is excuted on Win2k or XP,
Win2k or XP crashes or rebooted.
On Windows 98,nothing happens.
#include <stdio.h>
int main( void )
{
for(;;){
printf( "hung up\t\t\b\b\b\b\b\b" );
}
return 0;
}
-----------------------------
Masaru Tsuchiyama
-----------------------------
Richard Norman
>If the following code is excuted on Win2k or XP,
>Win2k or XP crashes or rebooted.
>On Windows 98,nothing happens.
>
>#include <stdio.h>
>
>int main( void )
>{
> for(;;){
> printf( "hung up\t\t\b\b\b\b\b\b" );
> }
> return 0;
>}
Much to my amazement, this is not just a joke on
the infinite loop. The following also crashes Win2000
int main()
{
printf("hung up\t\t\b\b\b\b\b\b");
print("hung up\t\t\b\b\b\b\b\b");
}
It seems that the escape sequence (which looks like
perfectly legal C) crashes a buffer somewhere (or a
pointer so that the next write crashes it).
Is this a known feature of the operating system?
Andy Lutomirski
console subsystem handles repeated writes (even the mouse slows down). I'll
go try this now (I'm curious).
Andy
"Richard Norman" <rsno...@mediaone.net> wrote in message
news:fmuatto0aj2kcsgl0...@4ax.com...
Tomas Rosin
Some more observations.
Masarus code crashes NT4 too, with a 'blue screen' (Fatal system error)
though!
However, the following code didn't crash NT4!
>int main()
> {
> printf("hung up\t\t\b\b\b\b\b\b");
> print("hung up\t\t\b\b\b\b\b\b");
> }
Tomas
"Richard Norman" <rsno...@mediaone.net> wrote in message
news:fmuatto0aj2kcsgl0...@4ax.com...
Charlie Gibbs
writes:
>Some more observations.
>
>Masarus code crashes NT4 too, with a 'blue screen' (Fatal system error)
>though!
Yup, it crashes my NT4 box too, but not my 98 box. I sent a copy
off to the office and asked them to try it on a Win2K box. Not
only did it crash, it took down the whole network. Amazing, for
such a simple program.
Just for laughs, I tried compiling the program with my ancient
MS-DOS Lattice compiler. That version worked just fine on both
my 98 and NT4 boxes. (I use Borland C++ Builder 4 for my 32-bit
Windows stuff.)
NT/2K robust? Ha!
--
cgi...@nowhere.in.particular (Charlie Gibbs)
I'm switching ISPs - watch this space.
Colin Davies
Win98SE
Must be something wrong with my system.
--
Hi, I need PC users to test my VMTU algorithm, It is designed to increase
the throughput of modem/internet connections. Its at http://www.vmtu.com
any questions just contact me
co...@vmtu.com
Regardz
Colin Davies
"Charlie Gibbs" <cgi...@nowhere.in.particular> wrote in message
news:720.696T19...@nowhere.in.particular...
Frans Bouma
> writes:
>
> >Some more observations.
> >
> >Masarus code crashes NT4 too, with a 'blue screen' (Fatal system error)
> >though!
>
> Yup, it crashes my NT4 box too, but not my 98 box. I sent a copy
> off to the office and asked them to try it on a Win2K box. Not
> only did it crash, it took down the whole network. Amazing, for
> such a simple program.
>
> Just for laughs, I tried compiling the program with my ancient
> MS-DOS Lattice compiler. That version worked just fine on both
> my 98 and NT4 boxes. (I use Borland C++ Builder 4 for my 32-bit
> Windows stuff.)
hmmm. VC++ comes with the source of the CRT, and looking
in printf(), it uses _output() from output.c, it's a fairly
long routine *cough*. Anyone noticed the bug in there yet?
FB
Ralf Buschmann
>Yes,
>
>Some more observations.
>
>Masarus code crashes NT4 too, with a 'blue screen' (Fatal system error)
>though!
It crashes Windows NT and Windows 2000 here, but not Windows 9x/XP.
However, it's interesting that it only crashes when you double click on
the .exe in Explorer. Launching it from the command line in a command
prompt window does _not_ cause a crash.
>However, the following code didn't crash NT4!
>
>>int main()
>> {
>> printf("hung up\t\t\b\b\b\b\b\b");
>> print("hung up\t\t\b\b\b\b\b\b");
>> }
Hmm, this "worked" for me. But the second "print" should be "printf".
Ralf.
Takeshi SHIGIHARA
They also crashed XP-rc1 box.
But when I inserted
SetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), 0);
before while(1) , the program ran normaly.
-- c1.c --
int main()
{
const char* str = "hung up\t\t\b\b\b\b\b\b";
int len = strlen(str);
DWORD wr;
while (1) {
WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), str, len, &wr, NULL);
}
return 0;
}
-- c2.c --
int main()
{
const char* str = "hung up\t\t\b\b\b\b\b\b";
int len = strlen(str);
DWORD wr;
while (1) {
WriteConsole(GetStdHandle(STD_OUTPUT_HANDLE), str, len, &wr, NULL);
}
return 0;
}
--
----- Takeshi SHIGIHARA
Office cyg...@zero.ad.jp
Home cyg...@po.jah.ne.jp -----
Bart Kowalski
news:3bd56bdb$0$21707$44c9...@news2.asahi-net.or.jp...
> I'm posting this article on behalf of my coworker.
>
> He found the bug which crash or reboot Windows 2000
> and Windows XP.
>
> If the following code is excuted on Win2k or XP,
> Win2k or XP crashes or rebooted.
> On Windows 98,nothing happens.
>
> #include <stdio.h>
>
> int main( void )
> {
> for(;;){
> printf( "hung up\t\t\b\b\b\b\b\b" );
> }
> return 0;
> }
The simplest program that could reproduce the problem on my system (Win 2000)
was:
#include <stdio.h>
int main(void)
{
printf("\t\b\b");
return 0;
}
Seems like there is definitely something fishy with the console I/O.
Bart.
Serve La.
"Bart Kowalski" <m...@nospam.com> wrote in message
news:3bd6c845$0$2727$45be...@newscene.com...
> The simplest program that could reproduce the problem on my system (Win
2000)
> was:
>
> #include <stdio.h>
>
> int main(void)
> {
> printf("\t\b\b");
> return 0;
> }
Yep, and it doesn't matter if it's unicode or not (printf or wprintf)
Serve La.
Callstack:
NTDLL! 77f82242()
NTDLL! 77f82250()
KERNEL32! 77e86878()
KERNEL32! 77e868d1()
_write(int 1, const void * 0x002f25f8, unsigned int 7) line 168 + 57 bytes
_flush(_iobuf * 0x00424a60) line 162 + 23 bytes
_ftbuf(int 1, _iobuf * 0x00424a60) line 171 + 9 bytes
printf(const char * 0x0042201c `string') line 62 + 14 bytes
main() line 46 + 10 bytes
mainCRTStartup() line 206 + 25 bytes
KERNEL32! 77e97d08()
registers:
EAX = 000000B0 EBX = 00000000
ECX = 0094007C EDX = 00000007
ESI = 0012F954 EDI = 00000000
EIP = 77F82247 ESP = 0012F910
EBP = 0012F92C EFL = 00000246
It happens here NTDLL! 77f82242()
The function's name is: NtRequestWaitReplyPort
The instruction where it happens is "int 2E". According to the MS website
intse does the following:
"At Ring 0, the INT 2Eh handler is called _KiSystemService, which is located
in NTOSKRNL.EXE. _KiSystemService takes the dispatch number (placed in EAX
by NTDLL.DLL) and uses it as an index into a dispatch table that each thread
has a pointer to. Just before jumping to the designated handling code,
_KiSystemService copies the parameters from the Ring 3 stack (which EDX
points to) onto the Ring 0 stack. "
http://www.microsoft.com/msj/defaulttop.asp?page=/msj/archive/s413.htm
But then I'm still nowhere :-)
Bart Kowalski
news:tte2hod...@corp.supernews.com...
int 2E is the instruction that actually switches the processor to kernel mode to
service the system call, so the bug is probably deep inside the kernel. In other
words, you can't debug it with conventional tools.
Maybe the code is trying to make a system call that doesn't exist and this
somehow triple-faults the CPU. But I don't really see how this could happen, and
in any case if that's really what's happening then there's something seriously
wrong with Windows NT.
Bart.
Jim Johnson
JUST FUCKING LOVELY.
I built this code, shut down all my programs, and ran it. It crashed the
system, as expected - but it also took out my system's sound!
Microsoft's most stable OS ever, my ass.
--
Jim Johnson
Metaphoric Software
-------------------
Makers of Techno Toys
Software for Electronic Music
http://www.technotoys.com
in...@technotoys.com
Frans Bouma
> > The function's name is: NtRequestWaitReplyPort
> >
> > The instruction where it happens is "int 2E". According to the MS website
> > intse does the following:
> > "At Ring 0, the INT 2Eh handler is called _KiSystemService, which is located
> > in NTOSKRNL.EXE. _KiSystemService takes the dispatch number (placed in EAX
> > by NTDLL.DLL) and uses it as an index into a dispatch table that each thread
> > has a pointer to. Just before jumping to the designated handling code,
> > _KiSystemService copies the parameters from the Ring 3 stack (which EDX
> > points to) onto the Ring 0 stack. "
> > http://www.microsoft.com/msj/defaulttop.asp?page=/msj/archive/s413.htm
> >
> > But then I'm still nowhere :-)
>
> int 2E is the instruction that actually switches the processor to kernel mode to
> service the system call, so the bug is probably deep inside the kernel. In other
> words, you can't debug it with conventional tools.
>
> Maybe the code is trying to make a system call that doesn't exist and this
> somehow triple-faults the CPU. But I don't really see how this could happen, and
> in any case if that's really what's happening then there's something seriously
> wrong with Windows NT.
It's not a kerneltrap, since the stop error is somewhere in the C0002xx
ranges, but a shutdown of a subsystem (like OS/2 subsystem, here the
windows subsystem) which causes the system to stop. I dunno if it still
is the fault of the microkernel or if its a bug in a layer on top of
it (f.e the windows subsystem) that's feeding hte kernel incorrect
stuff. A guy in a dutch newsgroup suggested it was something with
the gui, since the backspace is moving outside the window, which is
then probably not handled correctly. Since the gui is handled in kernelspace
it's probably that.
O.
Patrick Craig
Here's another variation:
#include <stdio.h>
int main(void)
{
int i;
FILE *fp;
fp = fopen("killer.dat","wb");
for (i = 0; i < 3000; i++)
{
fprintf(fp,"\t\t\b\b\b\b\b\b");
}
fclose(fp);
return 0;
}
Run this program to create the killer.dat file, then open
a new DOS window and run the following command:
type <full path to killer.dat>
Crashes my NT machine anyway!
Patrick
Serve La.
"Patrick Craig" <pat...@nag-j.co.jp> wrote in message
news:f65f688d.0110...@posting.google.com...
> Here's another variation:
>
> #include <stdio.h>
>
> int main(void)
> {
> int i;
> FILE *fp;
> fp = fopen("killer.dat","wb");
> for (i = 0; i < 3000; i++)
> {
> fprintf(fp,"\t\t\b\b\b\b\b\b");
> }
> fclose(fp);
> return 0;
> }
It all comes down to the same code. It would probably also crash if you used
WriteFile to a serial port. I'm pretty sure the bug is located in the
ntoskrnl.exe source, since int2E causes code to be executed there. For the
rest, I'm giving up ;-)
Charlie Gibbs
pat...@nag-j.co.jp (Patrick Craig) writes:
>Here's another variation:
>
>#include <stdio.h>
>
>int main(void)
>{
> int i;
> FILE *fp;
> fp = fopen("killer.dat","wb");
> for (i = 0; i < 3000; i++)
> {
> fprintf(fp,"\t\t\b\b\b\b\b\b");
> }
> fclose(fp);
> return 0;
>}
>
>Run this program to create the killer.dat file, then open
>a new DOS window and run the following command:
>
>type <full path to killer.dat>
>
>Crashes my NT machine anyway!
Oddly enough, my NT4 box could TYPE this file without crashing
(although the output did get messed up, in comparison with the
nice neat columns which come out on my MS-DOS and Win98 boxen).
The original program took my NT box down quite nicely.
I won't try sending this one off to the office - I got a cow orker
in trouble on Tuesday when he ran the original program on a Win2K
box and took their network down.
Jim M
>"Serve La." <ser...@c.demon.nl> wrote in message
>news:tte2hod...@corp.supernews.com...
>> Traced it right to the point where it went bad
>>
I laughed when I read this, thinking "really screwed system", but so
is mine :(
Both NT4 and 5.
NT4 SP7 anyone ?
Jimbo
--
@ Derbyshire
Jonathan de Boyne Pollard
FB> C0002xx ranges, but a shutdown of a subsystem (like OS/2
FB> subsystem, here the windows subsystem) which causes the system
FB> to stop. I dunno if it still is the fault of the microkernel or
FB> if its a bug in a layer on top of it (f.e the windows subsystem)
FB> that's feeding hte kernel incorrect stuff. [...]
The kernel isn't being fed anything. CSRSS.EXE is being terminated due to an
access violation. This problem lies almost entirely outside of kernel space.
<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/csrss-backspace-bug.html>
Jonathan de Boyne Pollard
CO> It is in system service B0h
You are very probably running Windows NT 2000. For some reason, that does not
correctly display the Blue Screen of Death. Windows NT 4 and Windows NT XP do
both display the Blue Screen of Death, however.
The bug is in CSRSS. INT 0x2E is largely irrelevant.
<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/csrss-backspace-bug.html>
Jonathan de Boyne Pollard
SL> port. I'm pretty sure the bug is located in the ntoskrnl.exe
SL> source, since int2E causes code to be executed there.
The bug is in the handling of high-level console I/O. Writing characters to a
serial device will not trigger it. Furthermore, this bug is not in the
Windows NT kernel.
<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/csrss-backspace-bug.html>
jacob navia
But doing nothing is an even greater mistake.
It would be easy to laugh the people that wrote NT now. But I will follow
the advise of somebody else that said:
Only those that never sinned throw the first stone.
I have had this kind of bug MANY times in my life, so I can understand the
people that wrote that code. What is amazing however, is that it took so
many years to discover it!
jacob
"Jonathan de Boyne Pollard" <J.deBoyn...@tesco.net> wrote in message
news:3BDAD62D...@tesco.net...
Jonathan de Boyne Pollard
It is not necessary to have a C++ compiler to demonstrate this bug. It can be
demonstrated with a wide variety of script languages, or even with nothing
more than a text file and the humble TYPE command.
<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/csrss-backspace-bug.html>