Using The Event Viewer (and Reliability Monitor)

[ubuysa]

Windows logs everything, and I really do mean everything, the volume of log records produced on a normally running Windows system is monumental. Most of them simply tell you that some ordinary (and perfectly normal) event has occurred. For example, when the user logs on a log record it written to record that event. As you might expect then, something like 95% of all log records don't indicate a problem at all, they simply record that some normal event occurred. The other 5% however do indicate problems, and some of them could be serious.

The tool that Microsoft provides for you to examine all the Windows logs (and there are many different logs) is called the Event Viewer, unfortunately it's not the most intuitive tool Microsoft has ever provided. Being able to extract useful information from the Windows logs is often a useful step in problem determination however, even if you can't fully interpret the log messages yourself you can copy what you think are the relevant log entries and post them to the PCS fora for the more experienced members to look at for you.


The Event Viewer

The easiest way to start the Event Viewer is to type 'eventvwr' in the Run command box. After it's started there will be a delay (which can be some minutes on a slower system) while the numerous logs are read and the Event Viewer is populated, you must wait for this process to complete before trying to use the Event Viewer. An example of the Event Viewer 'home' screen is shown below...



There are three frames to the Event Viewer screen; to the left is a folder tree structure for navigating the various logs, in the centre is the main log display, and on the right are a list of actions that you can take (the list of actions varies depending on where you are in the Event Viewer).

Initially the folder tree structure on the left is collapsed and the root (Event Viewer (Local)) is selected. We'll look at using this folder tree structure shortly.

The right-hand frame (the actions frame) has only a few basic actions displayed at the moment. We'll look at using some of these actions a little later.

The centre frame (called 'Overview and Summary') is divided into four panes; Overview, Summary of Administrative Events, Recently Viewed Nodes, and Log Summary. The small black up-arrow to the right of each of these panes can be used to collapse that pane and leave more room for the others.

