Yesterday I found a nice powershell script on microsofts scripting guys site to enable or disable the network card. I decided to give the script a try and was surprised to find it didn't work as expected on my laptop.
The script gave me an awful WMI error on the win32_networkadapter. When examining the error I found that all network related wmi calls would fail with a 'provider load failure'.
Although the microsoft site does not state Vista 64-bit as a supported OS for WMIDiag I decided to give it a try (and it seemed to work).
One of the errors listed in the output of wmidiag was the following:
1 error(s) 0x80041013 – (WBEM_E_PROVIDER_LOAD_FAILURE) COM cannot locate a provider referenced in the schema
In fact this was exactly the error I received before and says nothing about the reason I got the error.
The output of wmidiag however also stated the following which can help you troubleshoot the problem further:
=> When a WMI provider fails to load, it is possible to trace the provider load process by submitting, via WBEMTEST and asynchronously, the following WMI event query:
'Select * From MSFT_WmiSelfEvent'
Then you can trace the following WMI events:
At first i had a hard time figuring out what exactly had to be done, but i figured it out and here's what to do:
Click start >> run >> wbemtest.
When WbemTest starts up the first thing you need to do is click 'Connect…' to connect to a namespace (the namespace for the win32_networkadapter is 'rootcimv2') and then click 'Connect'.
Now to track the problem we first execute the query 'Select * From MSFT_WmiSelfEvent' which will show us all current WMI-activity:
click 'asynchronous', then click 'Notification Query…' and enter the query 'Select * From MSFT_WmiSelfEvent'.
after you click apply in the query result window the query starts running and we can try to figure out what's causing my wmi-query to fail
Leave the window open and return to the main window.
We can now execute the faulting query:
click 'semisynchronous', then click 'Query…' and enter the faulting query 'select * from win32_networkadapter'.
now when you click apply in the query result window you will receive the error and you can return to the query result window for the previous query.
To track the problem scroll down to the bottom and trace the following WMI events:
In my case my query result looked like this:
I found a Msft_WmiProvider_InitializationOperationFailureEvent and a Msft_WmiProvider_LoadOperationFailureEvent.
When you doubleclick the events you will get details on the failing components which in my case looked like this:
In both cases you can see that CIMWiFiProvider is failing, and in the LoadOperationFailureEvent you can see that we have now located the dll that had been causing all my misery in 'c:progam filesintelwifibinwifiwmip.dll'. In fact i had installed the intel wifilink driver package (including software) that contained a corrupted provider(wifiwmip.dll) which molested my wmi.
After removing the package from my system and installing the 'driver only'-version from intel, this problem was gone.
This was my first post…
hope you enjoyed it. See you next time.