New error just started happening

[Rick Parrish]

Hello, this weekend we just started having some of our scheduled tasks
fail with with an error number of "0x80070050" and a description of
"The file exists.". The line number is 0, so it's not pointing to a
particular line of code in our program.

Only tasks running remotely via the WSHController object seem to be
affected. And once this happens to one scheduled task, all subsequent
scheduled tasks also fail until the machine is rebooted (well the ones
running via WSHController anyway)

Anyone else experiencing this, or know what file the error may be
talking about? None of our tasks directly create files, so we're a
little stumped.

Thanks,
Rick

[Pegasus [MVP]]

"Rick Parrish" <parrish...@gmail.com> schrieb im Newsbeitrag
news:950c58ac-fff1-489a...@f16g2000yqm.googlegroups.com...

You need to supply more information:
- Where exactly did you see this message?
- What does the Task Scheduler log file report?
- What do you invoke with the Task Scheduler? A VB Script file? A batch
file? An executable?
- What do you get when you invoke a really simple task, e.g. the batch file
below:
@echo off
echo %date% %time% %UserName% >> "%temp%\test.log"

[Rick Parrish]

Thanks for the reply. Here's a little more information:

> You need to supply more information:
> - Where exactly did you see this message?

As mentioned we're running the scripts remotely via the WSHController
object. When the Remote_Error sub fires, we have a look at the
RemoteScript.Error property, and that's where we're seeing the given
error number, line number, and description

> - What does the Task Scheduler log file report?

It starts at the top of the hour, and returns with an exit code of
ffffffff roughly 90 seconds later (when completing successfully, it
should take less than 10 seconds).

> - What do you invoke with the Task Scheduler? A VB Script file? A batch
> file? An executable?

A windows scripting host script. We directly execute our
WSHController.wsf script (I'll include the code below), which then
executes OurTask.wsf

> - What do you get when you invoke a really simple task, e.g. the batch file
> below:
> @echo off
> echo %date% %time% %UserName% >> "%temp%\test.log"

Everything that does not run through our WSHController.wsf script
works fine. And this setup has been working fine for years until this
past weekend. I'm wondering if a patch broke something, which is why
I thought I'd check to see if others are having this issue.

Here's the WSHController.wsf script:

<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>

[Pegasus [MVP]]

"Rick Parrish" <parrish...@gmail.com> schrieb im Newsbeitrag

news:dc504540-cd04-4ca0...@e20g2000vbb.googlegroups.com...

> Thanks for the reply. Here's a little more information:
>
>> You need to supply more information:
>> - Where exactly did you see this message?
>
> As mentioned we're running the scripts remotely via the WSHController
> object. When the Remote_Error sub fires, we have a look at the
> RemoteScript.Error property, and that's where we're seeing the given
> error number, line number, and description
>
>> - What does the Task Scheduler log file report?
>
> It starts at the top of the hour, and returns with an exit code of
> ffffffff roughly 90 seconds later (when completing successfully, it
> should take less than 10 seconds).
>
>> - What do you invoke with the Task Scheduler? A VB Script file? A batch
>> file? An executable?
>
> A windows scripting host script. We directly execute our
> WSHController.wsf script (I'll include the code below), which then
> executes OurTask.wsf

Sorry, I plead profound ignorance when it comes to WSH Controller scripts.

[DLKirchmer]

On Dec 14 2009, 11:59 am, Rick Parrish <parrish.rich...@gmail.com>
wrote:

> . . .

> Everything that does not run through our WSHController.wsf script
> works fine.  And this setup has been working fine for years until this
> past weekend.  I'm wondering if a patch broke something, which is why
> I thought I'd check to see if others are having this issue.

> . . .

Above you state " I'm wondering if a patch broke something, which is

why
I thought I'd check to see if others are having this issue."

The error message you supplied is coming from WinRM

D:\>winrm helpmsg 0x80070050
The file exists.

Did your organization apply the "December Patch Tuesday" security
updates over that weekend?

MS09-069 Vulnerability in Local Security Authority Subsystem Service
Could Allow Denial of Service (974392)
MS09-070 Vulnerabilities in Active Directory Federation Services Could
Allow Remote Code Execution (971726)
MS09-071 Vulnerabilities in Internet Authentication Service Could
Allow Remote Code Execution (974318)
MS09-072 Cumulative Security Update for Internet Explorer (976325)
MS09-073 Vulnerability in WordPad and Office Text Converters Could
Allow Remote Code Execution (975539)
MS09-074 Vulnerability in Microsoft Office Project Could Allow Remote
Code Execution (967183)

Most deal with "Remote Code Execution" and that appears to cover the
process you have described for your scripts.

If this process has been working for years and nothing in the process
has changed but something in the environment did change then remove/
rollback the changes in the environment, one-by-one, in the reverse
order of which they were applied to determine the root cause of your
observed change in expected behavior/outcome. Once you believe you
have determined what change in the environment caused the unexpected
results in your process that has been working for years, re-apply that
change to validate your hypothesis and remove it again to re-validate
your original findings. If you cannot work on production systems to
perform these tests, restore a backup from when the process was
working to a VM and use that for your testing steps. You might also
capture via tracing or ProcMon logging everything that happens when it
works properly, re-apply the change that breaks it and re-capture
everything again to determine where the "break" is being introduced.

Please update the thread with any results (positive or negative)

Thanks,

David