Audio Playback
The Audio Playback troubleshooter has been updated to help users who don’t get sound in Windows Store Apps or on some web sites.  If you can’t play sound or music at all, this troubleshooter is for you.

Windows Store Apps
This troubleshooter has also been updated to find and fix problems with sound in Windows Store Apps.  Run this troubleshooter when you can play sound or music in desktop applications, but not in apps you’ve downloaded from the Windows Store, or if you experience other problems running Apps from the store.

Microsoft Word (KB2825739)
Some users of the Turkish version of Office 2013 may see an error message every time they start Word.  This troubleshooter fixes the problem and the error message will no longer be shown.  It only applies to the Turkish version of Office 2013.  Check out KB2825739 for more information. 

These instructions will give you a troubleshooting pack that works on Windows 7 operating systems.  However, I will update this post after Windows 8 release to show you how you can get the same tools to work on Windows 8.  Once you are able to do this, there are multitudes of regkeys and values you can modify.  Just make sure you don’t go running to the dark side with this one.  Heed this warning:

The registry contains really important operation and configuration information on your PC.  If you edit it incorrectly, you could end up with some serious issues.  Please, before you do anything described below, back up your registry.  If you want to know more about working with the registry, see KB 310516.

I’ve chosen a relatively harmless Windows 7 registry tweak for illustration purposes only.  With a little imagination (or experience with repetitive registry modifications) you can come up with your own custom application of this tool.

Step 1 – Start TSPD: Open Windows Troubleshooting Pack Designer.  Installation steps are listed in this blog post.  If you have not applied the TSPD fix yet, be sure to do that.

Step 2 - Create a project: Select “Project > New”.  Name your project Enable Aero.  A troubleshooting pack directory named Enable Aero is then created in your $User\Documents\troubleshooting packs folder.

Step 3 – Create the Title Screen: Your Project Name field is given the default name “Enable Aero” – you can change it if you want, but for this example, leave it as is.  The project name shows up as the title in the first screen of the troubleshooter.  Enter the following under Project Description:  “Turn Aero on”.  You can leave the “Privacy URL” field blank unless you’re interested in providing users with a privacy link.

Step 4 - Plan your workflow: Troubleshooting packs work in three main functional steps, each “compartmentalized” into independent scipts that “talk” to each other via Windows Troubleshooting Platform.  This is discussed in detail in the Device error troubleshooting sample.  These steps are as follows: Detect, Resolve, and Verify.  When you created your project in Troubleshooting Pack Designer, these scripts were added for you as part of the project.

You first need to define the state which “triggers” the necessary resolution steps to take place.  You don’t want a fix being applied if something’s not broken, right?  Once you’ve understood your detection logic, define the resolution steps.  Finally. you’ll need logic to verify that resolver actually fixed the problem we were looking for. In many cases, you can simply recycle the detection script itself.  Let’s do this is pseudocode (pseudoscript?) first:

Detect: Check the REG_DWORD-type “Composition” registry value in HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM.  Is the data for this value set to “0” ?  In this case “1” represents “Aero on” and “0” represents “Aero off”.  If the “Composition” value data is not 1 (on) then our root cause detection is true and we can step into the resolving the problem.  If the value is already 1, then we don’t have the problem and root cause detection is false.

Resolve: Set “Composition” data to “1”

Verify: Rerun detection script and if the resolver succeeded, then root cause detection will return false instead of true.

Step 5 - Add a Root Cause: In Project Explorer on the left, click “Add New Root Cause”.  A “root cause” is essentially a test condition.  As mentioned above, if we detect the root cause then we will apply the fix.  Let’s make the Root Cause ID “IncorrectRegValueData”.  This ID is referenced by your scripts.  The Root Cause Name should be “Composition registry value data incorrect”.  Leave the Root Cause Description blank for now.

Step 6 – Define the Troubleshooter:  In Project Explorer, click “Define Troubleshooter”.  You should not need to change the Troubleshooter properties presented – assuming you are an admin on the machine you’re working on, you don’t need the troubleshooter to run with elevated privileges.  We will not be using interactions in this example.

Step 7 – Define the Resolver:  In Project Explorer, click “Define Resolver”.  Our Resolver Name will be “Update registry value data”.  You can leave the Resolver Description blank for now.  Also, leave the Prompt, Elevation, Interaction and Parameter options as they are.

Step 8 - Define the Verifier:  In Project Explorer, click “Define Verifier”.  Because it is possible for a verifier script to determine the root cause has been resolved and we can reuse the troubleshooting script, leave the Verifiable and Reuse Troubleshooter options as they are.