The Overview pane only contains some very basic information about the Event Viewer and (after you've read it of course) this pane can be collapsed to create more viewing space.

The pane at the bottom, Log Summary lists all of the logs available, and not all of these will be Windows related. Third-party applications can (and often do) make their logs available to the Event Viewer, this is a good thing because it means that all your logging data is in one place. If you scroll down the list of logs here you can see the log name, the current and maximum size of each log, the date the log was last written to, whether the log is enabled on this system, and the log retention policy. As you scroll down notice that many of the Windows logs are disabled, this is by design and you should only enable logging for these features if instructed to do so by Microsoft.

This is a good moment to look at the folder tree structure on the left because this also refers to individual logs.

Custom Views is where you define filtered views that meet specified criteria so that if there are events you view often you can create a custom view for them. We'll look at creating custom views later.

Windows Logs is a summary view of some important logs, you can see the categories by expanding this folder. Application shows the general system (and some user) application log data, Security shows the security audit logs, Setup shows maintenance logs (update installation etc.), System shows kernel log data, and Forwarded Events shows log data that has been sent from other computers.

Applications and Services Logs is where all the various logs that Event Viewer can display are located, as you will see there are hundreds of them. Expand the 'Applications and Services Logs' folder and you'll see several overview log summary views and some expandable folders, how many and what they are called depends on your system and what's been installed - there are some basic ones though that are found on all systems. Hardware Events shows hardware log data, Internet Explorer shows log data from Internet Explorer of course, Key Management shows logs from the Key Management Service (KMS) which is related to licensing and activation, Windows PowerShell shows logs from the PowerShell tool[/U]. The expandable folder common to all systems is called Microsoft, so expand that folder. Again, how many sub-solders you see depends on your system and what's been installed but there are two expandable sub-folders common to all systems. Antimalware contains the logs from the Microsoft Antimalware Scan Interface (AMSI), and the Windows folder is where all the main logs are located. Expand the Windows folder and you'll see something similar to my example below...



We're not going to look at each and every one of these, don't worry! You just need to know that they're here in case you ever need to look at the logs for a specific feature. For example, in my 'Using the Performance Monitor' thread I showed you where performance alerts are logged; they're in Applications and Services\Microsoft\Windows\Diagnosis-PLA\Operational. You can see a correlation between the folder names here and the list of logs in the Log Summary on the 'home' screen.

Back on the Event Viewer 'home' screen' the pane in the centre, Recently Viewed Nodes is a list of logs (nodes) that you have recently looked at. You can of course double-click on any of these to go back to logs you have been recently viewing.

The pane at the top Summary of Administrative Events is the most important pane on this display and the one you would typically look at first. It lists a count of the number of each category of log event for the last hour, the last 24 hours, and the last 7 days. Note that this summary does not show every single available log entry, only those considered to be 'administrative' logs. What filter is used to extract 'administrative' logs isn't defined publicly, but all Critical, Error and Warning log entries are 'administrative' and are shown here. Non-administrative logs, like the performance alerts I mentioned earlier, must be directly accessed via the folder tree structure. An example of this pane is shown below...



The various log categories and their meaning are...

Critical these are failures (errors) that are considered to be so important that they must be investigated.

Error these are failures (errors) that have occurred and been logged, however almost all of these failures will have been automatically recovered by Windows. If a service stops unexpectedly for example, an error event will be logged, but Windows will simply restart the service and you probably won't even notice. There are a large number of errors logged on every normal client home system, this doesn't indicate that you have problems nor that your system is starting to fail. It's normal. Windows is a very complex system and unexpected things are happening all the time (especially in user mode). Windows is very resilient and it's designed to recover from almost any error, those it can't recover from generally cause a BSOD. Note that scammers who call you pretending to be Microsoft typically talk you through opening the Event Viewer and show you the apparently large number of errors logged, they then try to scare you into thinking your system is about to fail and only they can fix it for you.

Warning these are messages logged to tell you that something unexpected happened, it didn't cause a problem but you need to know that it happened. For example, if you enter a URL into your browser and the name lookup fails for some reason (as it often can) the DNS client will write a warning log message. These warning logs can be useful if you're having issues that you can't track down, a scan through the warning logs might reveal some interesting clues.

Information, as the name implies, are messages just to tell you things that you might find useful or interesting. When a service is started for example, it logs an information message. The performance alerts I mentioned earlier are logged as information messages. Many application programs log information messages so that the developer can debug the application.

Audit Success/Failure these are logs written by the security systems in Windows to log events that have security implications. For example, if you make changes to the Windows firewall the changes you make will be logged here. Think of these as information messages from the security system.

You can see from the '+' to the left of each category that they can be expanded to show the log entry types. In my example above I've already expanded the Critical category and you can see there is only one type of error, a Kernel-Power error (we'll look at what this error actually means in a short while). You can also see that I've had two of these log entries written during the last seven days and one was written in the last hour (these are not additive of course, there are only two of these errors logged on this system).

If I double-click on the Kernel-Power entry the log entries themselves are displayed, you can see this below...



As I select each log entry the box at the bottom displays the contents of the log entry.

 

[ubuysa]

Analysing A Log Entry

In the example above you can see that I've highlighted a critical entry and that the details of that log entry are displayed at the bottom (there are other ways of displaying log entries which we'll look at in a moment). All log entries use the same layout and have a General tab and a Details tab, currently we're looking at the General tab, we'll look at the Details tab later. There are many items of information on the log entry General tab and not all log entries fill out all of the fields (although this one does).

The description box at the top provides a basic reason for the log entry having been written. In this case it's because 'the system has rebooted without cleanly shutting down first'. Note that in this case this is a symptom and not a cause, this log entry just tells you that the system wasn't shut down properly - that's why it's a critical error - but this log entry doesn't tell you why the system didn't shutdown properly. You should look for other Critical or Error log entries written just before this one, they are more likely to reveal the cause.

The Log Name: field tells you the high-level component that caused this log entry to be written, in this case it's the 'System'.

The Source: field tells you the feature to which this log belongs, in this case it's 'Kernel-Power' (which is invoked when you shutdown or boot Windows).

The Event ID: field is a numeric code that specifically identifies this error within the component that logged it, in this case it was event id 41. These event ids are not unique across the system, application developers are free to choose whatever event ids they like for example. The event id is there for the developer (or Microsoft) to understand what happend in their particular application. This means that doing a web search for the event id is not always guaranteed to get you information related to this particular log entry, it might lead you to a completely unrelated application with the same event id. If there is an error code shown in the description box at the top (eg. 0x80070005) then that is much more useful as a search term.

The Level: field is one of Critical, Error, Information, etc. it shows the severity of the log entry.

