WMI Performance Adapter service start/stop

[Vadim Berman]

I have an application that registers the custom performance counters when
installed. The application runs as a Windows service and on startup it
attaches to the custom counters like this:

PerformanceCounter counter=null;
if ( PerformanceCounterCategory.Exists("name1") )
{
if ( PerformanceCounterCategory.CounterExists("name2", "name1") )
{
counter = new PerformanceCounter("name1", "name2", false);
}
}

When I am starting my service it times out and does not start. When I try to
start it the second time it starts OK, but after it is stopped it again will
not start on the first attempt.

What I found is that the Service Control Manager starts the WMI Performance
Adapter service after I tried to start my service the first time. When I try
to start my service the second time the WMI Performance Adapter is already
started and my service starts OK, but at this time the WMI Performance
Adapter service is stopped! If I start that service manually before starting
my service then my service also starts OK.

I did not establish any dependencies between my service and WMI Performance
Adapter.

If I run my application from the command line (not as a service) it works OK
whether the WMI Performance Adapter service was started or not.

Anyone has an idea about the reasons of this behavior and how to fix the
problem?

Thanks,

Vadim

[Vadim Berman]

If no one can answer this question here, could anyone recommend any more
relevant newsgroup?

Thanks,

Vadim

"Vadim Berman" <b...@alphalink.com.au> wrote in message
news:eItEB1LJ...@TK2MSFTNGP10.phx.gbl...

[Ivan Brugiolo [MSFT]]

Performance counter registration done from managed
application goes through an interesting 'registration' process under the
scenes.

To publish a performance counter you need to generate an "service
registration"
in HKLM\System\CurrentControlSet\Services\<yourservice>\Performance,
you need to call "lodctr <ServiceName>", and the the system reacts
at the "new counter event" by running the PerfLib dredger
(WmiADAP /D /T or winmgmt.exe /resyncperf PID, depending on the OS),
and then it runs an "idle task",
that will make the so called 'reverse adapter' to start as well (on WinXP
and W2K3).

The rationale is that WinMgmt re-exposes the performance
counter in the Win32_PerfXXX_YYY_ZZZ classes,
and the schema is generate at service install time, then 'lodctr' is called.
Performance counter were not schematized to begin with in 1992,
and legacy tools needs to go through the explicit query
of all the availalble data from a perflib to figure out what it provides.
The 'reverse adapter' is part of the "discovery what has just been
installed" process.

There was a QFE done for the .NET Framework (for version 1.0 IIRC)
in order to fix some problems in this area.

You may want to contact PSS with your problem,
or try to create your category in setup instead of as service startup.

--
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

"Vadim Berman" <b...@alphalink.com.au> wrote in message

news:#ZlWDjgJ...@TK2MSFTNGP09.phx.gbl...

[Vadim Berman]

Ivan,

Thank you for your response. About your recommendation "to create your
category in setup instead of as service startup" - I do create the category
in setup. The service actually hangs up (and is killed by the Service
Control Manager) on executing the PerformanceCounterCategory.CounterExists()
function (at this time the category and all counters do exist). As I wrote
in the original letter, somehow the WMI Performance Adapter service is
involved, if I start it before starting my service everything works OK, also
everything works if I start my app from the command line rather than as a
service. Strange.

As about QFE - I installed latest SPs and updates. I am not sure about where
I can find additional quick fixes.

Regards,

Vadim

"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> wrote in message
news:uvayjvsJ...@TK2MSFTNGP10.phx.gbl...

[Ivan Brugiolo [MSFT]]

The QFE was a specific one for the .NET Framework 1.0.
It solved several problems related with the Perf-Counter registration /
query.

Can you repro this in a "clean machine", not the development box, for
example ?
I don't seem to remember a hung in that place, but the code path is quite
convoluted to say what's going on from outside a debugger.

--
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

"Vadim Berman" <b...@alphalink.com.au> wrote in message

news:#2PvjfvJ...@TK2MSFTNGP10.phx.gbl...

[Vadim Berman]

Ivan,

This is reproducible on three XP machines, one of them is almost "clean".
However when I tried to reproduce the problem on a minimal example that
example worked OK. Probably something else in the application triggers this
behavior. I will try to narrow down a problem.

Thanks,

Vadim

"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> wrote in message

news:u5BSDLwJ...@TK2MSFTNGP11.phx.gbl...

[Vadim Berman]

OK, seems like I found how to fix the problem. What was wrong was that I
attached to the counters in the server initialization code, not in the
OnStart handler. When I moved the code to the OnStart handler the problem
went away. Still I do not understant why
PerformanceCounterCategory.CounterExists() does not work before the OnStart
is called.

Vadim

"Vadim Berman" <b...@alphalink.com.au> wrote in message

news:OykeRjfK...@TK2MSFTNGP12.phx.gbl...

[Ivan Brugiolo [MSFT]]

OK, this is clear.
It's because you are implicitely holding the SCM lock,
and that lock is required by SCM to start the reverse adapter.
Basically you either wait for the SCM to time out on that lock,
or you move that code somewhere else.
There are similar requirements in Un-Mananged cod not to call-back into
the SCM from a code that is executed in ServiceMain,
otherwise you are going to create multi-process deadlocks.
Similar requirements are there for not making RPC calls
or cross module blocking calls from DllMain.

--
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

"Vadim Berman" <b...@alphalink.com.au> wrote in message

news:OxKa8XgK...@TK2MSFTNGP11.phx.gbl...

[Vadim Berman]

Thank you for the explanation, Ivan. Now it is clear.

Vadim

"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> wrote in message

news:uYMfh8gK...@TK2MSFTNGP09.phx.gbl...