Use PowerShell to Troubleshoot “Provider Load Failure”

Summary: Microsoft Scripting Guy, Ed Wilson, shows how to use Windows PowerShell to troubleshoot a “provider load failure.”

Hey, Scripting Guy!

I ran across what may be an interesting issue for you. In one of our audit scripts last night, we received the following error:

Test-Connection : Provider load failure 

At SomePowerShellScript.PS1:26 char:24

+     if (test-connection <<<<  $srv -q -count 1) {

    + CategoryInfo          : InvalidOperation: (:) [Test-Connection], ManagementException

    + FullyQualifiedErrorId : TestConnectionException,Microsoft.PowerShell.Commands.TestConnectionCommand

What provider does Test-Connection use? I'm trying to research the failure. I know that another scan, which uses compiled code, did a whole slew of ping sweeps after this failed, so I don't think the problem is at a network/network interface layer. Also, with no changes to the system, the scripts ran fine this morning.

I've done a few Internet searches for the issue and have gotten no closer, hence the email to the guru.

Sincerely, 

BK

Microsoft Scripting Guy, Ed Wilson, is here. I am still in Redmond, Washington today. This morning I am going to have coffee (well, maybe just a cup of tea) with the scripting manager. So I am sitting in the building 43 coffee shop, working through my email. Lo and behold! I look up, and it is Jeffrey Snover coming over to say hi to me! We chat about the Hey, Scripting Guy! Blog for a bit, he confirms our meeting for this afternoon, and he heads off to his first meeting of the day. Wow. I know I have said this before (probably even yesterday), but I LOVE my job!

First find the provider

BK, I happen to know that the Test-Connection Windows PowerShell cmdlet uses the Win32_PingStatus WMI class to perform the ping. I found this out by using the Get-Help cmdlet to look up Test-Connection. In the description, it says that the cmdlet returns an instance of the Win32_PingStatus WMI class. This is shown in the image that follows.

To find the provider of a WMI class, there are several approaches. Perhaps the easiest way is to use wbemtest. This is shown here.

Another way to find the provider of a WMI class is to use the Get-CimClass cmdlet as shown here.

PS C:\> Get-CimClass win32_pingstatus | select -expand cimclassqualifiers

Name                                 Value              CimType                Flags

----                                 -----              -------                -----

dynamic                               True              Boolean ...rride, ToSubclass

provider                   WMIPingProvider               String ...rride, ToSubclass

When I know the WMI class and the WMI provider, there are a couple things I can do. I can look the information up on MSDN. The WMIPingProvider and the Win32_PingStatus class are both documented.

Start a trace

With the name of the WMI provider and the name of the WMI class, it is time to start a trace log. I have written a week’s worth of Hey, Scripting Guy! Blogs about this, and you should review those posts for fundamental concepts. Here are the steps:

1. Open the Windows Event Viewer utility.
2. On the View menu, check Show Analytic and Debug Logs.
3. Navigate to Microsoft/Windows/WMI-Activity.
4. Right-click the Operational log, and select Enable Log from the Actions menu.
5. Right-click the Trace log, and select Enable Log from the Actions menu.

Wait for the problem to occur again

BK, now you need to wait for the problem to surface again. When the error occurs again, go back to the Event Viewer utility, navigate to the WMI-Activity log, and search through the Operational logs and Trace logs. Hopefully, you will be able to find what is causing the problem. If not, you need to enable the Debug log by using the previous procedure. Unfortunately, the Debug logs require expert WMI skills and detailed knowledge that is rarely found outside of Microsoft Customer Service and Support (CSS). Therefore, you would need to open a case with Microsoft CSS to get to the root cause.

Join me tomorrow when I will talk about more cool Windows PowerShell stuff.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy