I ran across an issue recently where several CScript processes would peg the CPU for several seconds at a time. You may have run across the same issue, and read some other articles about updating CScript to the latest version (5.7). But, what if CScript.exe is already at version 5.7, like it was in this particular instance?
Apply the update package again.
I knew it was a problem with CScript, but after looking at the version and verifying it was the latest version, the problem was elusive. I applied the update package again, simply because I was running out of ideas and figured it couldn’t hurt. Well, it didn’t hurt. It solved the problem.
Here’s what I observed that made it so clear it was still a problem with CScript, in case you are having similar issues and need to prove this case in your environment.
How to quickly verify CScript is root cause in this situation.
1. Create a text file
2. Paste WScript.echo "hello" into it
3. Save as %temp%\test.vbs
4. Open a command prompt
5. Type CScript.exe %temp%\test.vbs and hit enter
You will see this:
So, what’s so special about that? Well, how long did it take for hello to output to screen? If it took more than a millisecond, that’s too long. In my case, it took 2 seconds just to echo a string. That’s a problem!
Verify issue with Procmon
If you really want to see how this is affecting your agent machine, follow these steps.
1. Open up Procmon on the agent machine in question
2. Setup your filter like so:
3. Capture for a couple minutes. You’ll see some CScript processes logged fairly soon, like so:
Take a look at the Exit Status on all these CScript processes. They are all over 2 seconds, and that’s why CPU is pegged for so long.
As you can see from above, this is the current version of CScript.exe (220.127.116.11335) for Windows Server 2003. But, after RE-applying the CScript update (same version), all these processes that were taking more than 2 seconds are now running in fractions of a second.