tags:

views:

517

answers:

2

I have an interesting/annoying problem with some VBScripts running on Windows 2003 Server (they run fine on XP).

The scripts basically periodically call WMI objects to extract performance information and write it to a log file. It's started by Scheduled Tasks at 12:05 each morning and runs until midnight (or would if it didn't keep crashing). It's owned by Administrator and the task is "cscript xx.vbs blah blah blah".

Sometimes it runs for hours, sometimes only a few minutes. The calls are of the form:

set objWMI = getObject("winmgmts:\\.\root\cimv2")
:   :   :
do lots of times:
    set itemCpu = wmi.get("Win32_PerfRawData_PerfOS_Processor.Name='_Total'")

The error it comes back with is a dialog box stating that the remote procedure call failed to execute but no extra information (it does give a 32-bit hex number and I'll update this question with it next time it happens but my Google searches turned up very generic pages so I'm not sure the code will help).

It also used to crash out (same error) with the following line but I haven't seen a problem with this one since I changed it to use Win32_Perf Raw Data_PerfOS_Memory.

set colMem = wmi.execQuery("select AvailableKBytes" & _
    " from Win32_PerfFormattedData_PerfOS_Memory",,48)

I gather it's not network-related since it's on the same machine.

I've also tried to set objWMI to nothing and do another getObject every time through the loop but that didn't help.

One other possible problem, it's actually running inside VMWare Workstation (but so is the XP) - next week I'll get a physical-PC setup of Win2k3 running to test it there.

The strange thin is, it sometimes runs for hours without problems, collecting the data and sending it to the log file. Other times, it crashes in ten minutes.

Any ideas from the Windows gurus out there among us?

UPDATE:

Okay, it finally failed again. Here's my little effort at screen capture:

+-------------------------------------------------+
|  Windows Script Host                          |X|
+-------------------------------------------------+
|  \/   Script:   C:\Program Files\blah\blah.vbs  |
|  /\   Line:     271                             |
|       Char:     2                               |
|       Error:    The remote procedure call       |
|                 failed and did not execute.     |
|       Code:     800706BF                        |
|       Source:   SWbemServicesEx                 |
+-------------------------------------------------+

Line 271 is:

set itemCpu = wmi.get("Win32_PerfRawData_PerfOS_Processor.Name='_Total'")

with wmi having been previously set with:

set wmi = getObject("winmgmts:\\.\root\cimv2")

(this one is continuously being re-created inside the loop, so I don't think it's an issue with the RPC connection going stale).

+1  A: 

The error 1722(0x6BF) is : The RPC server is unavailable.

One suggestions : free all objects explicitly in your script

To perform best diagnose try to sniff your network using Microsoft Network Monitor 3.2 and search for issue.(view this help How to capture network traffic with Network Monitor)

Good look.

lsalamon
Turns out this was partially the fix. There were a couple of objects which weren't explicitly freed, although I though they would be when the variables were assigned with something else or went out of scope. The other half of the problem was hitting WMI as hard as possible.
paxdiablo
When I explicitly freed all objects as soon as I was finished with them AND only queried WMI once every ten seconds, the problem went away. Well, it might still be there but my process restarts every midnight so the running slow bit may just make it happen every 25 hours instead of three-ish :-)
paxdiablo
So, +1 and accept. You helped me avoid having to rewrite the thing in C.
paxdiablo
+1  A: 

If your script is checking any user accounts when it runs take a look at this hotfix. It only a problem on 2003 which may explain why it works fine on your XP system.

http://support.microsoft.com/kb/933593

It was causing some random problems for us at work that didn't entirely fit the description in the article but the hotfix did fix our problems.

Jerb
@Jerb, +1 for the info but it didn't fix the specific problem I was having.
paxdiablo