Step 9 – Edit Root Cause Scripts:  In Project Explorer, click “Edit Root Cause Scripts”.   Let’s start with the troubleshooter that contains the detection logic.  Click on “Edit Troubleshooter Script” to open it in PowerShell.  Notice that Troubleshooting Pack Designer named your script consistently with the RootCauseID you defined earlier (TS_IncorrectRegValueData.ps1).

You will see the following in your troubleshooting script:

# 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 = "IncorrectRegValueData"

# Your detection Logic Here

$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

In place of ”# Your detection Logic Here”, add the following PowerShell logic:

#Detection logic: Select registry path and find the data stored under the "Composition" registry value
$regPath = Get-ItemProperty HKCU:\Software\Microsoft\Windows\DWM
$regValueData = $regPath."Composition"

#Check if the registry data is not 1.  If this is true, root cause has been detected

if
($regValueData -ne "1")
{
    $RootCauseDetected = $true
}

else
{
    $RootCauseDetected = $false
}  

Be sure to leave the line that notifies Windows Troubleshooting Platform of the root cause status:

#The following line notifies Windows Troubleshooting Platform of the status of this root cause
update-diagrootcause -id $RootCauseId -detected $RootCauseDetected

Next update the resolver script (RS_IncorrectRegValue.ps1).  When you first open it, it will look like this:

# 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

Now replace “# Your logic to fix the root cause here ” with this:

$regPath = "HKCU:\Software\Microsoft\Windows\DWM"
$value = "Composition"
$data = 1

Set-ItemProperty $regPath $value $data

Be sure to save your scripts and your project.  You’re now ready to test you troubleshooter!

Step 10 – Test your troubleshooter: In Troubleshooting Pack Designer, select “Build > Run” or press F5 to build and run the troubleshooter.  You should end up with a screen that looks like the screenshot below. 

Be sure to check regedit and see that the “Composition” value data under HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM has been changed from 0 to 1 (if it was already 1, then Windows Troubleshooting Platform gives you a window that says “Troubleshooting couldn’t identify the problem”).  To test that Aero has been enabled, you will have to log off and log back on.   You now have a troubleshooting pack that checks a specific registry value and data, and changes it if it’s in a particular state.  Such is the versatility of PowerShell combined with Windows Troubleshooting Platform.

In such times it may be useful to enumerate all problem devices on a machine, filter them by error code, and handle each of those devices uniquely based on a combination of error code and one of their properties (we will be accessing these properties in PowerShell via WMI).  In this example, we will learn how to build a troubleshooting pack that finds all devices with a particular error state.  If any devices are found with the designated error code we are looking for, we will create an array of these devices’ DeviceIDs and resolve each device based on a combination of knowing our error code and DeviceID of the device(s) of interest.  Of course there are many ways to solve this kind of problem, based on the known and unknown variables in the troubleshooting process.  For example, you can filter your list using other Win32_PnPEntity properties of the device, so long as they are available to the OS whether the driver is installed or not and the property data is unique enough to set them apart from other devices.  You can also filter for other kinds of device error codes.  This is just one example that can easily be tailored to suit your specific needs.

In the case of a missing driver, we know the ConfigManagerErrorCode is Code 28 (0x1C).  Let’s say we want to create an automated troubleshooter for an audio device with a driver that has not been installed.  During the troubleshooting experience, we would like the user to be redirected to a web page where they can quickly and easily download the driver.  Alternatively, they can be given a direct link to the driver itself, where upon clicking the link they will automatically begin the driver installation process without having to search for a download link on a webpage.

Before getting started with this example, you will want to make sure you have installed Windows Troubleshooting Pack Designer.  The steps for doing so are listed here.

Let’s begin with the logic of what we want to do in PowerShell.  Then we’ll work this logic into the Windows Troubleshooting Platform framework with Troubleshooting Pack Designer.  Don’t worry about following along and adding code anywhere yet – this is just to give you the building blocks that we will use later when we actually build the scripts with troubleshooting pack designer.  As we plan the troubleshooter, note the basic structure of the WTP framework:

The main root cause detection logic resides in the troubleshooter script.  If you detect a root cause, the troubleshooter uses the Update-DiagRootCause cmdlet to handoff relevant information to the resolver.  The required parameters associated with this cmdlet are -id and -detected.  The -id parameter represents the identifier string for the root cause you want to update and the -detected parameter represents whether the root cause was detected or not.  Optional parameters are the -InstanceId and -Parameter parameters, representing the specific instance of the root cause and information passed from the troubleshooters to the resolver, respectively.  In this example, the use of both required and optional parameters will be demonstrated.

