{"id":15671,"date":"2011-02-07T00:01:00","date_gmt":"2011-02-07T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2011\/02\/07\/use-powershell-to-troubleshoot-your-windows-7-computer\/"},"modified":"2011-02-07T00:01:00","modified_gmt":"2011-02-07T00:01:00","slug":"use-powershell-to-troubleshoot-your-windows-7-computer","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/use-powershell-to-troubleshoot-your-windows-7-computer\/","title":{"rendered":"Use PowerShell to Troubleshoot Your Windows 7 Computer"},"content":{"rendered":"

Summary<\/b>: Learn how to use Windows PowerShell to simplify troubleshooting your Windows 7 or Windows Server 2008 R2 computers.<\/p>\n

\"Hey,<\/p>\n

  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?<\/p>\n

—SW<\/p>\n

\"Hey, Hello SW,<\/p>\n

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<\/a> on some totally rad waves<\/a>.<\/p>\n

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<\/a>, 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.<\/p>\n

\"Photo<\/a><\/p>\n

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<\/a>. On Wednesday I discuss using the troubleshooting packs to diagnose remote problems<\/a>, and on Thursday I talk about using PowerShell and Scheduled Tasks to automate troubleshooting<\/a>.<\/p>\n

The TroubleShootingPack module<\/a> 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<\/b> command to see which modules are available. I use the ListAvailable<\/i> switched parameter to return the information shown here.<\/p>\n

\n

PS C:\\> Get-Module -ListAvailable<\/p>\n

ModuleType Name ExportedCommands<\/p>\n

———- —- —————-<\/p>\n

Script BasicFunctions {}<\/p>\n

Manifest cdc1ADmodule {}<\/p>\n

Script ConversionModuleV6 {}<\/p>\n

Binary DataONTAP {}<\/p>\n

Script DotNet {}<\/p>\n

Manifest FileSystem {}<\/p>\n

Manifest IsePack {}<\/p>\n

Script ISEProfileModule {}<\/p>\n

Manifest MSI {}<\/p>\n

Manifest PowerShellPack {}<\/p>\n

Manifest PSCodeGen {}<\/p>\n

Manifest Pscx {}<\/p>\n

Manifest PSImageTools {}<\/p>\n

Manifest PSRSS {}<\/p>\n

Manifest PSSystemTools {}<\/p>\n

Manifest PSUserTools {}<\/p>\n

Manifest TaskScheduler {}<\/p>\n

Manifest WPK {}<\/p>\n

Manifest ActiveDirectory {}<\/p>\n

Manifest AppLocker {}<\/p>\n

Manifest BitsTransfer {}<\/p>\n

Manifest FailoverClusters {}<\/p>\n

Manifest GroupPolicy {}<\/p>\n

Manifest IntelvPro {}<\/p>\n

Manifest NetworkLoadBalancingCl… {}<\/p>\n

Manifest PSDiagnostics {}<\/p>\n

Manifest TroubleshootingPack {}<\/p>\n<\/blockquote>\n

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<\/a> has a number of awesome Windows PowerShell projects<\/a>).<\/p>\n

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<\/b> 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.<\/p>\n

\n

Import-Module -Name TroubleShootingPack<\/p>\n<\/blockquote>\n

I do not need to use the Name<\/i> 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 <\/i>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<\/b> cmdlet with Tr* <\/i>as indicated here to import the TroubleShootingPack module.<\/p>\n

\n

Import-Module Tr*<\/p>\n<\/blockquote>\n

What happens if I use the T*<\/i> 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<\/b> cmdlet returns two modules.<\/p>\n

\n

PS C:\\> Import-Module T*<\/p>\n

PS C:\\> Get-Module<\/p>\n

ModuleType Name ExportedCommands<\/p>\n

———- —- —————-<\/p>\n

