Creating your own troubleshooting pack


Take notice: My new feed address is now Please re-subscribe.

As I wrote in one of my blogs, you not only can tell your user which exactly troubleshooting pack to run, you can also create one of your own. Finally I decided to learn how and to tell you. I was pretty sure it was very hard, creating those. But I was plain wrong: it’s easy. Moreover it’s fun, because for creating it you should collect all the components of a geek’s fun:

1) Use GUI

2) Use scripting

3) Run the automation and see the result!

So, let’s begin.

Unfortunately, you cannot just create a pack with Notepad. Well, probably there is a method, but I believe it is far less convenient than the following. First of all you need to download and install Windows 7 SDK. I, honestly, don’t know which component exactly contains the feature we are going to use, so you can find it out yourself, or just follow me and care not about it. After installation you’ll have a menu entry for Troubleshooting Pack Designer:


You only need to decide what is the problem you’re going to solve with the pack. In my example, I’m going to automatically detect and fix one simple yet annoying defect: my Dell notebook sometimes cannot detect network speed while on a dock-station. Disabling and re-enabling the interface is one of the workarounds, which I don’t erally hate, but which I’d like to automate. (ok, I know that just a two line script would be enough, but then I wouldn’t have had a simple enough scenario to show you Winking smile)So, I launch the designer:


and create a new project:



(take notice of “Privacy URL” field: it is mandatory) Everything else is pretty straightforward from now on. Add a new root cause (you can add several of them). In my case it is “A Network is detected 10Mbps instead of 100”:


and hit “Design Troubleshooter” button. You’ll be presented with several settings. Troubleshooter – whether to run it elevated and interact with a user. In my case I set both to No:


Then configure a resolver and in the same way:


Surely we want our tool to check whether the actions taken had fixed all the problems, therefore we need to configure a verifier:


And finally, create and input scripts for them.


# TroubleshooterScript – This script checks for the presence of a root cause

# Key Cmdlets:

# — update-diagrootcause flags the status of a root cause and can be used to pass parameters

# — get-diaginput invokes an interactions and returns the response

# — write-diagprogress displays a progress string to the user


$RootCauseID = "NetIs10"


# Your detection Logic Here

$speed = (Get-WmiObject -Class Win32_NetworkAdapter | Where-Object { $_.Speed -ne $null -and $_.MACAddress `

-ne $null -and $ -like "*82567lm*"}).speed

if ($speed -ne 100000000)


      $RootCauseDetected = $true


      #Replace "$true" with the result of your detection logic


#The following line notifies Windows Troubleshooting Platform of the status of this root cause

update-diagrootcause -id $RootCauseId -detected $RootCauseDetected

It’s a very primitive script, which just checks if the network interface has speed of 100Mbps. Resolver:

# Resolver Script – This script fixes the root cause. It only runs if the Troubleshooter detects the root cause.

# Key cmdlets:

# — get-diaginput invokes an interactions and returns the response

# — write-diagprogress displays a progress string to the user


# Your logic to fix the root cause here

$network = Get-WMIObject Win32_NetworkAdapter | where {$ -like "*82567lm*"}


Start-Sleep 4


Even more simple script: just re-enables the interface.

Now just compile (some questions about certificate arise, you can use a test self-signed certificate or configure a right one in options) the pack and use it.


Well, at least for me it was some great experience with a good outcome: I now have an instrument to check and fix everything =)