Note
Reference material: For more information on how device error code are obtained, please reference the Win32_PnPEntity class ConfigManagerErrorCode table Update-DiagRootCause: For more information on the Update-DaigRootCause cmdlet, please review the documentation on MSDN.

Building the Troubleshooter Logic

First we need to build a list of devices on the PC that are giving us an Error Code 28 (0x1C).  It is important to pause here and consider that we may want to use this code to filter for more than just one error code.  For example, error code 18 (0x12) reports that Device drivers must be reinstalled.  In many cases this could warrant the same resolution as Error code 28.  Thus, we should build our code to handle more than one error code at a time. 

We will do this by creating an array called $BrokenDevices and assign to it devices that are reporting the Error code(s) we are interested in.  Let’s first create a hash table called $ErrorCodeList to store the Error codes.  We will then use the Get-WmiObject cmdlet and the Win32_PnPEntity class to get our list of these devices (stored in $AllDevices).  Next we create the $BrokenDevices array to store the list of broken devices.  In the script we’ll iterate through each of these filtered items using a foreach loop to obtain their Device ID and build an array out of it as follows:

#build hashtable of Error Codes to filter for in the device list            
$ErrorCodeList = @{}            
$ErrorCodeList.Add(18,18)            
$ErrorCodeList.Add(28,28)            
#...and so forth for additional error codes            
            
#Get our list of devices            
$AllDevices = Get-WmiObject Win32_PnPEntity            
            
#Create array for the filtered devices            
$BrokenDevices = @()            
            
#filter by values selected in ErrorCodeList            
foreach ($device in $AllDevices)            
{            
    if ($ErrorCodeList.ContainsValue([int]$Device.ConfigManagerErrorCode))            
    {            
        $BrokenDevices += $device            
    }            
}

Next we need to define the logic for what happens when this array is successfully populated with at least one item.  In the context of the Windows Troubleshooting Platform framework, this means that we have indeed found a root cause—at least one device is having a problem.  This part may not be relevant in regular PowerShell scripting, but with WTP it is important – in order to use the framework properly, we must raise a flag that flips our -detected parameter to $true.  We must also pass the relevant parameters obtained while troubleshooting, namely the PNP Device IDs.  For now all you need to know is that we use Update-DiagRootCause iteratively, in other words we are looping through the list of broken devices and essentially calling the resolver script for each one:

#update the resolver for each instance of a device in the $BrokenDevices list            
foreach ($erroredDevice in $BrokenDevices)            
{            
                
    Update-DiagRootCause -id $RootCauseId -detected $true -InstanceId $erroredDevice.PNPDeviceID -Parameter @{"ID" = $erroredDevice.PNPDeviceID}            
}

Building the Resolver Logic

Now comes the fun part – determining what happens now that we have found the broken devices!  In our case, we want to present a window that offers additional instructions to the user as well as an URL to the page or the driver itself.  This is where Windows Troubleshooting Platform really starts to demonstrate its utility.  As a support developer or IT Admin, you may not want to be stuck having to deal with figuring out how to create message windows with link text in your script.  You’ll see how to use Troubleshooting Pack Designer to build these interactions fairly quickly without mucking around with the code too much at all.  For now, let’s just take a look at the basic PowerShell logic that we would use as a resolution to the problem.  We will build a script that handles each Device ID that was found in the troubleshooting script with a unique interaction, so we must declare our parameters and build a switch statement:

#declare parameters from the troubleshooting script            
PARAM($ID)            
            
#handle each parameter passed uniquely            
switch ($ID)            
{            
    "[Insert Device ID 0 here]"            
    {            
        #Show Text interaction window with URLs for Device 0            
        Get-DiagInput -id "INT_ShowURL0"            
    }            
    "[Insert Device ID 1 here]"            
    {            
        #Show Text interaction window with URLs for Device 0            
        Get-DiagInput -id "INT_ShowURL1"            
    }            
    "[Insert Device ID 2 here]"            
    {            
        #Show Text interaction window with URLs for Device 0            
        Get-DiagInput -id "INT_ShowURL2"            
    }            
    "[Insert Device ID 3 here]"            
    {            
        #Show Text interaction window with URLs for Device 0            
        Get-DiagInput -id "INT_ShowURL3"            
    }            
    default            
    {            
        Get-DiagInput -id "INT_ShowURLDefault"            
    }            
}