Manifest troubleshootingPack {Get-TroubleshootingPack, Invoke-Troubleshoo…<\/p>\n

Script TaskScheduler {Remove-Task, Get-ScheduledTask, Stop-Task, …<\/p>\n

To see which commands the module provides, I use the Get-Command<\/b> cmdlet with the Module<\/i> parameter. This command and the results appear here.<\/p>\n

PS C:\\> Get-Command -Module trouble*<\/p>\n

CommandType Name Definition<\/p>\n

———– —- ———-<\/p>\n

Cmdlet Get-TroubleshootingPack Get-TroubleshootingPack [-Path…<\/p>\n

Cmdlet Invoke-TroubleshootingPack Invoke-TroubleshootingPack [-P…<\/p>\n

PS C:\\><\/p>\n<\/blockquote>\n

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

\"Image<\/a><\/p>\n

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%<\/b> location (C:\\Windows\\Diagnostics\\System). By using this information, I can use the Get-ChildItem cmdlet<\/a> to list all of the available troubleshooting packs. The command to list the troubleshooting packs and the results are shown here.<\/p>\n

\n

PS C:\\> Get-ChildItem C:\\Windows\\diagnostics\\system<\/p>\n

Directory: C:\\Windows\\diagnostics\\system<\/p>\n

Mode LastWriteTime Length Name<\/p>\n

—- ————- —— —-<\/p>\n

d—- 7\/14\/2009 1:37 AM AERO<\/p>\n

d—- 7\/14\/2009 1:37 AM Audio<\/p>\n

d—- 7\/14\/2009 1:37 AM Device<\/p>\n

d—- 7\/14\/2009 1:37 AM DeviceCenter<\/p>\n

d—- 7\/14\/2009 1:37 AM HomeGroup<\/p>\n

d—- 7\/14\/2009 1:37 AM Networking<\/p>\n

d—- 7\/14\/2009 1:37 AM PCW<\/p>\n

d—- 7\/14\/2009 1:37 AM Performance<\/p>\n

d—- 7\/14\/2009 1:37 AM Power<\/p>\n

d—- 7\/14\/2009 1:37 AM Printer<\/p>\n

d—- 7\/14\/2009 1:37 AM Search<\/p>\n

d—- 7\/14\/2009 1:37 AM WindowsMediaPlayerConfiguration<\/p>\n

d—- 7\/14\/2009 1:37 AM WindowsMediaPlayerMediaLibrary<\/p>\n

d—- 7\/14\/2009 1:37 AM WindowsMediaPlayerPlayDVD<\/p>\n

d—- 7\/14\/2009 1:37 AM WindowsUpdate<\/p>\n

PS C:\\><\/p>\n<\/blockquote>\n

To obtain information about a troubleshooting pack, use the Get-TroubleShootingPack<\/b> 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<\/a> the information to the Format-List<\/b> cmdlet to see the information.<\/p>\n

\n

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

Path : C:\\Windows\\diagnostics\\system\\AERO<\/p>\n

Id : AeroDiagnostic<\/p>\n

Version : 1.0<\/p>\n

Publisher : Microsoft Windows<\/p>\n

Name : Aero<\/p>\n

Description : Display Aero effects such as transparency.<\/p>\n

MinimumVersion : 6.1<\/p>\n

PrivacyLink : http:\/\/go.microsoft.com\/fwlink\/?LinkId=104288<\/p>\n

SupportsClient : True<\/p>\n

SupportsServer : True<\/p>\n

SupportsX86 : True<\/p>\n

SupportsAmd64 : True<\/p>\n

SupportsIA64 : True<\/p>\n

RequiresElevation : True<\/p>\n

Interactive : True<\/p>\n

RootCauses : {Mirror drivers don’t support Aero effects, Aero effects not sup<\/p>\n

ported on this Windows edition, Video card doesn’t support requi<\/p>\n

red display settings, Video card driver doesn’t support Aero eff<\/p>\n

ects…}<\/p>\n

FoundRootCauses :<\/p>\n

Interactions : {This troubleshooter can’t run in a Remote Desktop session}<\/p>\n

ExtensionPoint : #document<\/p>\n<\/blockquote>\n

If I want to see what root causes the troubleshooting pack is able to detect, I select and expand the RootCauses<\/b> 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).<\/p>\n

\n

PS C:\\> Get-TroubleshootingPack -Path C:\\Windows\\diagnostics\\system\\AERO |<\/p>\n

Select-Object -ExpandProperty RootCauses<\/p>\n

Name<\/p>\n

—-<\/p>\n

Mirror drivers don’t support Aero effects<\/p>\n

Aero effects not supported on this Windows edition<\/p>\n

Video card doesn’t support required display settings<\/p>\n

Video card driver doesn’t support Aero effects<\/p>\n

Color depth is set too low<\/p>\n

Desktop Window Manager Session Manager service isn’t running<\/p>\n

Themes service isn’t running<\/p>\n

Current power settings don’t support Aero desktop effects<\/p>\n

Desktop Window Manager is disabled<\/p>\n

Transparency is disabled<\/p>\n

The Windows Experience Index has not been computed<\/p>\n

The current theme doesn’t support Aero<\/p>\n<\/blockquote>\n

To run a troubleshooting pack, I need to first use Get-TroubleShootingPack<\/b> to retrieve an instance of a troubleshooting pack, and then I can pipe it to the Invoke-TroubleShootingPack<\/b> 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.<\/p>\n

\n

PS C:\\> Import-Module tr*<\/p>\n

PS C:\\> Get-TroubleshootingPack C:\\Windows\\diagnostics\\system\\Audio | Invoke-Troubles<\/p>\n

hootingPack<\/p>\n

No problems were detected<\/p>\n

PS C:\\><\/p>\n<\/blockquote>\n

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.<\/p>\n

\"Tasks<\/a><\/p>\n

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.<\/p>\n

\n

PS C:\\> Import-Module tr*<\/p>\n

PS C:\\> Get-TroubleshootingPack C:\\Windows\\diagnostics\\system\\Audio | Invoke-Troubles<\/p>\n

hootingPack<\/p>\n<\/blockquote>\n

The output from the Audio TroubleShooting Pack is shown in the following screen shot.<\/p>\n

\"Troubleshooting<\/a><\/p>\n

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<\/a>.<\/p>\n

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

Ed Wilson, Microsoft Scripting Guy<\/b><\/p>\n","protected":false},"excerpt":{"rendered":"

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, […]<\/p>\n","protected":false},"author":595,"featured_media":87096,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[51,31,3,4,134,45],"class_list":["post-15671","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-getting-started","tag-operating-system","tag-scripting-guy","tag-scripting-techniques","tag-troubleshooting","tag-windows-powershell"],"acf":[],"blog_post_summary":"

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, […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/15671","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/users\/595"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/comments?post=15671"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/15671\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media\/87096"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media?parent=15671"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=15671"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=15671"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}