infoTECH Feature

December 28, 2009

IE 8 Introduces JScript WSH Bug

I know it's not wise, but there's a reason why I have Windows Update shut off on my servers. I have nothing against automatically receiving the latest security and performance updates, just there's this strange desire to have the servers, well, up and running.

Windows update rarely fails to deliver its content without a headache. The latest was when I opened up Windows Update on a server allowing it to unleash a litany of updates in one shot. When the server rebooted and the services started without a hitch, I knew it was too good to be true and I was proven right the next day. 

Turns out that a long running JScript nightly job had just crashed unexpectedly with no warnings, no events, nothing. Now I had recently done some hardware work on the server and I was led astray thinking this was a hardware issue. After crossing that off the list, I turned my attention to Windows updates, removing them one at a time and testing the program only to have it crash again and again.

It wasn't until I removed Internet Explorer 8 that the JScript program returned to its normal execution mode and stopped crashing. So what exactly had IE 8 done to the system? I still don't have a clear idea on that. About all I can surmise is that IE8 alters garbage collection routines in JScript or Windows Scripting Host (WSH) where JScript is executed within. As the program runs, a legit referenced object would suddenly vanish (presumably garbage collected) causing the object address to become invalid and hence promptly crash due to an ostensible access violation.

The good news which helped with troubleshooting is that this flaw is reproducible on any host with IE 8 installed. It seems to be independent of the Windows version or even the JScript/WSH version, and the script crashes at the same spot every time. It's almost like some hard-coded trigger is activated based on a certain but unknown criteria.

Now for the fun part, below is the JScript code. Just make sure you run it on a host with IE 8 installed. If you change the array size or the loop count, the script may not crash! Apparently only certain conditions trigger the flaw.

while(true) {
 arr="0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7".split(" ");

 for (j=0;j<198;j++)


To run the code, save the code block is a file named test.js. Then open up the command window (cmd.exe) and run it like so:
C:\> cscript test.js

The program should crash after the 13,106th iteration, as indicated below:

Now, Microsoft (News - Alert) just needs to reimburse my company for the wasted hours chasing after this problem.


Subscribe to InfoTECH Spotlight eNews

InfoTECH Spotlight eNews delivers the latest news impacting technology in the IT industry each week. Sign up to receive FREE breaking news today!
FREE eNewsletter

infoTECH Whitepapers