WMI and multi-threading

[Tad Frysinger]

All -

I am using WbemDisp in a server process to handle WMI requests initiated
from numerous clients. I am using the SWbemLocator.ConnectServer to get
access to WMI info via ISWbemServices. Is using ISWbemServices thread-safe?

Thanks.

Tad

[Ivan Brugiolo [MSFT]]

SWbemServices is designed to be thread safe.
However, for a complex application, it may be more performant
to use the RAW IWbemServices instead
of the ole-automation compatible interface.
The main bottleneck/problems you may find
could be in the inter-apartment marshaling process.
IWbemServices pointers are free-threaded.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Post by Tad Frysinger
All -
I am using WbemDisp in a server process to handle WMI requests initiated
from numerous clients. I am using the SWbemLocator.ConnectServer to get
access to WMI info via ISWbemServices. Is using ISWbemServices

thread-safe?

Post by Tad Frysinger
Thanks.
Tad

[Tad Frysinger]

Post by Ivan Brugiolo [MSFT]
SWbemServices is designed to be thread safe.
However, for a complex application, it may be more performant
to use the RAW IWbemServices instead
of the ole-automation compatible interface.
The main bottleneck/problems you may find
could be in the inter-apartment marshaling process.
IWbemServices pointers are free-threaded.

Thanks for the tip. Did you see my other post regarding the 80020009
errors I am seeing?

I notice when I run my test on a single machine, this error does not
appear. However, when I access a computer remotely it does appear.

Any ideas?

Thx.

Tad

[Ivan Brugiolo [MSFT]]

About DISP_E_EXCEPTION, I haven't seen the message
Sorry, I'm coming back from a short vacation,
and I skipped 200 messages.
Looks like some marshaling error in the OleAutomaiton code,
but it's hard to tell without context.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Post by Tad Frysinger

Post by Ivan Brugiolo [MSFT]
SWbemServices is designed to be thread safe.
However, for a complex application, it may be more performant
to use the RAW IWbemServices instead
of the ole-automation compatible interface.
The main bottleneck/problems you may find
could be in the inter-apartment marshaling process.
IWbemServices pointers are free-threaded.

Thanks for the tip. Did you see my other post regarding the 80020009
errors I am seeing?
I notice when I run my test on a single machine, this error does not
appear. However, when I access a computer remotely it does appear.
Any ideas?
Thx.
Tad

[Tad Frysinger]

Post by Ivan Brugiolo [MSFT]
About DISP_E_EXCEPTION, I haven't seen the message
Sorry, I'm coming back from a short vacation,
and I skipped 200 messages.
Looks like some marshaling error in the OleAutomaiton code,
but it's hard to tell without context.

Here's the context:

I have written a simple test app "WMI Bridge" in VB .Net, in C#, and in
Java talking via JNI to a .dll that in turn calls wbemdisp to make the
appropriate calls, just to test various settings of WMI. It is working,
but with some caveats I am trying to understand.

When the WMI Bridge starts up, it makes a call to the WMI services
running locally on that box, to make sure it can access WMI. It does
this using a method I named 'doPollAvailability(<machine name>,
<username>, <password>). When it tries to connect locally, it uses null
for both the name and the password arguments, and passes the IP address
of the machine (I have also tried 'localhost', and the actual machine
name of my test box when I experienced the problems outlined below, all
with the same results).

This method gets a reference to an SWbemLocator object, and uses the
standard ConnectServer() call to connect to the machine name that was
passed in. If an error occcurs during this ConnectServer call, the
method returns FALSE, otherwise it returns TRUE.

When I start up this little process on an XP box, it works just fine.
doPollAvailability() returns TRUE. When I move this to a w2k server, I
get an 80020009 exception.

If I start this on the XP box, then make another call and pass the IP
address of the w2k server for it to test from the XP box,
doPollAvailability() returns TRUE for the w2k box, and in fact I can get
all sorts of info via WMI about the w2k box, as long as I ask for it
FROM the XP box, and not trying to host the WMI Bridge app ON the w2k box.

Oh, I can always get all the information I want from the XP box when
running the WMI Bridge on the XP Box, so it isn't a matter of the app
not working on a localhost arrangement - just not when localhost is a
w2k machine, evidently!

One other item that might be important: the XP box is a laptop that was
once part of a domain (but is not any longer). It is part of a workgroup
now, and the w2k server is part of this same workgroup - but it has
NEVER been part of any domain.


