So, back in June I discovered that my performance counter library code didn't work on my new Vista x64 development box... The problem seems to be that the code has always been doing things in an undocumented/unsupported way and it's only now that the old way doesn't actually work at all any more...
I think I know what I need to do to fix the counter installation problem, use the wonderfully unixy named "lodctr
" program (or the API alternative) to load the strings for the performance counters rather than simply shoving them into the registry myself... That means that the library code I have needs to be changed so that it writes out the appropriate files (an .ini file and a header file with #defines in it) and then calls LoadPerfCounterTextStrings()
...
So I finally have to dive into this code to make some more changes, and since I've been avoiding this for over 7 years now I expect I'll finally do it properly. I expect that means the following need to be done: bring the code into line with my coding standards, remove all of the nasty asserts
, protect the kernel objects that we use for IPC with appropriate security descriptors that make use of the new vista defined groups and add some tests.
As if by conincidence, does this have anything to do with your Vista Perflib woes? http://blogs.technet.com/markrussinovich/archive/2007/07/09/1449341.aspx
No, though I thought it would be permissions to start with. It seems like the registry key concerned is now 'special' and you cant write to it (which is good really as it was easy to screw it up and render the whole system's perfmon system inoperable).
Have you considered to use ATL for performance counters?
I did, but it's a dependency that I didn't want to introduce.
I don't think it would matter if you use ATL. ATL tries to edit the registry key directly and fails for the same reason.
Thanks, that's good to know, in a round about kinda way.
The library that I developed works well and I'm happy with it; it's much more powerful than the stuff I originally had.