Summary: Learn how to use Windows PowerShell to simplify troubleshooting your Windows 7 or Windows Server 2008 R2 computers.

  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.

NOTE: this is the first of four articles that talk about using the Troubleshooting Modules. Todays article talks about finding the troubleshooting module, and the troubleshooting packs. Tommorow’s article discusses automating the troubleshooting process via an answer file. On Wednesday I discuss using the troubleshooting packs to diagnose remote problems, and on Thursday I talk about using PowerShell and Scheduled Tasks to automate troubleshooting.

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.

PS C:\> Import-Module T*

PS C:\> Get-Module

ModuleType Name ExportedCommands

———- —- —————-

Manifest troubleshootingPack {Get-TroubleshootingPack, Invoke-Troubleshoo…

Script TaskScheduler {Remove-Task, Get-ScheduledTask, Stop-Task, …

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.

PS C:\> Get-TroubleshootingPack -Path C:\Windows\diagnostics\system\AERO | Format-List

Path : C:\Windows\diagnostics\system\AERO

Id : AeroDiagnostic

Version : 1.0

Publisher : Microsoft Windows

Name : Aero

Description : Display Aero effects such as transparency.

MinimumVersion : 6.1

PrivacyLink : http://go.microsoft.com/fwlink/?LinkId=104288

SupportsClient : True

SupportsServer : True

SupportsX86 : True

SupportsAmd64 : True

SupportsIA64 : True

RequiresElevation : True

Interactive : True

RootCauses : {Mirror drivers don’t support Aero effects, Aero effects not sup

ported on this Windows edition, Video card doesn’t support requi

red display settings, Video card driver doesn’t support Aero eff

ects…}

FoundRootCauses :

Interactions : {This troubleshooter can’t run in a Remote Desktop session}

ExtensionPoint : #document

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).

PS C:\> Get-TroubleshootingPack -Path C:\Windows\diagnostics\system\AERO |

Select-Object -ExpandProperty RootCauses

Name

—-

Mirror drivers don’t support Aero effects

Aero effects not supported on this Windows edition

Video card doesn’t support required display settings

Video card driver doesn’t support Aero effects

Color depth is set too low

Desktop Window Manager Session Manager service isn’t running

Themes service isn’t running

Current power settings don’t support Aero desktop effects

Desktop Window Manager is disabled

Transparency is disabled

The Windows Experience Index has not been computed

The current theme doesn’t support Aero

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.

PS C:\> Import-Module tr*

PS C:\> Get-TroubleshootingPack C:\Windows\diagnostics\system\Audio | Invoke-Troubles

hootingPack

No problems were detected

PS C:\>

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.

PS C:\> Import-Module tr*

PS C:\> Get-TroubleshootingPack C:\Windows\diagnostics\system\Audio | Invoke-Troubles

hootingPack

The output from the Audio TroubleShooting Pack is shown in the following screen shot.

SW, that is all there is to using the troubleshooting packs with Windows PowerShell. Troubleshooting Week will continue tomorrow when I will continue talking about using answer files to automate the Windows PowerShell troubleshooting packs.

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