As mentioned above, this script filters a set of devices by the DeviceID (a string) and handles each of them with unique interactions.  Interactions are built into Windows Troubleshooting Platform and can be created/customized with Windows Troubleshooting Pack Designer.  In our case, the interactions will present a window with text and an URL for the user to click on as shown below:

For now, all you need to know is that interactions are identified in PowerShell by their interaction IDs.   As a developer, you can decide the names of these interaction IDs.  In the example above, the interactions IDs are “INT_ShowURL0”, “INT_ShowURL1”, “INT_ShowURL2”, and “INT_ShowURL3”.  You will also want to build a “default” interaction in case a device in the list of broken devices doesn’t match one of the device ID we’ve specified in the switch statement. 

Note
Reference material: For more information about interactions, see the MSDN documentation on interacting with the user.

Building the Verifier Logic

You may be wondering about the verifier script.  For now, we won’t worry about it because we will simply reuse the logic from the troubleshooter to make sure the root cause is not there anymore.  If the steps that occurred during the resolution phase were unsuccessful, then the root cause would still exist and the troubleshooter, if run again, would return with a root cause detection of $true.  Troubleshooting Pack Designer has a way for us to decide to use this verification method, which you will see in later steps.

Building the Troubleshooting Pack

Now that we have a sense of our logic and where our interactions will occur, let’s build it into a troubleshooting pack.  Open Troubleshooting Pack Designer and create a new project with the name “DeviceDriverExample”:

Now add a project description.  This should briefly describe what the troubleshooting pack accomplishes.  Be sure to keep the description to less than 100 characters.  Copy and paste the following text for the Project Description: “Check for problem devices and show the user how to resolve the problem”.

The privacy URL can be left blank for now.  You should include your own URL to your privacy statement before releasing your troubleshooter.

Click “Add New Root Cause” in Project Explorer on the left side.

The Root Cause ID is the unique ID for the problem we’re going to find and fix.  We’ll use this ID in PowerShell to inform the framework if we’ve found a problem.  We will call our root cause “DeviceError” since if any device returns an error code that reports a missing driver, then we can flag our root cause detected state to true.  The root cause name should be “Device Error” and description should be something similar to the following: “The devices enumerated on the PC may have various error states.  Remember, root cause detection is determined by filtering one or more ConfigManagerErrorCode(s) associated with a device.

Now click “Next” in the upper right hand corner or “Define Troubleshooter” in Project Explorer on the left.  In this next screen, you can leave everything as it is.  Most of it is fairly self-explanatory.  We will not be using interactions in the troubleshooter in this case, and will use them as part of the resolver instead:

Click “Next” on the right again, or “Define Resolver” on the left.  Your resolver name should be “DriverDownload” and the description should be something about the solution to the root cause like: “This resolver redirects the user to an URL where they can download the correct device driver”.  In this example, we will be using interactions AND parameters, so select “Yes” for both the “Interactions” and “Parameters” options. 

Under “Interactions”, click the “Add Interaction” button.  This will launch the Interaction Designer.  Notice the drop down menu under “What interaction do you want to define?”.  We simply want to show the user some text to redirect them to an URL, so “Show Text” will be the best option.  Let’s call our first interaction “INT_ShowURL0”, and the question we ask the user (“Question or Prompt”) should be something like “Please download and install the latest driver for this device”.  The “Explanation Text” should explain more about the prompt.  Type “Follow the link below to download the correct driver”.  For now, let’s ignore Interaction Caching and leave it selected as “No” and let’s add a Help Link.  Select “Yes” under “Help Link” and add your Link Text and URL.  This will be the URL for the user to download the correct driver.  You text should describe where the user will be directed and correspond with the name of audio device you are troubleshooting, such as “Driver for HD Audio Device”.  Find an URL that you’d like your user to visit, otherwise for this example, use http://www.microsoft.com/hardware/en-us/downloads.  Selecting “Yes” to “Do you want to draw additional attention to the help link” will bring the help link up closer to the interaction text, so it can be good practice to do so.

Click “OK” and select “Add Interaction” again.  This time use the following to populate the fields:

• Interaction type: Show Text
• Interaction ID: INT_ShowURLDefault
• Question or Prompt: No matching case
• Explanation: The device driver was not found.
• Help Link: Yes
• Link Text: Try to find drivers at www.microsoft.com
• Link Target: http://www.microsoft.com/hardware/en-us/downloads
• Draw additional attention to help link? Yes

Click “OK”.  We can add more interactions later (as our switch statement actually requires 4 different interactions to really work) – for the sake of brevity, let’s just use two interactions for now and modify our script accordingly. 