The User: field identifies either the system or the user account that was running when the log entry was written, in this case it was the 'System'.

The Op Code: field was designed to tell you the actual instruction (operation code) that was executing at the time the log entry was written. It's never been fully implemented however and usually says just 'Info' as in my example.

The Logged field is simply the date and time the log entry was written.

The Task Category: field is similar to the event id, it's a (developer) assigned number designed so that the developer (or Microsoft) has more information about why the log entry was written, here it's (63). It's of no real use to us - and it often just says 'None' or is blank.

The Keywords: entry also contains information for the developer (or Microsoft), in our case it's '(70368744177664),(2)' which is gobbledegook as far as we're concerned. Often it's blank or it says 'Classic' or 'Process' or similar terms that have no real meaning for us.

The Computer: field is of course the name of the system on which the log entry was written. This is useful if you send your logs to someone else to analyse for you. If you ask for help from PCS with a problem they will quite often ask you to send your system logs for them to analyse.

Finally, the More Information: field contains a hyperlink that you think would take you to more useful information about this log entry. It doesn't! It's encouraging at first, if you click the link you'll see a window pop up listing the 'information that will be sent to Microsoft' and if you click Yes you'll only be taken to the home page for Microsoft (www.microsoft.com). It's absolutely useless so don't even bother clicking these hyperlinks.

Now click the Details tab, there are two radio buttons here; Friendly View and XML View. They both provide exactly the same information but the Friendly View is probably a little easier to read. And example of the Details tab for the Kernel-Power event we're looking at is shown below...



The System category is initially collapsed, you can click the '+' next to it to expand it as I have done above. There isn't a great deal more useful information in here, though you can see the process id which, in the event of their being more than one instance of this process, will let you see which one failed (via the Task Manager). Event Data category does sometimes contain more useful information such as error codes for example. Here it's pretty useless. Note that the BugcheckCode is the BSOD code if this error resulted in a BSOD.

It's worth looking at the Detailed view in case you find information in here that can improve the web search term you use when you're looking for help.


Other Ways To View Logs

