Fixing a WMI provider load failure

I’ve been recently working with Power options on Windows for another purpose and couldn’t believe when Hyper-V MVP Niklas Åkerlund reported on his blog that the Get-CIMInstance cmdlet on Windows 2012 R2 Core edition fails to read power plans 😦

gcim -N root/cimv2/power -Class Win32_PowerPlan

Get-CimInstance : Provider load failure
+ FullyQualifiedErrorId : HRESULT 0x80041013,Microsoft.Management.Infrastructure.CimCmdlets.GetCimInstanceCommand

Ugly isn’t it? And quite unexpected…

I loved the way he solved the problem by writing functions in PowerShell that leverage the built-in powercfg.exe command. The code is available on the script center gallery on this page.

I started to look around for ways to troubleshoot WMI provider load failures and I found 3 ways:

  • using the official recommendation

It’s at the bottom on this page
So, I run

winmgmt /verifyrepository

…and it wasn’t a surprise that the WMI repository appears to be consistent. Why would it be corrupted? I’ve just loaded a test VM in Azure and removed the GUI from the server.

  • using eventlogs

It’s documented on the heyscriptingguy blog on this page

The problem is that you don’t have the wbemtest.exe and eventvwr.exe utilities on a Core edition but you have PowerShell 😀

# 1.Enable the WMI Activity log
$log = Get-WinEvent -ListLog * | Where LogName -match "WMI"

# 2. Read events from the log
Get-WinEvent $log.LogName |
Sort TimeCreated | 
Select -last 4 | 
ft -Wrap -Autosize

The WMI provider is actually loaded from the %systemroot%\system32\PowerWmiProvider.dll file but ends with a new error 0x8007007E.
While this error isn’t on the WMI Error Constants page, we still have PowerShell to help us :-D.
I’ve been using the tip that Windows PowerShell MVP Boe Prox pointed out in the comments on deciphering error codes


  • using WMI events

I’ve also tested this method that I found on this page and used the tips Windows PowerShell MVP Trevor Sullivan gave on his blog.

$myevent = @()
Register-WmiEvent -Query "Select * From MSFT_WmiSelfEvent" -Action { 
	$global:myevent += $Event 
gcim -Namespace root/cimv2/power -Class Win32_Powerplan
Get-EventSubscriber | Unregister-Event
($myevent | Sort timeGenerated).sourceEventArgs.NewEvent | 
Where Query -ne "Select * From MSFT_WmiSelfEvent" | 
Where __SUPERCLASS -ne "MSFT_WMIThreadPoolEvent"

The resultcode is 2147942526 which is actually the same error as 0x8007007E

Well, there’s another page for super advanced WMI tracing… but when in doubt, I chose to run procmon.

The Get-CIMInstance worked with the minimal server interface. When I removed the Server-Gui-Mgmt-Infra feature I had the WMI provider load failure.

With procmon, I was looking at what files the WMI process was missing.

I copied successively the following missing files back to C:\windows\system32\


And… it started to work again 😎 Long story, quick fix (not always $true, btw):


3 thoughts on “Fixing a WMI provider load failure

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.