Re: WMI Win32_PerfFormattedData hosed - how to fix?

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 joseomjr@xxxxxxxxx for trying to help me figure out what was going on.

Later,
Chris


Chris Richards wrote:
Tried reinstalling service pack 2. That didn't work either.

Later,
Chris

Manbinder Pal Singh [MSFT] wrote:
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]" <manbins@xxxxxxxxxxxxx> wrote in message news:eEbpD93PHHA.1280@xxxxxxxxxxxxxxxxxxxxxxx
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" <gizmo@xxxxxxxxxxxxx> wrote in message news:%23i23aJyPHHA.856@xxxxxxxxxxxxxxxxxxxxxxx
I e-mailed them shortly after my previous post. Have you not received them yet?
Later,
Chris

Manbinder Pal Singh [MSFT] wrote:
OK. Logs please?


Thanks,
Manbinder Pal Singh

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


"Chris Richards" <gizmo@xxxxxxxxxxxxx> wrote in message news:Oyoo9UnPHHA.4156@xxxxxxxxxxxxxxxxxxxxxxx
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] wrote:
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" <gizmo@xxxxxxxxxxxxx> wrote in message news:eLp%23D3cPHHA.2340@xxxxxxxxxxxxxxxxxxxxxxx
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

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

Thanks

Later,
Chris

joseomjr@xxxxxxxxx wrote:
After you re-registered did you try running those commands? Maybe try
re-installing the service pack?


Chris Richards wrote:
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

joseomjr@xxxxxxxxx wrote:
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 wrote:
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



.

Relevant Pages

  • Re: McAfee Virus Scan In Vista
    ... Despite the fact that I uninstalled the McAfee software correctly and have ... I've run a Registry Cleaner and, despite finding a couple of hundred ... Right-click Command Prompt and Run as Administrator. ... winmgmt /salvagerepository ...
    (microsoft.public.windows.vista.general)
  • Re: Health Monitor stuck in Collecting
    ... > conflict to the Performance Monitor process. ... Check whether the performance counters are disabled. ... > Run Registry Editor by typing REGEDIT in the Run box. ... Disable WMI logging which may issue ignorable events. ...
    (microsoft.public.windows.server.sbs)
  • Re: PolAdtEv
    ... I did try posting a question about this on ... entire array instead of just the first 254 characters? ... >This is more a WMI question and not SMS related. ... tried tojsut get the data from the registry into ...
    (microsoft.public.sms.inventory)
  • Re: Msinfo32 error message
    ... I manually uninstalled all Norton registry keys ... Ramesh Srinivasan, Microsoft MVP [Windows Shell/User] ... The Winhelponline Blog: http://www.winhelponline.com/blog ... Error: WMI ADAP status. ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: Data Derived From Where?
    ... I tried testing this as well....the registry value was precisely the same ... value reported by WMI --all the way down to the 16 extra spaces to the right ... The next logical assumption is the BIOs itself. ... retrieve that data. ...
    (microsoft.public.win32.programmer.wmi)