Categories TutorialsWindows 10

Diagnosing common Windows problems with PowerShell troubleshooting packs

Although Windows 10 is the most stable and reliable version of Windows that Microsoft has created in quite some time, things can, and occasionally do go wrong. Thankfully, there are a number of different diagnostic and troubleshooting tools built into the operating system. In fact, you can diagnose a wide variety of Windows problems through PowerShell by leveraging the built-in troubleshooting packs.

Troubleshooting packs are essentially collections of diagnostic tests that are all related to a specific area of the system. You can see a list of all of the available troubleshooting packs by opening PowerShell, navigating to C:\Windows\Diagnostics\System, and then entering the Get-ChildItem | Select-Object Name command. As you can see in the figure below, there are currently 17 different troubleshooting packs available, covering everything from audio to printers.


To use the troubleshooting packs, you will have to specify the Get-TroubleshootingPack cmdlet, followed by the name of the troubleshooting pack that you want to use. If you want to perform network diagnostics for instance, you would enter the Get-TroubleshootingPack cmdlet, followed by the word Networking.

Before I continue, I wish to point out that the reason why I am able to get away with using a simplified command such as Get-TroubleshootingPack Networking is because I am working from within the C:\Windows\Diagnostics\System folder. If you try to run a troubleshooting pack from another location, you will usually have to provide a full path. The command looks like this:

Get-TroubleshootingPack -Path “C:\Windows\Diagnostics\System\Networking”

Running troubleshooting packs

So now that I have explained how to access a troubleshooting pack, let’s take a look at what happens when you run a troubleshooting pack. For the following examples, I am going to be using the Windows Update troubleshooting pack, but the process works in basically the same way regardless of which troubleshooting pack you use.

So with that said, when you run the Get-TroubleshootingPack cmdlet and specify the name of an individual troubleshooting pack, the initial results are not exactly helpful. As you can see in the figure below, Windows initially provides some version information, and not much more.


Running the troubleshooting pack in this way isn’t exactly helpful, but there is quite a bit of useful information contained within the troubleshooting pack. Before I show you how to extract that information though, I want to show you how to find out what the troubleshooting pack does, and how to tell if it will work on your system. The reason why this is important is because some troubleshooting packs are designed for Windows 10, while others might only work on Windows Server.

The system that I am using to generate the screen captures in this article is running a 64-bit edition of Windows 10. Therefore, if I wanted to know what the Windows Update troubleshooting pack does and whether or not it will work on my system, I would use a command like this one:

Get-TroubleshootingPack WindowsUpdate | Select-Object Name, Description, SupportsClient, SupportsAmd64

As you can see in the figure below, the SupportsClient field shows a value of “True,” meaning that the pack will run on Windows 10. Similarly, the SupportsAmd64 column is also showing a value of true, meaning that the pack will work on a 64-bit operating system. The values that you can use to test whether or not a troubleshooting pack is supported include:

• SupportsClient
• SupportsServer
• SupportsX86
• SupportsAmd64
• SupportsIA64

So now let’s take a look at how to use a troubleshooting pack to determine what is wrong with a system. Rather than running the Get-TroubleshootingPack cmdlet directly, it is usually going to be easier to map the cmdlet to a variable. Therefore, I am going to use a variable named $Diag. Here is the command:

$Diag = Get-TroubleshootingPack WindowsUpdate

Hunting down the root causes

Once the variable has been created, we can begin to look for the root causes of the problems that we are experiencing. Each troubleshooting pack can test for a variety of conditions. To see a list of the tests, just enter the variable name, followed by a period, and the word RootCauses. The figure below shows the potential root causes of a Windows Update failure.


So now let’s run the troubleshooting pack. To do so, pipe the previously created variable to the Invoke-TroubleshootingPack cmdlet. You can see what this looks like in the next figure.


In this case, no problems were found. In all honesty, I would have been surprised if problems were detected, because Windows Update is working fine. Had a problem been detected though, Windows would have provided information on how to correct the problem.

Just for the sake of demonstration, however, let’s pretend that we had received a message stating that Windows Update components needed to be repaired. Troubleshooting packs will usually provide you with a recommended resolution, but there is a way to manually get more information if necessary. For example, the Windows Update troubleshooting pack might indicate that Windows Update is failing because there are pending system changes that require the system to be rebooted before additional updates can be installed.

Troubleshooting packs: Each a little different

One thing that I have found when working with the various troubleshooting packs within Windows is that each one is a little bit different. Some troubleshooting packs, like the Windows Update pack, simply examine the system and provide you with a result. Other troubleshooting packs, like the Networking pack, actually require a bit of interactivity. In fact the Networking troubleshooting pack prompts you for an instance ID, and then presents you with a menu of nine different types of tests that you can perform. Regardless of how a troubleshooting pack actually behaves, however, the basic command structure remains the same across troubleshooting packs.

Featured image: Shutterstock / TechGenix illustration

Brien Posey

Brien Posey is a freelance technology author and speaker with over two decades of IT experience. Prior to going freelance, Brien was a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network engineer for the United States Department of Defense at Fort Knox. In addition, Brien has worked as a network administrator for some of the largest insurance companies in America. To date, Brien has received Microsoft’s MVP award numerous times in categories including Windows Server, IIS, Exchange Server, and File Systems / Storage. You can visit Brien’s Website at: www.brienposey.com.

Share
Published by
Brien Posey
Tags Powershell

Recent Posts

Don’t be a victim: Why MSPs must do an internal security audit

Managed Service Providers are in the crosshairs of hackers because the bad guys know MSPs hold a lot of sensitive…

6 hours ago

Azure Quick Tip: Link Azure Automation and Log Analytics workspace

Here’s a Quick Tip that will show you how to link an Azure Automation and Log Analytics workspace even if…

9 hours ago

Creating Hyper-V VMs from a CSV file with PowerShell

Expedite the process of creating several virtual machines with a PowerShell script that builds VMs based on the contents of…

11 hours ago

Provision VMs using Marketplace and save some valuable time

Do you provision VMs regularly? This step-by-step guide shows you a way to do it quickly that will save you…

14 hours ago

CRD in Kubernetes: Powerful boost for an already powerful platform

While Kubernetes is already the No. 1 container orchestration tool, a custom resource definition, or CRD, adds incredible custom features…

3 days ago

PowerShell Quick Tip: Consistent output in Azure Automation Accounts

Here’s another in our popular Quick Tips series. This one focuses on PowerShell and how it can help you get…

3 days ago