#212057 - 2016-10-26 05:31 PM
Problems on Server 2008 (not R2) of late
|
Glenn Barnas
KiX Supporter
   
Registered: 2003-01-28
Posts: 4401
Loc: New Jersey
|
We've been using Kix to perform several different maintenance and monitoring tasks across about 2500 different machines. It's a broad mix - a couple of XP and 2003 systems waiting for upgrade, mostly W7, 8.1, and 10 workstations and Server 2008r2 and 2012/2012r2 platforms. The Kix utilities are running as expected on all of these. The Server 2008 platforms, however, are another story. Kix itself works fine, but the UDFs that we use to perform WMI queries are mostly failing. In particular, I'm using the WMIUptime UDF and several generic WMI queries to obtain lists of local hard drives. What is frustrating is that WMI queries made directly from our monitoring server on each subnet seem to work properly.
The Kixforms.dll (latest ver) is also having problems on the Server 2008 platforms - we can register it fine (apparently). I have test code that simply instantiates the DLL, which works, but when I run a utility that actually uses the DLL functionality, it throws an error dialog box: "Windows - Unable To Locate Component", followed by "Exception Processing Message 0xc0000135" followed by parameters when the DLL is instantiated.
$SYSTEM = CreateObject('Kixtart.System')
If VarType($SYSTEM) <> 9 or @ERROR
If Exist(@SCRIPTDIR + '\kixforms.dll')
Shell 'RegSvr32 /s ' + @SCRIPTDIR + '\KixForms.dll'
$SYSTEM = CreateObject('Kixtart.System')
If VarType($SYSTEM) <> 9 or @ERROR
fError('Unable to register and instantiate KF.DLL', 1)
EndIf
Else
fError('KF.DLL is not present', 2)
EndIf
EndIf This is the basic logic I use to verify that Kixforms.dll is present and can be used.
I'm still digging into the issue, but if anyone has seen this and shed more light on the issue, it would be greatly appreciated.
Glenn
_________________________
Actually I am a Rocket Scientist!
|
|
Top
|
|
|
|
#212059 - 2016-10-27 09:14 AM
Re: Problems on Server 2008 (not R2) of late
[Re: Allen]
|
Arend_
MM club member
   
Registered: 2005-01-17
Posts: 1896
Loc: Hilversum, The Netherlands
|
I agree with Allen, try updating Visual C++
|
|
Top
|
|
|
|
#212070 - 2016-11-03 09:29 PM
Re: Problems on Server 2008 (not R2) of late
[Re: Lonkero]
|
Glenn Barnas
KiX Supporter
   
Registered: 2003-01-28
Posts: 4401
Loc: New Jersey
|
OK - so did some digging on this today. One of the disk space monitors was failing to collect WMI data. I knew that the code was pretty much right out of KOM, so I copied the raw KOM source to the machine and damned if it didn't work!Break On
$oWMIService = GetObject("winmgmts:\\.\root\cimv2")
$cItems = $oWMIService.ExecQuery("Select * from Win32_Volume",,48)
For each $oItem in $cItems
"Capacity: " + $oItem.Capacity ?
"Caption: " + $oItem.Caption ?
Next The only change from direct KOM output was hard coding the "." and changing the 3-char variable prefix to a single char.
So - what's different from my code???
Well, good code practices , for one.. I declare my vars and set strict options. I inserted the following after the Break On statement:Dim $Rc, $objWMIService, $colItems, $objItem, $Item
$Rc = SetOption('Explicit', 'On')
$Rc = SetOption('WrapAtEOL', 'On')
$Rc = SetOption('NoVarsInStrings', 'On')
$Rc = SetOption('NoMacrosInStrings', 'On')
$Rc = SetOption('WOW64FileRedirection', 'Off')
$Rc = SetOption('WOW64AlternateRegView', 'Off') Sure enough, the @SERROR now reports "Invalid Syntax" and the script dies with a totally misleading error:ERROR : expected ')'!
Script: C:\KRMMwork\Bin\z.bms
Line : 14 Eliminating the WOW64FileRedirection option resolved the problem. WTH??
Any thoughts on this? This issue only exists on Server 2008, works fine on Server 2008R2 and higher.
Glenn
_________________________
Actually I am a Rocket Scientist!
|
|
Top
|
|
|
|
Moderator: Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart
|
0 registered
and 601 anonymous users online.
|
|
|