Any ideas?

Thx.

Tad

[Ivan Brugiolo [MSFT]]

There are quite too many factor in this configuration.
The domain-less WinXP box might be suffering the "FroceGuest" behavior
(authenticated calls are downgraded to the Null-Logon session)
Authenticated Local Connections are forbidden by WbemProx.dll.
To test how wbemdisp.dll translates this in WinXP and W2K,
you should try to run your very same code in JScript or VBScript.
[since you are using C++ code against wbemdisp,
a scripting language should be a very good test-bed]
(Use the same account to run the script that you are using for your bridge).
The W2K machine might not have the upgraded wbemprox.dll that
allows connection at Packet-Level with WinXP
(this should be in W2K-SP3, if memory serves well).

If you are using wbemdisp.dll, then please try your "algorithm" in a
scripting language.
If it reproes, please post your code and the exact scenario.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Post by Tad Frysinger

Post by Ivan Brugiolo [MSFT]
About DISP_E_EXCEPTION, I haven't seen the message
Sorry, I'm coming back from a short vacation,
and I skipped 200 messages.
Looks like some marshaling error in the OleAutomaiton code,
but it's hard to tell without context.

I have written a simple test app "WMI Bridge" in VB .Net, in C#, and in
Java talking via JNI to a .dll that in turn calls wbemdisp to make the
appropriate calls, just to test various settings of WMI. It is working,
but with some caveats I am trying to understand.
When the WMI Bridge starts up, it makes a call to the WMI services
running locally on that box, to make sure it can access WMI. It does
this using a method I named 'doPollAvailability(<machine name>,
<username>, <password>). When it tries to connect locally, it uses null
for both the name and the password arguments, and passes the IP address
of the machine (I have also tried 'localhost', and the actual machine
name of my test box when I experienced the problems outlined below, all
with the same results).
This method gets a reference to an SWbemLocator object, and uses the
standard ConnectServer() call to connect to the machine name that was
passed in. If an error occcurs during this ConnectServer call, the
method returns FALSE, otherwise it returns TRUE.
When I start up this little process on an XP box, it works just fine.
doPollAvailability() returns TRUE. When I move this to a w2k server, I
get an 80020009 exception.
If I start this on the XP box, then make another call and pass the IP
address of the w2k server for it to test from the XP box,
doPollAvailability() returns TRUE for the w2k box, and in fact I can get
all sorts of info via WMI about the w2k box, as long as I ask for it
FROM the XP box, and not trying to host the WMI Bridge app ON the w2k box.
Oh, I can always get all the information I want from the XP box when
running the WMI Bridge on the XP Box, so it isn't a matter of the app
not working on a localhost arrangement - just not when localhost is a
w2k machine, evidently!
One other item that might be important: the XP box is a laptop that was
once part of a domain (but is not any longer). It is part of a workgroup
now, and the w2k server is part of this same workgroup - but it has
NEVER been part of any domain.
Any ideas?
Thx.
Tad

[Tad Frysinger]

Post by Ivan Brugiolo [MSFT]
There are quite too many factor in this configuration.
The domain-less WinXP box might be suffering the "FroceGuest" behavior
(authenticated calls are downgraded to the Null-Logon session)
Authenticated Local Connections are forbidden by WbemProx.dll.
To test how wbemdisp.dll translates this in WinXP and W2K,
you should try to run your very same code in JScript or VBScript.
[since you are using C++ code against wbemdisp,
a scripting language should be a very good test-bed]
(Use the same account to run the script that you are using for your bridge).
The W2K machine might not have the upgraded wbemprox.dll that
allows connection at Packet-Level with WinXP
(this should be in W2K-SP3, if memory serves well).
If you are using wbemdisp.dll, then please try your "algorithm" in a
scripting language.
If it reproes, please post your code and the exact scenario.

I will do this, but note that my problem isn't authentication. I am able
to get to the box just fine - for a while (both the local box, and the
target remote box - remember when I access the local box I don't pass
any authentication). After a while (400 iterations or so) I see the
80020009 error. It appears to be "running out of memory" (whatever that
means that might cause that error) somehow on the target box. I can run
all day long locally.

Tad

[Ivan Brugiolo [MSFT]]

