Use PowerShell to Troubleshoot Your Windows 7 Computer

Hey, Scripting Guy! I was recently reading something about using the Windows PowerShell troubleshooting packs that are available in Windows 7. How can I leverage this information?

—SW

Hello SW,

Microsoft Scripting Guy, Ed Wilson, here. I am officially allowed to fly again. I am so excited. I already have two trips booked; I will be flying out to Redmond, Washington to teach a couple of Windows PowerShell classes to a group of engineers that maintain our online services. I taught a class to one member of their group a couple of years ago, and they have been attempting to bring me back ever since. The cool thing is that the first week of class will correspond with the Microsoft MVP summit, so I hope to pop into that one day. My return flight actually goes through San Diego, California, which is way cool, because I love San Diego (I actually lived there for a while). If I am lucky, the airline will strand me for a few days, and I can go hang ten on some totally rad waves.

SW, speaking of totally rad, one of the more impressive things one can do with Windows PowerShell is to use the troubleshooting packs. When combined with Windows PowerShell remoting, the results can be as impressive as Oahu’s North Shore, which you can see in this photo I took a few years ago when I was in Honolulu teaching a Windows PowerShell class.

The TroubleShootingPack module is available in Windows 7. Because it is a module, it first needs to be imported into the current Windows PowerShell session. When working with modules, I first like to use the Get-Module command to see which modules are available. I use the ListAvailable switched parameter to return the information shown here.

PS C:\> Get-Module -ListAvailable

ModuleType Name ExportedCommands

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

Script BasicFunctions {}

Manifest cdc1ADmodule {}

Script ConversionModuleV6 {}

Binary DataONTAP {}

Script DotNet {}

Manifest FileSystem {}

Manifest IsePack {}

Script ISEProfileModule {}

Manifest MSI {}

Manifest PowerShellPack {}

Manifest PSCodeGen {}

Manifest Pscx {}

Manifest PSImageTools {}

Manifest PSRSS {}

Manifest PSSystemTools {}

Manifest PSUserTools {}

Manifest TaskScheduler {}

Manifest WPK {}

Manifest ActiveDirectory {}

Manifest AppLocker {}

Manifest BitsTransfer {}

Manifest FailoverClusters {}

Manifest GroupPolicy {}

Manifest IntelvPro {}

Manifest NetworkLoadBalancingCl... {}

Manifest PSDiagnostics {}

Manifest TroubleshootingPack {}

The modules that are available on any given system depend to a large extent on what options are enabled, what server roles are implemented, whether the Admin Pack tools have been installed, and whether any additional software has been installed. The previous list from my computer is typical, but it reflects the installation of various community software projects in addition to some modules that I have written myself. (By the way, CodePlex has a number of awesome Windows PowerShell projects).

When I have identified the module that I want to use (the TroubleShootingPack in this example), I need to use the Import-Module Windows PowerShell cmdlet to import the module (the cool thing about the Windows PowerShell naming convention it that quite often the names are downright intuitive). The following command imports the TroubleShootingPack module into the current Windows PowerShell session.

Import-Module -Name TroubleShootingPack

I do not need to use the Name parameter, nor do I need to spell out the entire module name if I do not want to do so. I can use positional parameters (Name is in the first position), and I can use wildcard characters to avoid spelling out the entire name. As long as there is a single match for the module name, I am OK. Therefore, I can use the Import-Module cmdlet with Tr* as indicated here to import the TroubleShootingPack module.

Import-Module Tr*

What happens if I use the T* wildcard pattern? That pattern would match both the TroubleShootingPack module on my system plus the TaskScheduler module. One might expect an error to arise. However, it does not. In fact, it loads both modules. The following code shows that the Get-Module cmdlet returns two modules.

To see which commands the module provides, I use the Get-Command cmdlet with the Module parameter. This command and the results appear here.

PS C:\> Get-Command -Module trouble*

CommandType Name Definition

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

Cmdlet Get-TroubleshootingPack Get-TroubleshootingPack [-Path...

Cmdlet Invoke-TroubleshootingPack Invoke-TroubleshootingPack [-P...

PS C:\>

The TroubleShootingPack provides only two cmdlets: Get-TroubleShootingPack and Invoke-TroubleShootingPack. Unfortunately, the troubleshooting cmdlets are a bit strange to use. For example, using Get-TroubleShootingPack by itself generates an error, as does an attempt to use a wildcard character as shown in the following screen shot.

Therefore SW, the first thing I need to know after importing the TroubleShootingPack module is what troubleshooting packs are available. On my system, all of the troubleshooting packs install into a diagnostics folder in the %SystemRoot% location (C:\Windows\Diagnostics\System). By using this information, I can use the Get-ChildItem cmdlet to list all of the available troubleshooting packs. The command to list the troubleshooting packs and the results are shown here.

PS C:\> Get-ChildItem C:\Windows\diagnostics\system

Directory: C:\Windows\diagnostics\system

Mode LastWriteTime Length Name

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

d---- 7/14/2009 1:37 AM AERO

d---- 7/14/2009 1:37 AM Audio

d---- 7/14/2009 1:37 AM Device

d---- 7/14/2009 1:37 AM DeviceCenter

d---- 7/14/2009 1:37 AM HomeGroup

d---- 7/14/2009 1:37 AM Networking

d---- 7/14/2009 1:37 AM PCW

d---- 7/14/2009 1:37 AM Performance

d---- 7/14/2009 1:37 AM Power

d---- 7/14/2009 1:37 AM Printer

d---- 7/14/2009 1:37 AM Search

d---- 7/14/2009 1:37 AM WindowsMediaPlayerConfiguration

d---- 7/14/2009 1:37 AM WindowsMediaPlayerMediaLibrary

d---- 7/14/2009 1:37 AM WindowsMediaPlayerPlayDVD

d---- 7/14/2009 1:37 AM WindowsUpdate

PS C:\>

To obtain information about a troubleshooting pack, use the Get-TroubleShootingPack cmdlet and pass the path to the folder that contains the particular pack. For example, to obtain information about the AERO Troubleshooting Pack, type the command shown here. I pipe the information to the Format-List cmdlet to see the information.

If I want to see what root causes the troubleshooting pack is able to detect, I select and expand the RootCauses property as shown here. (The following command is a single logical command. I continued the command to the next line by breaking the command at the pipe character for display on the blog).

To run a troubleshooting pack, I need to first use Get-TroubleShootingPack to retrieve an instance of a troubleshooting pack, and then I can pipe it to the Invoke-TroubleShootingPack cmdlet. If you run a troubleshooting pack from a non-elevated Windows PowerShell console, chances are that it will report that no problems are detected as shown here.

This can be really misleading. To use the troubleshooting pack to look for problems, the Windows PowerShell console needs to be run with Administrative rights. I right-click the Windows PowerShell console icon and choose “Run as Administrator” from the task list as shown here.

After I have an elevated Windows PowerShell console, I can import the module, retrieve the specific troubleshooting pack, and then invoke the troubleshooting pack. The specific commands are shown here.