Go to ...

RSS Feed

September 22, 2020

Ruminations on Reliability Monitor

Reliability Monitor is a specially-packaged offshoot of the Windows built-in Performance Monitor facility. In fact, if you can’t get Reliability Monitor to come up in the search box (mine does as “View reliability history” as soon as I type “reli” therein), another way to invoke this tool is to type perfmon /rel into the search box, or at a command line in PowerShell or Cmd.exe.  (Note: perfmon.exe is the executable file that runs Performance Monitor.)

How Does Reliability Monitor Work?

Basically, Reliability Monitor filters errors and information from Event Viewer and Performance Monitor to show you a variety of specific behaviors on a Windows PC. If you look to the right of the line graph, you’ll see the following categories listed there:

+ Application failures: reports when applications stop working, crash, or freeze
+ Windows failures: reports when Windows itself or its various sub-systems stop working, crash or freeze
+ Miscellaneous failures: reports hardware, driver and other failures not tied to applications or the OS
+ Warnings: reports warnings related to driver, Windows Update or Microsoft Store app updates that don’t complete successfully
+ Information: reports information about updates to drivers, or originating from WU or the Microsoft Store

I find Reliability Monitor extremely helpful in checking the health and well-being on my Windows PCs. In the example shown in the lead-in graphic, it showed my that the MiniTool Partition Wizard updatechecker kept issuing “Stopped working” errors where each of the three “Critical events” symbols appears (a white x in a red circle). To keep things shorter, I like to call Reliability Monitor ReliMon and will do so for the rest of this story.

That’s strange to see, because I’d already disabled that item in the Startup tab in Task Manager. This informed me that the program was still running anyway (and failing), even though I’d explicitly disabled it in the first place. I renamed that file from its default executable name of updatechecker.exe to updatechecker.old. If I ever need to run it again, I can rename it back, then run it. But now, it can’t run unless I restore the name. Presumably there’s some kind of task in Task Scheduler that’s causing this to run, even though I don’t want it to. And that’s just the kind of thing that Reliability Monitor is good at finding, and why I keep using it.

Knowing When to Act on ReliMon Reports

The example I presented in the preceding section is a great one that shows unambiguously that acting will eliminate certain critical events. Because I don’t want MTPW to run its own update checker — I have a couple of general purpose tools I use to do that once or twice a month myself — I’m happy to simply turn it off by removing it from the runtime picture (that’s what the renaming trick does). But other ReliMon items may not be amenable to that kind of solution. Here’s a different case in point on my production desktop PC:

If I look at Relimon output here, for example, I see the following critical events:

Internet Explorer “stopped working” 7/25/2020
DSAService  “stopped working” 7/28/2020
OUTLOOK.EXE “stopped working” 8/2/2020
Runtime broker “stopped working” 8/8/2020

Of those four items, three are either Microsoft applications I actually use (IE and Outlook, though IE not so much anymore) or services (runtime broker). Stopping or killing them really isn’t an option.  In fact, stopping or killing them would be counter-productive. Those are the kinds of errors you just have to live with.

On the other hand, DSAService is an Intel-provided service that checks for driver updates even when, as I had already done, I’d disable its startup item in the Task manager to try to turn it off. Turns out that some task is calling the Intel DSAService.exe program in much the same way that MTPW scheduled a call for updatechecker.exe. So yes, this is another item, I’ll rename to prevent further recurrences, in hopes it won’t stop me from checking for updates manually. And sure enough, the “Check for New Drivers” button in the Intel Driver and Support Assistant (the DSA that gives the executable file its name, I presume) keeps on working. Done!

As for the other stuff, these are things that could prompt Feedback Hub reports if the errors interfere with Windows operation, performance or reliability. Otherwise, one just learns tolerate them and sigh. Sigh.

Author: Ed Tittel

Ed Tittel is a 30-plus-year computer industry veteran. He’s a Princeton and multiple University of Texas graduate who’s worked in IT since 1981 when he started his first programming job. Over the past three decades he’s also worked as a manager, technical evangelist, consultant, trainer, and an expert witness. See his professional bio for all the details.

Leave a Reply

More Stories From 20H1