This seems a stress/runtime problem more than a configuration problem.
The WbemDisp code adds some Unsecapp.exe processes (in certain conditions),
and it uses far much more resources than the native IWbemService poitners.
Without seeing a debugging session at the time you see that error
I don't have much more ideas.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Post by Tad Frysinger

Post by Ivan Brugiolo [MSFT]
There are quite too many factor in this configuration.
The domain-less WinXP box might be suffering the "FroceGuest" behavior
(authenticated calls are downgraded to the Null-Logon session)
Authenticated Local Connections are forbidden by WbemProx.dll.
To test how wbemdisp.dll translates this in WinXP and W2K,
you should try to run your very same code in JScript or VBScript.
[since you are using C++ code against wbemdisp,
a scripting language should be a very good test-bed]
(Use the same account to run the script that you are using for your bridge).
The W2K machine might not have the upgraded wbemprox.dll that
allows connection at Packet-Level with WinXP
(this should be in W2K-SP3, if memory serves well).
If you are using wbemdisp.dll, then please try your "algorithm" in a
scripting language.
If it reproes, please post your code and the exact scenario.

I will do this, but note that my problem isn't authentication. I am able
to get to the box just fine - for a while (both the local box, and the
target remote box - remember when I access the local box I don't pass
any authentication). After a while (400 iterations or so) I see the
80020009 error. It appears to be "running out of memory" (whatever that
means that might cause that error) somehow on the target box. I can run
all day long locally.
Tad

[Tad Frysinger]

Post by Ivan Brugiolo [MSFT]
This seems a stress/runtime problem more than a configuration problem.
The WbemDisp code adds some Unsecapp.exe processes (in certain conditions),
and it uses far much more resources than the native IWbemService poitners.
Without seeing a debugging session at the time you see that error
I don't have much more ideas.

OK, here is a snippet of code for a VB sample that, when run (say for
100,000 iterations), shows memory consumption steadily increasing. Is
there a known problem with wbemdisp.dll leaking memory at all?

Thanks.
====

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
On Error Resume Next

If (servername.Text.Length() = 0) Then
Console.WriteLine("Enter a server name")
Return
End If
Dim counter As Integer = tfIterations.Text
For i As Integer = 1 To counter
ConnectServer(servername.Text, username.Text, password.Text)
Next i

End Sub
Private Sub ConnectServer(ByVal servername As String, ByVal
username As String, ByVal password As String)

Dim objSWbemLocator = CreateObject("WbemScripting.SWbemLocator")
If username.Length = 0 Then
username = Nothing
End If
If password.Length = 0 Then
password = Nothing
End If
Dim objSWbemServices = _
objSWbemLocator.ConnectServer(servername, _
"root\cimv2", _
username, _
password)
If (Err.Number <> 0) Then
' Handle error condition
End If
End Sub
End Class

====
Tad

[Ivan Brugiolo [MSFT]]

There aren't any know leaks in WbemDisp.
try to call

Set objSWbemServices = Nothing
Set objSWbemLocator = Nothing

at the end of the loop, inside the loop
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Post by Tad Frysinger

Post by Ivan Brugiolo [MSFT]
This seems a stress/runtime problem more than a configuration problem.
The WbemDisp code adds some Unsecapp.exe processes (in certain conditions),
and it uses far much more resources than the native IWbemService poitners.
Without seeing a debugging session at the time you see that error
I don't have much more ideas.

OK, here is a snippet of code for a VB sample that, when run (say for
100,000 iterations), shows memory consumption steadily increasing. Is
there a known problem with wbemdisp.dll leaking memory at all?
Thanks.
====
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
On Error Resume Next
If (servername.Text.Length() = 0) Then
Console.WriteLine("Enter a server name")
Return
End If
Dim counter As Integer = tfIterations.Text
For i As Integer = 1 To counter
ConnectServer(servername.Text, username.Text, password.Text)
Next i
End Sub
Private Sub ConnectServer(ByVal servername As String, ByVal
username As String, ByVal password As String)
Dim objSWbemLocator = CreateObject("WbemScripting.SWbemLocator")
If username.Length = 0 Then
username = Nothing
End If
If password.Length = 0 Then
password = Nothing
End If
Dim objSWbemServices = _
objSWbemLocator.ConnectServer(servername, _
"root\cimv2", _
username, _
password)
If (Err.Number <> 0) Then
' Handle error condition
End If
End Sub
End Class
====
Tad