WMI Win32_PerfFormattedData hosed - how to fix?

[Chris Richards]

I've been working on an ATL client to talk to WMI.

In the course of working on this, I was investigating the
Win32_PerfFormattedData_PerfOS_Processor class and had started getting
some data under the debugger when I lost power.

When I came back up, my WindowsXP machine appeared to come up clean
(didn't try to run chkdsk on the way up) but just to be sure I manually
ran chkdisk to check for problems. None were reported.

Since the crash, I haven't been able to get data on
Win32_PerfFormattedData_PerfOS_Processor,
Win32_PerfRawData_PerfOS_Processor, or indeed any of about 24 total
classes in these same families. WMIDiag reports an error 0x80041010
enumerating these classes. I have tried repairing the WMI registry by
following the instructions listed at
http://windowsxp.mvps.org/repairwmi.htm but have had no luck. All of
the classes that are giving me problems appear to belong to wmicookr.dll
(which exists in %systemroot%\system32\wbem and which I have
re-registered) and are enumerated in WMI.MOF (which also exists, and
which I have also re-registered).

I'm at a complete loss here, and I do NOT want to have to reinstall this
entire machine just so I can fix this.

One other observation is that I have a little program which enumerates
the performance registry keys in the Performance Registry Interface.

Prior to this crash, I had a whole huge list of keys. Since this crash,
I have many fewer keys, and the last key enumerated appears to only be
partially there.

Any help, ideas, suggestions, pointers? I've been fighting with this
for two days. This does not seem to be a unique problem either. I've
seen numerous references to the 0x80041010 error, or 0x80041002, which
I've also seen, without any successful resolutions.

Thanks in advance

[jose...@gmail.com]

You can always try deleting the repository data which WMI will rebuild
on its own from the MOF files.

C:\WINDOWS\system32\wbem\Repository\FS

[Chris Richards]

I deleted the entire Repository directory and all subdirs. Didn't fix
the problem.

I tried the instructions at

http://windowsxp.mvps.org/repairwmi.htm

again, and now the 24 classes that I was having trouble with don't even
show up at all. ARG!!!

Thanks for the response.

Later,
Chris

[jose...@gmail.com]

Have you tried the following cmd:
mofcomp -N:root\cimv2 wmi.mof

[jose...@gmail.com]

These cmd's have helped me in some situations too:

winmgmt /clearadap
winmgmt /kill
winmgmt /unregserver
winmgmt /regserver
winmgmt /resyncperf

[Chris Richards]

I've done the /clearadp and /kill. I've also unregistered and
re-registered the server. I haven't tried the /resyncperf, but somehow
I don't think that's going to help.

I was digging through the mofcomp.log and came across this:

(Thu Jan 18 12:25:52 2007.1241109) : Compiler returned error
0x8004400a(Thu Jan 18 13:04:26 2007.3555343) : Parsing MOF file: wmi.mof
(Thu Jan 18 13:04:27 2007.3555921) : Finished compiling file:wmi.mof
(Thu Jan 18 13:04:27 2007.3555968) : Done!
(Thu Jan 18 13:04:31 2007.3559671) : Parsing MOF file: wmi.mfl
(Thu Jan 18 13:04:31 2007.3559703) : Finished compiling file:wmi.mfl
(Thu Jan 18 13:04:31 2007.3559734) : Done!

I suspect there is something wrong with the wmi.mof file and that lies
at the heart of my problems.

[jose...@gmail.com]

Try checking it:
mofcomp -check C:\WINDOWS\system32\wbem\wmi.mof

I wonder if the problem is with the MOF file itself or something else.
Maybe try copying the MOF file from a known good.

[Chris Richards]

Did that. File parsed fine. So then I did

mofcomp c:\windows\system32\wbem\wmi.mof

and it parsed fine and said it was loading the data into the registry.
The problem persists, though. Hmm.........

[Chris Richards]

Ok, maybe we are attacking this problem from the wrong end.

It doesn't look like ANY of the classes that are provided via
wbemperf.dll or wmicookr.dll are in the registry.

I've done:

regsvr32 wbemperf.dll

and

regsvr32 wmicookr.dll

and both commands completed successfully.

So, any ideas on what could be allowing the DLLs to successfully
register, yet prevent the class information from properly registering?

BTW, thanks for all your help so far.

Later,
Chris

[jose...@gmail.com]

After you re-registered did you try running those commands? Maybe try
re-installing the service pack?

[jose...@gmail.com]

After you re-registered did you try running those commands? Maybe try
re-installing the service pack?

[Chris Richards]

Yes, I did try rerunning the commands. I haven't tried reinstalling the
service pack. I'll give that a shot.

Thanks

Later,
Chris

[Chris Richards]

Well, reinstalling the service pack didn't fix it either.

I guess I'm going to have to break down and spend $200 to call
Microsoft. :(

Later,
Chris

[Manbinder Pal Singh [MSFT]]

I would recommend you to try again the following steps.
1. Clean all logs ( delete all ) and event log after taking backup in case
you need it laters.
2. net stop winmgmt and net start winmgmt
3. see if the above two fixes your problem
4. Otherwise try each operatino below one by one and see the logs and the
event log and tell if there is any winmgmt or ADAP message.
5. winmgmt /clearadap
6. winmgmt /resyncperf

Send the wmiadap.log , winmgmt log and if any events are there in event log.

Thanks,
Manbinder Pal Singh

This posting is provided "AS IS" with no warranties, and confers no rights.

"Chris Richards" <gi...@aoaforums.com> wrote in message
news:eLp%23D3cPH...@TK2MSFTNGP05.phx.gbl...

[Chris Richards]

Thank you.
I have tried the items mentioned below with no success. I am sending
you the logs as requested.

Later,
Chris

[Manbinder Pal Singh [MSFT]]

OK. Logs please?

Thanks,
Manbinder Pal Singh

This posting is provided "AS IS" with no warranties, and confers no rights.

"Chris Richards" <gi...@aoaforums.com> wrote in message

news:Oyoo9UnP...@TK2MSFTNGP03.phx.gbl...

[Chris Richards]

I e-mailed them shortly after my previous post. Have you not received
them yet?

[Manbinder Pal Singh [MSFT]]

Yes I got them now and i jsut had a first glance it. Your log suggests that
the adap process failed for some libraries. I will try to see and dig
further deep sometime and let you know.

Thanks,
Manbinder Pal Singh

This posting is provided "AS IS" with no warranties, and confers no rights.

"Chris Richards" <gi...@aoaforums.com> wrote in message

news:%23i23aJy...@TK2MSFTNGP05.phx.gbl...

[Manbinder Pal Singh [MSFT]]

Starting with ContentFilter library all the subsequent libraries failed and
PerfOS and PerfNet being one of those and so you dont get the data what you
want.

Only which passed were

.NET CLR Data performance

.NET CLR Networking

.NET Data Provider for Oracle

.NET Data Provider for SqlServer

.NETFramework

ASP.NET libraries

aspnet_state

VerifyLoaded fails for all the failing libraries and subsequent failures
may be because of that

Constructing the PerfOS performance library wrapper.

(Mon Jan 22 16:26:25 2007.70788859) : VerifyLoaded for PerfOS hr = 80041001.

(Mon Jan 22 16:26:25 2007.70788859) : Construction of the PerfOS perflib
wrapper failed hr = 80041001.

(Mon Jan 22 16:26:25 2007.70788859) : CAdapPerfLib::EndProcessingStatus()...

(Mon Jan 22 16:26:25 2007.70788859) : Destructing the PerfOS performance
library wrapper.

(Mon Jan 22 16:26:25 2007.70788859) : CPerfLibSchema::Initialize for PerfOS
hr 80041001

(Mon Jan 22 16:26:25 2007.70788859) : ProcessLibrary ForceStatus for PerfOS
hr = 80041001

(Mon Jan 22 16:26:25 2007.70788859) : ProcessLibrary ForceStatus for PerfOS
hr = 80041001

Let me dig more as when it can fail with 80041001. Thank for your patient.

Thanks,
Manbinder Pal Singh

This posting is provided "AS IS" with no warranties, and confers no rights.

"Manbinder Pal Singh [MSFT]" <man...@microsoft.com> wrote in message
news:eEbpD93P...@TK2MSFTNGP04.phx.gbl...

[Chris Richards]

I realize you are probably working on this in your spare time, so I
don't wish to push. :)

However, I was curious if you were able to find out anything further on
this issue?

Thanks in advance for your time.

[Chris Richards]

Tried reinstalling service pack 2. That didn't work either.

[Chris Richards]

AHA! I FINALLY got it fixed!

Symptom: A significant portion of the Win32_PerfRawData and
Win32_PerfFormatedData WMI derived classes were returning 80041001,
80041002, or 8004100a when I tried to access them. In some cases, the
classes were missing entirely. In other cases, they were there but not
working right.

Here's what I had to do.

First, my performance registry was hosed (the performance registry is
the interface that WMI uses to get a good deal of its information, in
fact, it might get ALL of its info from there, I'm not sure). To fix
the performance registry, I had to basically pull it out by its roots
and reinstall it.

*********WARNING*********
//the following contains information on editing system files and the
//registry. If you don't know what you are doing, you can turn your
//system into a doorstop in a heartbeat! When you do, don't come crying
//and sniveling to me; I will have no sympathy.
*******END WARNING*******
0. Backup up your copies of the perfc009.dat and perfh009.dat located in
your %Systemroot%\System32 folder. For non-english systems, the '009'
might be something else, as these files are localized for each system.

0a. If you have ANY reason to suspect that some of your service pack,
patch, update, or hot fix files might have been replaced, reapply the
relevant service packs, patches, updates, and hotfixes. In fact, you
probably should do that anyway, just to be safe.

0b. Find all ini files used to load performance counters. The easy way
to do this is to use the following command from a command prompt at the
root of your system drive, and also the root of your 'Program Folders'
drive, if you run a split configuration like me:
findstr /i /s /c:"drivername" *.ini

Unfortunately, findstr doesn't handle files that start with the unicode
Byte Order Mark (FF FE or FF FF). Neither did any of several different
grep utilities for windows that I tried. I finally ended up using a
great little text editor called TextPad32. It has a 'Find in Files'
feature that knows how to handle the Unicode BOM.

Make a note of all the files you find. You'll need this information later.

1. Get your original install CD, go the i386 folder, and extract the
files perfc009.da_ and perfh009.da_. For help on using extract, just type:
extract
at the command line. Extract these files and replace the ones in
%Systemroot%\System32.

2. Start your favorite registry editor. Look for the following registry
key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Perflib

3. In the registry, change the LastCounter value to 1846 (decimal,
0x0736 Hex). Change the LastHelp value to 1847 (decimal, 0x0737 Hex).

4. Look for the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services. This is the
services registry hive. Look through each service key in turn, looking
for any service keys that have a subkey named 'Performance'.

5. For each service key that has a performance subkey, delete the
following value names:
FirstCounter
FirstHelp
LastCounter
LastHelp

This will get you back to a base performance registry set. You now have
only basic performance counters. Any extended counters will need to be
manually added.

6. For each INI file identified in step 0b do the following:
From a command prompt, CD to the directory containing the relevant INI
file. Type the following command:
lodctr inifile
where inifile is the name of the ini file that you wish to load.

Note: Some of these may respond with an error 2 that they couldn't be
loaded because the relevant registry key can't be opened. Generally,
this is because the service doesn't exist. If you encounter this, check
the relevant services registry key for the INI file you are loading (you
can determine the service registry key by opening the INI file and
looking at the [info] section for the entry called 'drivername' and
seeing what it is set to). If the service is in fact not installed,
then there most likely isn't a problem. However, I did find that in
particular, MSSQL has a default INI file called sqlctr.ini. This tries
to install counters for the default MSSQLServer service, which won't
exist. However, there WILL BE INI files for each MSSQL instance that is
running. Also, there will be a bunch of INI files that are in your
Service Packs directory, and possibly also in the folders for each of
the installed Windows patches. So long as your running installation is
current with all of the service packs, updates, patches, and hot-fixes
that it is supposed to have, these can be safely ignored.

Rinse and repeat for every perf counter file that you need to have enabled.

7. Reboot.

8. If you come back up and your performance registry still is showing
all the objects it should, some of them may have gotten disabled because
the performance registry was hosed previously. There are two ways to
fix this:
8a. You can manually search through the performance subkeys of all
the service keys in the services registry
(HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services). Look for a
value name called Disable Performance Counters. If it is set to any
value other than 0, the Performance Counters for that service have been
disabled and will have to be re-enabled by setting the entry back to 0
and rebooting the system.
8b. Install the Support Tools for your platform (they should be on
your install media; you can also download them from Microsoft). Run the
Exctrlist.exe tool, and use it to re-enable any disabled performance
counters.

9. Reboot again. At this point, your performance counter registry
should be restored to normal operation, but WMI will probably still be
hosed.

Note: The above information is based on information found at
http://support.theplanet.com/knowledgebase/users/kb.php?id=10089

Now, to fix your WMI:
10. From Start|Run or a command line, type:
net stop winmgmt

11. Go to %Systemroot%\System32\wbem. Delete the Repository directory
and all of its contents.

12. From Start|Run or a command line, type:
net start winmgmt

13. From a command line, cd %SystemRoot%\system32\wbem
Type the following commands:
for %i in (*.dll) do regsvr32 -s %i
for %i in (*.exe) do %i /RegServer

(Note that none of the above will restore files that are actually
MISSING from your WMI installation.

The information above is based on information found at:
http://windowsxp.mvps.org/repairwmi.htm

Finally, if that doesn't get your WMI back in working order, do the
following:

14. winmgmt /clearadap

15. winmgmt /resyncperf

16. Reboot

At that point, you should hopefully have a fully repaired Performance
Counters Registry, and a fully repaired and functional WMI. That's what
it took for me. I really hope this helps someone else.

Thanks to Manbinder Pal Singh and jose...@gmail.com for trying to help
me figure out what was going on.

[jose...@gmail.com]

I'm glad you found a solution to this and thank you for sharing your
findings. I am sure this will prove useful to others and may come in
handy in the future.