Vague WSHController/WSHRemote errors on Windows 2003
parrish...@gmail.com
We've automated several tasks here with the use of Windows Scripts. To
notify us when the tasks fail to complete, we use the
WSHController/WSHRemote objects and catch the errors via the Error
event. We aren't actually running the scripts remotely, they're all
run from the same machine, but this seemed to be the easiest/best way
to get useful error reports. We're open to suggestions of
alternatives, if there are any.
Anyway, this setup worked perfectly when we were running everything on
a Windows 2000 machine, but recently it was upgraded to Windows 2003.
Now we've found that if our tasks fail, the Remote_Error() sub is still
being called, but the information it contains is absolutely useless.
For example, if I create a "test.vbs" file that contains a single line
of "WScript.Echo 1/0", a Windows 2000 machine would report:
test.vbs terminated abnormally at 11/24/2006 1:15:09 PM
Error Number: 0x800A000B
Line: 1
Char: 1
Description: Division by zero
Source: Microsoft VBScript runtime error
Source Text:
But now, our Windows 2003 machine reports:
test.wsf terminated abnormally at 11/24/2006 1:16:25 PM
Error Number: 0x80004005
Line: 0
Char: 0
Description: Execution of the Windows Script Host failed.
Source: Windows Script Host Remote Script
Source Text: Unspecified error
No matter what the error generated in the task, the error reported via
Remote_Error() is always the same as above. Even calling
WScript.Quit() in the task generates the above error, which it didn't
do under Windows 2000, and which we don't want it to do.
So is this a known problem, hopefully one with a workaround? I've
tested on several Windows 2003 machines, some of which were Windows
2000 upgrades, some of which where fresh installs, and they all exhibit
the same behaviour. I'll paste the script we use below, in case that
helps.
Thanks for your time,
Rick Parrish
<job id="WSHController">
<script language="VBScript">
Dim objArgs, objController, objRemoteScript
' Check for command-line parameter
set objArgs = WScript.Arguments
if (objArgs.Count = 0) then
WScript.Echo "USAGE: [cscript | wscript] WSHController.wsf <full
path of script to execute>"
WScript.Quit(-1)
end if
' Start script
set objController = CreateObject("WSHController")
set objRemoteScript = objController.CreateScript(objArgs(0))
Call WScript.ConnectObject(objRemoteScript, "Remote_")
objRemoteScript.Execute()
' Wait for script to terminate
do while objRemoteScript.Status <> 2
WScript.Sleep(100)
loop
' This runs if the remote script encountered a problem
' Remote script cannot use ON ERROR RESUME NEXT
Sub Remote_Error
Dim objEmail, objError, objFSO
set objEmail = CreateObject("CDO.Message")
set objError = objRemoteScript.Error
set objFSO = CreateObject("Scripting.FileSystemObject")
objEmail.From = "x...@xxx.ca"
objEmail.To = "y...@yyy.ca; z...@zzz.ca"
objEmail.Subject = "WSHController - Error running " &
objFSO.GetFileName(objArgs(0))
objEmail.HTMLBody = objFSO.GetFileName(objArgs(0)) & " terminated
abnormally at " & Now() & "<br><br>"
objEmail.HTMLBody = objEmail.HTMLBody & "Error Number: 0x" &
Hex(objError.Number) & "<br>"
objEmail.HTMLBody = objEmail.HTMLBody & "Line: " &
CLng(objError.Line) & "<br>"
objEmail.HTMLBody = objEmail.HTMLBody & "Char: " &
objError.Character & "<br>"
objEmail.HTMLBody = objEmail.HTMLBody & "Description: " &
objError.Description & "<br>"
objEmail.HTMLBody = objEmail.HTMLBody & "Source: " &
objError.Source & "<br>"
objEmail.HTMLBody = objEmail.HTMLBody & "Source Text: " &
objError.SourceText & "<br>"
objEmail.Send
set objEmail = nothing
set objFSO = nothing
WScript.Quit(-1)
End Sub
</script>
</job>
parrish...@gmail.com
I checked out the version numbers of CSCRIPT.EXE on a couple different
systems, and found the following:
Windows 2000 SP4: 5.6.0.6626
Windows 2003 Pre-SP1: 5.6.0.8515
Windows 2003 Post-SP1: 5.6.0.8827
Version 5.6 Download: 5.6.0.8825 (Advertised as 5.6.0.8831)
The original 5.6.0.8515 from Windows 2003 Pre-SP1 does not have the
problem I described, so a simple fix would be to just copy the Pre-SP1
files to a fully patched Post-SP1 system.
Of course there must have been a reason for the new Windows Script
releases, such as bug and security fixes, so this is obviously not a
desirable solution, so I'm still hoping there is some other work-around
available.
But for those interested, here are the files you should copy from your
Pre to Post SP1 systems (if you have a non-slipstreamed SP1 install,
you may be able to pull these files out of your
$NtServicePackUninstall$ directory):
cscript.exe
dispex.dll
jscript.dll
scrobj.dll
scrrun.dll
vbscript.dll
wscript.exe
wshcon.dll
wshext.dll
wshom.ocx
They all exist in your Windows\System32 folder. Don't forget about
copying to your DllCache folder as well, or the files will quickly be
replaced with the broken 5.6.0.8827 version.
Rick
Michael Harris (MVP)
> Hello,
>
> We've automated several tasks here with the use of Windows Scripts.
> To notify us when the tasks fail to complete, we use the
> WSHController/WSHRemote objects and catch the errors via the Error
> event. We aren't actually running the scripts remotely, they're all
> run from the same machine, but this seemed to be the easiest/best way
> to get useful error reports. We're open to suggestions of
> alternatives, if there are any.
I can repro the problem on W2K sp4 (fully patched) with WSH 5.6.0.8825. Same
results on XP pro sp2 (fully patched) same WSH version/build.
As separate *.VBS scripts...
'ControllerScript.vbs
'
Set controller = CreateObject("wshcontroller")
Set RemoteScript = controller.createscript("RemoteScript.vbs")
WScript.ConnectObject RemoteScript, "remote_"
RemoteScript.Execute
Do : wscript.sleep 1000
Loop Until RemoteScript.status <> 2
Sub remote_Error
Dim theError
Set theError = RemoteScript.Error
WScript.Echo "Error Source: " & theError.Source
WScript.Echo " Number: " & theError.Number
WScript.Echo " Hex: " & hex(theError.Number)
WScript.Echo " Description: " & theError.Description
WScript.Echo " Line: " & theError.Line
WScript.Echo " Char: " & theError.Character
WScript.Echo " SourceText: " & theError.SourceText
WScript.Quit 4001
End Sub
'RemoteScript.vbs
'
Err.raise &hf99,"RemoteScript","error " & &hf99
wscript.quit 0
Results (note error number is correct)...
Error Source: Windows Script Host Remote Script
Number: -2146824295
Hex: 800A0F99
Description: Execution of the Windows Script Host failed.
Line: 0
Char: 0
SourceText: 0x800A0F99
As a combined WSF with separate jobs...
<package>
<!-- ControllerRemoteJobs.wsf -->
<job id=1>
<script language=vbscript>
'ControllerScript
ThisScript = wscript.scriptfullname
Set controller = CreateObject("wshcontroller")
Set RemoteScript = controller.createscript(ThisScript & " //job:2")
WScript.ConnectObject RemoteScript, "remote_"
RemoteScript.Execute
Do : wscript.sleep 1000
Loop Until RemoteScript.status <> 2
Sub remote_Error
Dim theError
Set theError = RemoteScript.Error
WScript.Echo "Error Source: " & theError.Source
WScript.Echo " Number: " & theError.Number
WScript.Echo " Hex: " & hex(theError.Number)
WScript.Echo " Description: " & theError.Description
WScript.Echo " Line: " & theError.Line
WScript.Echo " Char: " & theError.Character
WScript.Echo " SourceText: " & theError.SourceText
WScript.Quit 4001
End Sub
</script>
</job>
<job id=2>
<script language=vbscript>
'RemoteScript
Err.raise &hf99,"RemoteScript","error " & &hf99
wscript.quit 0
</script>
</job>
</package>
Results...
Error Source: Windows Script Host Remote Script
Number: -2147467259
Hex: 80004005
Description: Execution of the Windows Script Host failed.
Line: 0
Char: 0
SourceText: Unspecified error
--
Michael Harris
Microsoft MVP Scripting
parrish...@gmail.com
thread that sounds like the same problem here:
http://groups.google.ca/group/microsoft.public.scripting.wsh/browse_thread/thread/77f90a7037061ec5/c8b4cfab890d7a45?lnk=raot#c8b4cfab890d7a45)
Is there a proper way to report this problem to Microsoft, so hopefully
an update can be released at some point to address the problem?
Thanks,
Rick
Paul Baker [MVP, Windows - Networking]
instructions here:
http://support.microsoft.com/
This page will also explain all the other support options. For example, you
can get technical support by phone too. You may have to pay, but it will be
free if proven to be a Microsoft bug. I am not sure what their standards are
for deciding whether or not it is free. For example, what if it's an
intentional but under-documented feature?
Paul
<parrish...@gmail.com> wrote in message
news:1164724353.6...@j72g2000cwa.googlegroups.com...