views:

230

answers:

1

I just executed installutil on a DLL in which custom performance counters are installed. I installed 2 categories but then realized I had an issue with the first category, so I deleted the category but before deleting I ran an asp.net app against to make sure it was working.

The issue is after deleting the category and then recreating the application is logging to the custom perfmon counter but the values never get updated.

The second custom category works fine and counter is getting populated. I can see both categories within perfmon but noticed that the first category counters never get updated when running an asp.net against it.

Has anyone run into this issue. Do I need to delete the existing instance? I'm trying to avoid a reboot of the machine.

+1  A: 

depending on how you install the counter, (assuming transacted installation let's say...) perf counters can get "orphaned".

IMHO this is because perf counters seem to get installed in the Reg and "elsewhere" <--still trying to find out where else perf counter info gets stored.

In some cases, the regkeys get built appropriately and so register as appropriate but the OS "elsewhere" location is not properly built out. It's almost like there is a perfcounter cache somewhere. ( comments anyone?)

So in summary after installation run lodctr /R from the commandline with the appropriate perms and this "seems" to solve the issue for most installations. I would be interested to see what others say about this as the generally available documentation (i.e. MS) SUCKS beyond belief on this topic...

grrr.

Thanks... I ended up rebooting and now the counter data gets updated properly. But I have another issue. When I run the wbemtest to verify the class, the class is there but currently no instances. So when I query the object using wmi, no counter data is being returned. So now I'm investigating how why the instance is not there.