The summary that we've just looked at is an excellent way of finding out whether there are any problems that you need to investigate, but it's not the only way to view log entries. In the summary view expand the Information category and find a log entry type that has many entries (it doesn't matter what it is). Right-click on this entry and select 'View All Instances of This Event' and the display will show every instance of this event (that matches the Source: and Event ID: fields). This saves a lot of time scrolling through the logs looking for similar events.

Under the root in the folder tree on the left is a folder called Custom Views, if you expand that you will see a pre-installed custom (ie. filtered) view called Administrative Events. This custom view shows you only Critical, Error and Warning log entries and in date/time order (with the most recent first). An example of this view is shown below (notice the icon used to highlight each type of event)...



Sometimes it's more convenient to use the Administrative Events custom view rather than the summary we've just seen because you can see events as they happened in time.


Creating Custom Views

As you've just seen. it can be quite handy having a custom view so that you can view log entries that are important to you quickly and without having to search for them all every time. The example I'm going to use here are the performance alert log entries that we looked at in the 'Using The Performance Monitor' thread.

In the Action frame on the right you can see a Create Custom View... menu item, click that and the Create Custom View dialog will open, this is shown below...



The Logged: list item lets you specify the time period you want to view (last hour, last day, etc.). I'm going to select Any Time.

The Event Level: is a set of checkboxes for you to specify what category of log entries you want to include (you can select more than one). I'm going to select Information.

The By Log: radio button lets you specify which specific log(s) you want to include, in here you'll find a series of checkboxes for you to select the log(s) you want to include in your custom view. I'm going to select Applications and Services\Microsoft\Windows\Diagnosis-PLA\Operational because that's where the performance alerts are written.

The By Source: radio button lets you select logs to include based on the Source: field in the log entry. I'm not using this entry type.

The <All Event Ids> box is where you list the event ids you want to include, as the text above says you can include several ids (comma separated) or ranges. I'm using 2031 because that's the event id for the performance alerts.

The Keywords:, User:, Computer(s): entries let you select log entries based on the Keyword:, User: or Computer: field in the log entry. I'm not using any of these entry types.

Click Ok when you're done and you'll see a 'Save Filter' dialog that asks for a name for the custom view (I've called mine 'Performance Alerts') and an optional description field. Click Ok when you're done and you'll see your new custom view in the Custom View folder tree on the left. Now, when you click on that custom view you will see only the performance alert log entries as shown below...

 

[ubuysa]

How To Get Help

Often doing a web search for the text in the description box will get you some helpful hints - but treat all websites and all advice with suspicion unless you know them to be authoritative. If there is an error code included in the description (eg. 0x80070005) then include that in the web search.

You can also copy the log entry as a text file and post in on the PCS fora for somebody more experienced to look at. To do that you need to use the Action frame on the right. If you look back at the last image I showed of the Administrative Events you can see that the highlighted log entry produces a highlighted entry in the Action frame with several actions underneath it. The action we're going to use is Copy.

When you click on the Copy action a flyout appears with 'Copy Table' and 'Copy Details as Text' options. Copy Table just copies the log entry header information (what you see in the summary) but Copy Details as Text copies the entire log entry (in internal XML format) as text which you can paste into a PCS forum post. Below is what the Kernel-Power log entry looks like as text...



If you really have no idea what logs to look at for your problem then you can export the entire contents of the Administrative Events custom view, that contains all your Critical, Error and Warning log entries. You can then post this to the PCS fora, or send it in an email to PCS for example, others can then import that into Event Viewer on their PC and examine your logs in the same detail as any other logs. Note that you can export any custom view but the Administrative Events view is so useful because it contains all the important log entries.

Right-click on the Administrative Events entry in the Custom View folder and select the 'Save All Events in Custom View As...' menu option. The standard Save As dialog will open so that you can select where to save the exported logs, they will be saved as an Event Viewer .evtx file. You'll then see the Display Information dialog shown below...



If you're sending the logs to someone whose computer uses the same language as you then you can simply click Ok to dismiss this box, but if the recipient uses a different language you'll need to use this dialog to add the language support for whatever language the recipient uses.

You can then send the .evtx file by any electronic means.

If someone sends you a .evtx file there are two ways of importing it into your Event Viewer. The easiest is to just double-click the .evtx file, it will open in Event Viewer automatically (and be loaded into a new folder in the folder tree structure called Saved Logs). The other way is to open the Event Viewer and right-click on the root of the folder tree structure (Event Viewer (Local)) and select 'Open Saved Log', you'll see the standard file open dialog for you to locate the .evtx file, and then an Open Saved Log dialog where you can give the log a unique name on your system (and a description) you can also change where the log file will be saved in your Event Viewer but it's probably wise to stick to the default of Saved Logs.

You can then simply select this saved log to display it in your Event Viewer.

 

[ubuysa]

The Reliability Monitor

Few users even know that the Reliability Monitor exists, it's buried deep in the Security & Maintenance feature, but it's another useful tool that displays Windows logs (and a little more).

The easiest way to start the Reliability Monitor is to type 'perfmon /rel' into the Run command box. No, the Reliability Monitor is not a feature of the Performance Monitor, it's just that all these tools are components of the Microsoft Management Console (MMC) so they are all inter-linked. The Reliability Monitor will start but, like the Event Viewer, it has to read all the relevant logs before it can display anything. An example of the Reliability Monitor 'home' screen is shown below...



The 'graph' near the top is organised by date, each vertical box is a day, every other day is labelled with the date. You can move forwards and backwards in time by clicking the arrowhead at each end of this 'graph'.

You can see in my example that some days have event icons on them and these icons should now be familiar; they are log events. Included in the Reliability Monitor are Critical, Error, Warning, and some Information messages, but there are some major differences between the way the Reliability Monitor treats these log entries and the way the Event Viewer treats them.

1. All Critical and Error log entries are classified as Critical by the Reliability Monitor. This means that a log entry that the Event Viewer shows as type Error is always shown as type Critical in the Reliability Monitor.

2. Only a subset of the Error log entries and Warning log entries are displayed by the Reliability Monitor, those Microsoft consider to be important. This means that the Reliability Monitor is not showing you the complete picture.

As we have already mentioned, the vast majority of system errors (even critical system errors) are recovered automatically by Windows, so as with the Event Viewer, the presence of many Critical errors in the Reliability Monitor display does not mean that your system is falling apart, nor even that it's flaky.

The Warning and Information entries always appear at the bottom of each day but the location of the Critical errors is organised by Application, Windows, and Miscellaneous depending on the component that failed. In my example you can see that all the visible Critical errors were Application errors. Critical errors in Windows should probably be treated more seriously.

If you click on any day that has log entries recorded for it you'll see a list of the log entries beneath the 'graph', as in my example above (I'd clicked on 27th August 2018 in my example - you can see it highlighted). To the right of each entry is a hyperlink called 'View Technical Details' and if I click that link for the Critical error displayed (the Microsoft Management Console error) you see more detail for that error as shown below...



The details you see are similar to those we saw in the Details tab in Event Viewer (though there are some differences which we will look at). Again, there is very little information in here that is useful to us. These reports are automatically sent to Microsoft (note the 'Report Sent' status at top right) who use them to check that there are no bugs in their code. If there is a fix available for the error you automatically reported it will be included in the next Windows Update you do. This is a very good reason why turning off all the telemetry in Windows 10 is not always a good idea.

Incidentally, note the 'Learn how to report problems and check for solutions automatically' hyperlink at the bottom. This is also useless, it just takes you to the basic Windows 10 help page.

What we're looking for in here are useful search terms so that we can look for help on the web, useful fields in here are:

The Problem Event Name: APPCRASH in this case
The Application name: mmc.exe in this case
The Exception Code: c0000374 in this case Note that if you search for this always add 0x to the front to identify it as a hexadecimal number, so use 0xC0000374 (it's not case sensitive)

The search term that I would use to search for help with this error would be 'APPCRASH mmc.exe 0xC0000374'.

Interestingly, some of the information shown in the Reliability Monitor details page is different from the information the Event Viewer shows for the same error. In the image below I've placed the Reliability Monitor details next to the Event Viewer details for exactly the same error...



You can see that whilst the details of which application (mmc.exe) is in the Event Viewer details page it's not labelled as such. Similarly, the exception code (c0000374) is also in the Event Viewer details but isn't labelled as such either. Both are shown and labelled in the description box on the General page however.

More worryingly, there is information that's not presented in the same way. For example, the date and time stamp in the Event Viewer is in human readable form and accurate to 10 nanoseconds, whilst the date and time stamp in the Reliability Monitor is a hexadecimal number (probably the number of seconds since midnight on 1-1-1970). Note that the time is given in Zulu time - the Z at the end - which is the same as UTC. I'm three hours east of UTC, hence the 07:15:05, the time is shown as local time (10:15:05) in the summary list.

Even more worryingly there is 'Additional Information' in the Reliability Monitor entry that doesn't appear at all in the Event Viewer entry. Similarly, there are hexadecimal numbers in the Event Viewer (that look like virtual addresses to me) that don't appear at all in the Reliability Monitor.

Yet both the Reliability Monitor and Event Viewer are displaying exactly the same log data. Clearly we aren't shown all the information contained in these logs. That's not surprising since most of this information only makes sense to the developer (or Microsoft).

The other feature on the Reliability Monitor 'home' screen is the blue graph that zig-zags its way across my example above. This graph is called the System Stability Index and it's intended to show you how stable your system is and how that stability has been changing over time. It uses a scale (on the left) from 1 to 10, where 10 is most stable and 1 is least stable.

A newly installed system starts out with a stability index of 10 and it's updated every hour. The index will stay at 10 until a Critical error occurs (as defined in the Reliability Monitor of course). Depending on how severe Microsoft consider each Critical error to be (and it's not published) the stability index will drop by between 0.2 and 1.0, clearly it can't go lower than 1. For every hour that there are no Critical errors (Warning and Information don't count) the stability index is increased by 0.03. You can see that it takes a long time to recover your stability index (0.72 per day) but you lose it very quickly.

The graph that you see in my example is probably worse than yours because I'm an experimenter and I quite often break things (sometimes on purpose) but my index is still averaging around 5 which is pretty reasonable I think! How useful is this stability index? It's up to you really, personally I think it's little more than a gimick and I rarely pay much attention to it. I certainly would not fret because my index was always less than 10 (as it is here) because as I mentioned earlier, Windows is a complex system and unexpected events are happening all the time (mainly in user mode). As long as your system is functioning as it should I wouldn't waste any time worrying about the stability index. Of course, if you're running Windows in a business environment, as a server hosting service for example, then you would want the stability index to be at or close to 10, but you wouldn't go messing about and breaking things on a business system (I hope!).