Generic failure

[bratton]

Hello,

I have a simple script that pulls the name of the logged on user from WMI. When I run it through AutoIT on some computers I'm getting the following error.

Desc = Generic failure

WinDesc = Variable is not of type 'Object'

Source = SWbemServicesEx

What's strange is that if I run the same code in a vbscpt it retuns the value successfully.

AutoIT Code (throws the error)

$strComputer = "."

$objWMIService = ObjGet("winmgmts:\\" & $strComputer & "\root\cimv2")

$colItems = $objWMIService.ExecQuery("Select * From Win32_ComputerSystem","WQL",48)

For $objItem in $colItems

MsgBox (0,"Username", $objItem.UserName)

Next

VBscript (returns the UserName")

On Error Resume Next

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery("Select * from Win32_ComputerSystem",,48)

For Each objItem in colItems

Wscript.Echo "UserName: " & objItem.UserName

Next

Any idea why vbscript is working, but not AutoIT? I've found some similar posts about this error, but nothing that specifically described the issue I'm seeing. Thanks in advance for the help.

[water]

Why WMI? What's wrong with the AutoIt macro @UserName?

[bratton]

This is just an example of the issue I'm seeing. The issue is not specific to this namespace or class or object. Any call I make to WMI is failing with AutoIt, but works with vbscript.

[water]

Please have a look at in the Example Scripts section. You select the Namespace and WMI Class and Scriptomatic generates the AutoIt code for you.

Edited April 25, 2013 by water

[iamtheky]

and if you run the script with the $strComputer = "localhost" ?

Edit: "." works fine on my machine, but the only way i can replicate your error is to throw a bogus string for the computer

Edited April 25, 2013 by boththose

[bratton]

Hi water,

Thanks for the link. That's an awesome tool. Unfortunately, the code it gave me threw the same error.

Hi boththose,

I tired changing it to $strComputer = "localhost" but it still failed with the same error. I also changed it to winmgmts:.rootcimv2 but that also failed.

[kylomas]

bratton,

Runs fine on my machine (Win7 x64 - Autoit 3.3.8.1) as posted in OP....

kylomas

Edited April 25, 2013 by kylomas

[water]

The only difference I see is that in VBS the "WQL" is omitted from this statement:

$colItems = $objWMIService.ExecQuery("Select * From Win32_ComputerSystem","WQL",48)

You could try to replace "WQL" in the AutoIt script with the keyword Default.

$colItems = $objWMIService.ExecQuery("Select * From Win32_ComputerSystem",Default,48)

[bratton]

Thanks kylomas. The script I have has run successfully on about 18,000 computers. It's just a handful that have this really strange issue. It's like there's some dependency for AutoIT that doesn't exist, or maybe some dll that is corrupt. I'm really stumped on this one.

[water]

If there is a problem with WMI then I would expect the AutoIt script and the VBS to crash.

Are you sure VBS runs when AutoIt crashes?

BTW: Which version of AutoIt do you run?

[kylomas]

bratton,

Of course, apologies, missed that.

Have you checked that all maintenance levels are current, there is no malware and possibly run file checker?

kylomas

[bratton]

I replaced WQL with Default and it still failed.

Yeah, I was really surprised to see the vbscipt work when AutoIT was failing, but that's exactly what's happening.

I'm using 3.3.8.1

[water]

In this case I suggest to add a COM error handler to get more information about the problem.

Add

Global $oMyError = ObjEvent("AutoIt.Error", "MyErrorHandler"

at the top of your script and

Func MyErrorHandler($__oAD_MyError)

Local $bHexNumber = Hex($__oAD_MyError.number, 8)
Local $sError = "COM Error Encountered in " & @ScriptName & @CRLF & _
     "@AutoItVersion = " & @AutoItVersion & @CRLF & _
"@AutoItX64 = " & @AutoItX64 & @CRLF & _
"@Compiled = " & @Compiled & @CRLF & _
"@OSArch = " & @OSArch & @CRLF & _
"@OSVersion = " & @OSVersion & @CRLF & _
"Scriptline = " & $__oAD_MyError.scriptline & @CRLF & _
"NumberHex = " & $bHexNumber & @CRLF & _
"Number = " & $__oAD_MyError.number & @CRLF & _
"WinDescription = " & StringStripWS($__oAD_MyError.WinDescription, 2) & @CRLF & _
"Description = " & StringStripWS($__oAD_MyError.description, 2) & @CRLF & _
"Source = " & $__oAD_MyError.Source & @CRLF & _
"HelpFile = " & $__oAD_MyError.HelpFile & @CRLF & _
"HelpContext = " & $__oAD_MyError.HelpContext & @CRLF & _
"LastDllError = " & $__oAD_MyError.LastDllError
     MsgBox(64, "COM error", $sError)

EndFunc ;==>__AD_ErrorHandler

where you like.

[bratton]

This is the COM handler I'm using now, but I'll try yours to see if it generates anything more useful. Unfortunately, I had to give the system back to the user so I won't be able to test till tomorrow.

I'll let you know in the morning if I make any progress. Thanks again for all the help so far.

$oMyError = ObjEvent("AutoIt.Error","MyErrFunc")


Func MyErrFunc()
Msgbox(0,"AutoItCOM Test","We intercepted a COM Error !" & @CRLF & @CRLF & _
"err.description is: " & @TAB & $oMyError.description & @CRLF & _
"err.windescription:" & @TAB & $oMyError.windescription & @CRLF & _
"err.number is: " & @TAB & hex($oMyError.number,8) & @CRLF & _
"err.lastdllerror is: " & @TAB & $oMyError.lastdllerror & @CRLF & _
"err.scriptline is: " & @TAB & $oMyError.scriptline & @CRLF & _
"err.source is: " & @TAB & $oMyError.source & @CRLF & _
"err.helpfile is: " & @TAB & $oMyError.helpfile & @CRLF & _
"err.helpcontext is: " & @TAB & $oMyError.helpcontext _
)
Endfunc

[water]

If the messages you posted at the top of this thread is all you get then my COM error handler won't help.

I was hoping that there was a more meaningful error and description before the message you posted.

[JLogan3o13]

I do a lot of WMI scripting in support of a client that uses Microsoft's SCCM client, and see this type of error from time to time. Have you tried doing a rebuild of WMI on the affected machine(s)?

[water]

Could you test with the latest Beta version of AutoIt (3.3.9.4)? IIRC the COM error handling has been improved.

[bratton]

Hello. Sorry it's taken me awhile to get back to this. I just wanted to provide an update that I appear to have found the root cause. This issue was only on the Dell M4700 so I decided to start disabling devices to see if there was some kind of driver conflict. As it turns out, as soon as i disabled the video driver, the script worked perfectly. I have no idea why the video driver would prevent AutoIT from enumerating WMI, but it is definitely causing the problem.

The video card is a NVIDIA Quadro K100M.

Driver version is 9.18.13.668

I'm going to upgrade the driver to see if that resolves the issue. Just thought I'd post this as an FYI in case anyone else encounters this issue. 

[jai_magical]

On 5/14/2013 at 9:48 PM, bratton said:

Hello. Sorry it's taken me awhile to get back to this. I just wanted to provide an update that I appear to have found the root cause. This issue was only on the Dell M4700 so I decided to start disabling devices to see if there was some kind of driver conflict. As it turns out, as soon as i disabled the video driver, the script worked perfectly. I have no idea why the video driver would prevent AutoIT from enumerating WMI, but it is definitely causing the problem.

 

 

The video card is a NVIDIA Quadro K100M.

Driver version is 9.18.13.668

I'm going to upgrade the driver to see if that resolves the issue. Just thought I'd post this as an FYI in case anyone else encounters this issue. 

Thank you a lot. It works.