Slow response with WMI, VB.NET when connecting to multiple PCs

[Darren Rice]

I've written a VB.NET application that scans our entire domain(7000+ pc's,
mostly Win2k SP2) and grabs hardware/software information. It scans fine
for about 800-1000 PC's, but then it runs extremely slow. When I was
investigating the problem I noticed that doing a 'netstat' from a command
prompt shows a large number(400+) of 'established' sessions. It seems like
WMI isn't releasing the RPC sessions even after I've moved on to a new PC.
The instant I stop the program, all the sessions disappear within a few
seconds. I tested connecting to a single PC and getting a single property
and I see the same results. As long as the program is open, the sessions
remain 'established' for at least 10 minutes(some several hours).

There are no errors generated, or problems with the data being returned by
WMI. So far performance is the only issue.

All my WMI calls are like the following:
Dim scope As New ManagementScope("\\" & pcinfo.pcname & "\root\cimv2")
scope.Connect()
Dim query As New SelectQuery("Win32_OperatingSystem")
Dim searcher As new ManagementObjectSearcher(scope, query)
Dim envVar As New ManagementBaseObject
For Each envVar In searcher.Get()
.......
Next

I'm doing most of my testing on a WinXP machine with all the latest hotfixs
from WindowsUpdate. I've also seen the same results running from a Win2k
SP2 Server with all available hotfixes. Some testing I did with VB6 and
it's COM objects showed similar probelms. Does anyone have any ideas what's
causing this behavior, or of possible fixes?

Darren Rice,
dri...@attbi.com
MCSE

[Ivan Brugiolo [MS]]

VB6 and anything written in Managed code
does not offer you exact control of lifetime of objects.
In Managed Code you will have to wait for the garbage collector to call the
Finalizers
(unless you call them explicitely), and the same "concept" goes for VB code.

In pure scripting, it often helps setting the variables holding interesting
resources to Nothing / null
when they are no more needed, thus taking ownership of the lifetime of
resources.
VB6 uses the same wbemdisp.dll that scripting uses, that is a wrapper on top
of the native interfaces.

Normally in C++ (and native code) is regarded as a bug not calling
IUnknown::Release
on the interface pointers returned by API
(in your case the IWbemServices proxy-manager holds a RPC binding handle,
that holds an RPC connection, that holds a socket, just to make the story
short),
but many layers of P-Code and managed code tend to make people forget about
that.

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

"Darren Rice" <dri...@attbi.com> wrote in message
news:uM17toxSCHA.1880@tkmsftngp13...