Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell to determine the reliability of his workstation.
Microsoft Scripting Guy, Ed Wilson, is here. Sometimes, I am absolutely astounded when my computer works at all. At other times, I completely take it for granted. What makes the difference? Well, that part is easy: it is how well is my laptop working. Is it hanging, is it crashing, is it the infamous BSOD?
Well, I have not seen the last two issues in years. Windows, especially beginning with Windows 7 is rock solid, and it does not crash. So what gives? It all comes back to some particular application or website. Does the site routinely cause hangs? Does some application routinely fail and cause a Windows dialog box to appear that informs me the app has died, and then offer to restart the app?
These are the sorts of things that can be frustrating. In addition, these are the sorts of things that make me think that I need to format my hard disk drive and reinstall. But of course, if the issue is with some website, or some wayward application, then formatting my hard disk drive and reinstalling is really and truly a waste of time.
Dude, what happened to my laptop?
A couple of years ago, I wrote a series of posts that discuss using the Reliability provider in Windows 7. These posts also discuss enabling the Reliability provider for use with Windows Server 2008 R2. These posts are still applicable, and they bear re-reading as a context for today’s post.
One of the great things about the WMI Reliability provider, is that it provides me with a quick reality check. If I have an application that crashes once or twice, I may think, “Dude, this laptop crashes all the time,” when in reality, it was only twice in six months. In addition, I may think, “Dude, I need to fdisk this laptop because it is seriously unstable,” when in reality, it is rock solid. I have a tendency to remember the latest application abend much greater than the weeks of faithful and reliable service. So the numbers are a reality check.
Is it as bad as all that?
The first thing I want to do is to query the Win32_ReliabilityStabilityMetrics WMI class and get the minimum, maximum, and average reliability numbers. Here is the script:
Get-Ciminstance Win32_ReliabilityStabilityMetrics |
Measure-Object -Average -Maximum -Minimum -Property systemStabilityIndex
The command and the output are shown in the following image:
I have the minimum, the maximum, and the average values. It does not look all that bad. So I decide to pipe the results to the Out-Gridview so I can look at it in more detail. I change the query a bit to choose only the properties that I am interested in examining. Here is the query:
Get-CimInstance Win32_ReliabilityStabilityMetrics |
Select StartMeasurementDate, SystemStabilityIndex |
Out-GridView
Here is the grid view. One of the cool things about the grid view is that I can filter, select, and otherwise work with the data.
I now use a function I wrote when I was exploring the reliability provider (for more information, see Reuse PowerShell Code to Simplify Script Creation). This enables me to see where the sources of input to the reliability provider are coming from. I see that Windows Update Client occurred 109 times, and that there are 23 application errors and 8 application hangs. Her is the function:
Function Get-SortedReliabilityRecords
{
Param ([string]$computer = ".")
Get-WmiObject -Class win32_reliabilityRecords -ComputerName $computer |
Group-Object -Property sourcename, eventidentifier -NoElement |
Sort-Object -Descending count |
Format-Table -AutoSize -Property count,
@{Label = "Source, EventID";Expression = {$_.name} }
} #end function Get-SortedReliabilityRecords
The function and the output from the function are shown in the following image:
Finding application errors
With 23 application errors, it seems like a great place to explore. I write a bit of script, as shown here:
Get-CimInstance -ClassName Win32_ReliabilityRecords -Filter "
SourceName = 'application error'" |
Select ProductName, Message |
Format-Table -AutoSize -Wrap
I run the script, and as I scroll, I see that some common themes arise.
The best way to see where all the issues arise is to group the output. I use the following script to do my grouping:
Get-CimInstance -ClassName Win32_ReliabilityRecords -Filter "
SourceName = 'application error'" |
Select ProductName |
Group-Object -Property productname -NoElement |
Sort-Object count -Descending
The script and its output are shown here:
It seems that the largest number of application errors arise from the Communicator.exe application. I decide to group by time. Here is the script:
Get-CimInstance -ClassName Win32_ReliabilityRecords -Filter "
SourceName = 'application error' AND ProductName = 'communicator.exe'" |
Select timegenerated |
Sort -Descending
Here is the script and the output from the script:
Most of the errors occur on the same day, within minutes of each other. Therefore, I need to explore to see if it was a network issue, or if some wayward update that I installed around that period caused the new errors. It does not seem as if things are quite as bad as I thought. I also have an avenue to pursue as I troubleshoot the problems. Cool.
That is all there is to using the WMI Reliability provider. Join me tomorrow when I will have an excellent post about removing data from a .csv file by guest blogger Matt Tisdale.
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