Now we can define our parameters.  Parameters allow data to be passed from one phase of the troubleshooter to another, just like parameters for a function.  In this case, we want to pass information we collected in the root cause detection phase to the resolver script.  Before we can use those parameters in the resolver script we must define them for troubleshooting platform.  Parameters reference data collected by the scripts during the troubleshooting process. 

After selecting “Yes” for the Parameters option, you should now have a blank Parameter table as shown below:

Click the “Add Parameter” button.  The “Name” field will populate with “Parameter1” and the “Default Value” to “Default”.  Select “Parameter1” and change the name to “ID”.  This name will be used in identifying the information you will pass between the troubleshooting script and the resolver script in PowerShell (remember the parameter -Parameter @{"ID" = $erroredDevice.PNPDeviceID} in the troubleshooting logic and the PARAM($ID) line from our resolution logic?  The string “ID” corresponds with these and must be the same between your scripts and what you define in Troubleshooting Pack Designer.  Your parameter list should now look as it does below:

Click “Next” in the upper right or “Define Verifier” on the left.  Recall that we are reusing the troubleshooting script as a verifier, so nothing needs to be changed here.

Click on “Next” or “Edit Root Cause Scripts”.  It’s now time to add your PowerShell!  You should now see links to edit your troubleshooter and resolver scripts. 

Note that using the links in Troubleshooting Pack Designer is no different from just opening the .ps1 script in the project directory.  By default, the troubleshooting pack project is created in My Documents > troubleshooting packs.  You will see the .diag file which is the troubleshooting pack designer file you can edit, the ProjectFile.xml, and the troubleshooter and resolver script files that the Designer created for you (RS_DeviceError.ps1 and TS_DeviceError.ps1).  These are the files that will need to be updated with PowerShell logic so the troubleshooting pack works as intended.

Now to add our PowerShell code!  Let’s go back to the Scripts section of troubleshooting pack designer and edit our scripts.  Click on “Edit Troubleshooter Script”.  You should now see a PowerShell ISE window open with your troubleshooter script framework as follows:

This is the basic structure of a troubleshooter.  The bare essentials are the $RootCauseID (treated as a string) and $RootCauseDetected (treated as a boolean).  As we mentioned before, the $parameters hash table variable is optional and will not always be there – it depends on if you have specified the need for parameters while you were setting up your project in Troubleshooting Pack Designer.  Notice the declaration of the $parameters hash table that has been created for you in the second line of the script.  In this key-value pair, the key is the name you provided in Troubleshooting Pack Designer (“ID”) and its default value is “Default”.  The Designer added this line of script for you when you specified your parameter name through the user interface earlier.

When we build logic into the troubleshooter, we want to consider the end result of the logic flow, with the most important part being whether root cause detection is $true or $false.  This result gets passed through the update-diagrootcause cmdlet at the end of the troubleshooting script which relays information to the resolver script, such as whether it should run based on the result of the detection and other developer-specified information collected during troubleshooting ($parameters).  We will now incorporate the PowerShell logic we created earlier into the TS_DeviceError.ps1 script:

Copy and paste the following code immediately after the [HashTable]$parameters = @{"ID"="Default"} line:

#build hashtable of Error Codes to filter for in the device list            
$ErrorCodeList = @{}            
$ErrorCodeList.Add(18,18)            
$ErrorCodeList.Add(28,28)            
#...and so forth            
            
#Get our list of devices            
$AllDevices = Get-WmiObject Win32_PnPEntity            
            
#Create array for the filtered devices            
$BrokenDevices = @()            
            
#filter by values selected in ErrorCodeList            
foreach ($device in $AllDevices)            
{            
    if ($ErrorCodeList.ContainsValue([int]$Device.ConfigManagerErrorCode))            
    {            
        $BrokenDevices += $device            
    }            
}

We now need to update our resolver for each device that has an error.  Delete the line “update-diagrootcause -id $RootCauseId -detected $RootCauseDetected -parameter $parameters” and replace it with the following:

#update the resolver for each instance of a device in the $BrokenDevices list            
foreach ($erroredDevice in $BrokenDevices)            
{            
                
    Update-DiagRootCause -id $RootCauseId -detected $true -InstanceId $erroredDevice.PNPDeviceID -Parameter @{"ID" = $erroredDevice.PNPDeviceID}            
}

Save your script (CTRL+S) and close the window.  Now open your resolver script by returning to Troubleshooting Pack Designer and selecting “Edit Resolver Script” in the Root Cause Scripts view.  You should see the following:

In this script, Troubleshooting Pack Designer has given you the code to accept the troubleshooter parameters as well as basic code to trigger the interaction using the Get-DiagInput cmdlet.  However, the way it is written now triggers the interaction as soon as the resolver script runs.  We want to control how the interaction happens by using our switch statement.  Replace $INT_ShowURL0Result = get-diaginput -id "INT_ShowURL0" with the following code:

# --declare parameters            
PARAM($ID)            
            
#handle each parameter passed uniquely            
switch ($ID)            
{            
    "HDAUDIO\FUNC_01&VEN_10DE&DEV_000A&SUBSYS_10DE0101&REV_1001\5&18844406&0&0301"            
    {            
        Get-DiagInput -id "INT_ShowURL0"            
    }            
    default            
    {            
        Get-DiagInput -id "INT_ShowURLDefault"            
    }            
}

Note
Reference material:  Get-DiagInput:  For more infromation on the get-diaginput cmdlet, please review the documentation on MSDN

Testing the troubleshooting pack

This is where it gets tricky to test whether your troubleshooter works – because we are filtering for Device IDs, the Device ID listed above should be present on your machine.  If you don’t have the device in the first case presented above on the target PC, then you will only hit the default case.  For test purposes, let’s just make sure the default interaction gets hit, and then later you’ll learn how to look up a Device ID and create an error to test for.  One more gotcha – in order for this troubleshooter to return true for a root cause, you must have at least one device on your PC in an error state.  To accomplish this, go to Device Manager and temporarily disable a device (for example a sound device) by right clicking on it and selecting “Disable”.

Save your resolver script and go back to Troubleshooting Pack Designer.  It is time to see if all this works!  Press F5.  You will see the troubleshooting pack being built and signed.  Next you should see the following:

Click Next – if the device listed in the sample code is not on your PC then you should see this screen (this is the default interaction you created, INT_ShowURLDefault):

Click “Next” and the troubleshooter will run as a verifier to see if the problem was fixed.  The logic detected that the device was not repaired, so the troubleshooting report shows that a problem was found but not fixed:

At this point, you may be wondering how to find a device ID for a device on your PC and actually test this troubleshooter!  Unfortunately, we won’t be able to test it unless you want to uninstall drivers for your device, and we would like to avoid that right now.  Why don’t we try a different error code? It is easy to detect whether a device is disabled and then enable it as part of the resolution process.  The ConfigManagerErrorCode for this is 22 (0x16).  Let’s modify our code to look for Error code 22, and look for our disabled device’s PNP Device ID.  Remember that you already disabled a device in device manager earlier, so let’s figure out the device ID.  This is easy because we can use a script we already wrote!

Go back to your open scripts in PowerShell ISE and take a look at your troubleshooting script and the $ErrorCodeList you created there.  Comment out the hash table entries for error codes 18 and 28 and add one for error code 22 as follows:

#build hashtable of Error Codes to filter for in the device list            
$ErrorCodeList =             
$ErrorCodeList.Add(22,22)            
#$ErrorCodeList.Add(18,18)            
#$ErrorCodeList.Add(28,28)            
#...and so forth

Save this script.  Stay in the PowerShell ISE for the next steps.  Press F5 to run the script.  The ISE output will show you the parameters being passed through Update-DiagRootCause:

One of the device parameters shown is the Device ID.  Highlight and copy this device ID from the script output to the clipboard.  It will likely be a long alphanumeric sequence and different from the one in the screenshot above.  In the case above, the ID is: HDAUDIO\FUNC_01&VEN_10DE&DEV_000A&SUBSYS_10DE0101&REV_1001\5&18844406&0&0301.  Again, this may not be the same device as the one you disabled.

Go to your resolver script by clicking on the script pane button at the upper right corner next to the word “Script” and select the “RS_DeviceError.ps1” tab.  Paste your copied Device ID where the original device ID was.  Your switch statement will look something similar to the script below, where the [Your disabled Device ID here] string represents your disabled device ID.

#handle each parameter passed uniquely            
switch ($ID)            
{            
    "[Your disabled Device ID here]"            
    {            
        Get-DiagInput -id "INT_ShowURL0"            
    }            
    default            
    {            
        Get-DiagInput -id "INT_ShowURLDefault"            
    }            
}

Save your script and go back to Troubleshooting Pack Designer.  Press F5 to rebuild the pack and run it.  Once the troubleshooter hits the interaction prompt that says “Please download and install the latest driver for this device”, do not proceed with the troubleshooter.  Go back to Device manager and enable the device.  Now continue with the troubleshooter and you will see the following prompt showing that the problem was detected but not automatically fixed.  Most importantly, it does not report “Not Fixed” as it did before.

For the time being, this suffices for testing.  With this sample, you have learned many things at once – the troubleshoot-resolve-verify sequence, the process of planning how a troubleshooter will handle problems, the WTP specific Update-DiagRootCause and Get-DiagInput cmdlets, creating a troubleshooting pack from scratch, and using parameters and interactions then adding PowerShell code to make everything work.  Finally, you got started in learning how to be creative in testing your pack.  That’s quite a bit to learn in one sitting, and if you have gotten this far, congratulations!  Next time we will improve this troubleshooting sample in a number of areas, so pat yourself on the back and get ready for the next round!

DeviceDriverExample.zip

Manually - a.k.a. the hard(er) way:  You can write your own troubleshooting manifest, PowerShell scripts, and localization resources.  The troubleshooting manifest specifies root causes that the pack can detect, calls out the scripts used to detect, resolve and verify the resolution of problems, and identifies interactions presented to the user during the troubleshooting process.  If you want to know more, be sure to read more about writing troubleshooting pack manifests on MSDN.  You will also need to create and sign a security catalog, followed by creating a cab file. You might want to read all of this documentation.  Very carefully.  Just so you can appreciate how the next method does a lot of that for you.  Alternatively, you can skip reading and just go to the next method.  Keep in mind that this is a great way to author troubleshooting packs but if you are just getting started it can be time consuming to learn and build.  There are a lot of benefits to using this option that might not be apparent at first but will become more so as you start needing more flexibility in troubleshooting pack development.

Windows Troubleshooting Pack Designer - a.k.a. the easy way:  You can install a free GUI tool for editing troubleshooting packs that builds the manifest and the project file structure for you.  As a bonus, you can also use it to build and sign your packs.  Using TSP Designer makes it a lot easier to get started until you feel like setting up your own troubleshooting pack build environment.  As you add and customize interactions like showing help text/links, asking for input and presenting options for the user to choose from, TSP Designer updates the manifest for you.  Rather than dealing with troubleshooting pack framework stuff, you can focus more on the PowerShell and making sure your script logic detects the root cause and resolves it.  So are you ready to try it out yet?  Maybe you need more documentation on Windows Troubleshooting Platform to read.  If that is the case, then read the Windows 7 Troubleshooting Guide (which will apply to Win 8 as well).  This can be affectionately called the WTP troubleshooting pack development manifesto.  It is a healthy read but don't worry if it doesn't all stick at once.  You'll get there, via teleportation or otherwise.  Ok, let's install TSP Designer:

1.       Install Microsoft Visual C++ 2010 Express or Microsoft Visual Studio 2010

2.       Install the Windows 7 SDK 7.1 (NOTE: The “Tools” features under "Windows Native Code Development" and ".NET Development" must both be checked).  This will also work with the Win 8 SDK.

The Troubleshooting Pack Designer can be launched by clicking Start > All Programs > Microsoft Windows SDK v7.1 > Tools > Windows Troubleshooting Pack Designer.

****NOTE: If you are unable to launch or use the Troubleshooting Pack Designer please visit Microsoft Knowledge Base Article 2644923 for steps to resolve.****

Let’s begin with a little terminology.  What’s an “inbox troubleshooter”?  Well, it’s a fancy name for a troubleshooter that’s already part of Windows.  Got it?  Awesome.

Now, all inbox Windows troubleshooters have an attribute called a “Troubleshooting Pack ID” which identifies the troubleshooter so it can be invoked from the command line.  This is most convenient if you would like to run a Windows Troubleshooting Pack from your own application.  To accomplish this task, you can use the following command line syntax:

msdt–id [Troubleshooting Pack ID]

Here are some quick examples:

Audio Playback                    MSDT –id AudioPlaybackDiagnostic
Hardware and Devices        MSDT –id DeviceDiagnostic
Internet Connections           MSDT –id NetworkDiagnosticsWeb
[Custom local diagnostic]   MSDT –cab [Path_to_diagcab_file]

Easy, right?  There are lots more Troubleshooting Pack IDs you can reference at the end of this article.  Just one moment, my most stellar developer – there’s more you should know.  You’ll have this all figured out in no time, but there are a few little gotchas…

Windows 7 “Online” Troubleshooting Packs - WOTS

You may have heard of WOTS.  Chances are you haven’t.  Well my excellent friends, WOTS stands for “Windows Online Troubleshooting Service”.  Tangentially, you must first know that you absolutely can build your very own custom troubleshooting packs and run them directly from your PC of choice.  After all, troubleshooters built with Windows Troubleshooting Platform are simply collections of scripts packaged as a .diagcab file.  I’ll explain all that in a different post.  Promise.  For now, you just need to know that WOTS is a way of hosting these packages online – when your Windows 7 machine is connected to the interwebs, it automatically downloads the online package.  When it’s not connected, it’s not there.  Got it?  Maybe not?  Keep reading.

When you’re not online, Windows 7 gives you a particular set of troubleshooting packs.  When you get online, you get some new or updated ones.  In most cases, five “online” Troubleshooting Packs are enabled when you select the “Get the most up-to-date troubleshooters from Windows Online Troubleshooting Service” checkbox at the bottom of the Control Panel> All Control Panel Items window as seen below:

Now dudes and dudettes, these five hosted troubleshooting packs are as follows:

• Display Quality
• Performance (updated)
• Playing and Burning CDs, DVDs, and Blu-Ray Discs
• Set Up a TV Tuner
• Windows Update (updated)

(Hint:  The default view in Control Panel is totally hard to read.  If you want to see a clearer listing of the troubleshooters, click “View All” and you’re have a rather nice list of them)

There’s one additional troubleshooting pack for configuring devices (not shown in the Control Panel) that can be run by right-clicking devices under Control Panel > All Control Panel Items > Devices and Printers:

• Device Center (updated) – this is a contextually launched troubleshooter that can be useful in the case of troubleshooting a specific device.  It is totally unwise to run this troubleshooter without the parameters of the device you are troubleshooting.

Of these online Troubleshooting Packs, the Performance, Device Center, and Windows Update Packs have updated versions published to WOTS by Microsoft (for reference, I put (updated) next to those in the list above).  The original versions are available locally and can be launched when the computer is offline.

Display Quality, Playing and Burning CDs, DVDs, and Blu-Ray Discs, and Set Up a TV Tuner, all hosted on WOTS, are not available locally when the computer is offline.  If you attempt to invoke these Troubleshooting Packs from the command line without being connected to the internet, you will see the following prompt:

If you want to run the Display Quality, Playing and Burning CDs, DVDs, and Blu-Ray Discs, or Set Up a TV Tuner Troubleshooting Packs, you have to make sure the device is connected to the internet with WOTS enabled as shown above.

Does that make you dizzy?  Wooooaaah.  Don’t worry.  That’s why I’m writing all this down so you can reference it later when you need it, dude.  Think of it as a little tidbit left here to remind you throughout your Circuits of Time coding travels.  

Troubleshooting Pack IDs

The list below shows all Windows inbox Troubleshooting packs and their respective Troubleshooting Pack IDs:

Awesome, huh? [insert air guitar solo here]

Excellent……But Where can I find my Troubleshooting Pack ID?

Okay, there’s one more thing you gotta know.  What if you have a custom made troubleshooter on your PC and you have no idea what it is?  Most non-triumphant.  If for some reason you cannot locate a Troubleshooting Pack ID, you can just run the troubleshooter and step through it until it starts to detect the root cause(s).  Try it with one of the inbox troubleshooters first.  Go ahead and run it, then open the C:\Windows\Temp directory.  Look for a new folder created at the time you launched the troubleshooting pack.  This folder will have a random name, but will begin with the letters “SDIAG_”.  Inside this folder, look for DiagPackage.diagpkg and open this file with a text editor (i.e. notepad).  In the first several lines of XML, you will notice the <ID> tag under <DiagnosticIdentification>.  This will give you the Troubleshooting Pack ID of the pack you just ran.  See the example XML below:

  <DiagnosticIdentification>

    <ID>PerformanceDiagnostic</ID>

    <Version>1.0</Version>

  </DiagnosticIdentification>

Next time, I’ll tell you more about what these troubleshooting packs are all about and show you how to build them.  For now, you are dealing with the oddity of troubleshooting with the greatest of ease and can help your customers easily avoid bogus situations by being able to code a ready-made troubleshooting pack into your application.  Isn’t being excellent to each other what it’s all about?  Later.

Supplemental Information

• MSDN documentation on using the MSDT Command.  Includes a list of Troubleshooting Pack IDs for launching most diagnostics: http://technet.microsoft.com/en-us/library/ee424379(WS.10).aspx:
• Additional MSDN documentation on ways to run Troubleshooting Packs: http://msdn.microsoft.com/en-us/library/dd323763(VS.85).aspx:
• How to speak like Bill and Ted: http://www.billandted.org/howtospeak.htm