Using Analytic and Debug Logs

It's common for IT administrators to use the native Windows logs to search for problems.  Two of the most commonly used logs are the "System" and the "Application" logs.  However, not everyone takes advantage of the the other built in operational logs.  When you go to event viewer, you can expand "Applications and Services Logs" to reveal a vast array of logs. Many of them are empty, but many of them are capturing useful data that can help you discover what is going on with your computer.

For more information on what each of these logs and log types are visit this link https://technet.microsoft.com/en-us/library/cc722404.aspx

In this post, I want to talk about the analytic and debug logs.  The Windows Logs give you information across your system.  It will show you hardware events, system events, security events, application events, etc.  It will do this for all sorts of components and application.  The Applications and Services Logs will drill into individual components and report only on those.

To view these logs, go to View > Show Analytic and Debug Logs.  Prior to enabling this, you will mainly see operational logs in this section.

After enabling analytic and debug logs, you can now see additional logs.

If you want to start the log, you simply right click on the log and select "Enable Log".  Generally, you do not want to leave these logs running. Turn them on, capture what you need to, and then turn them off.  They tend to get large rather quickly.  Like other logs, you can make them circular logs and specify a maximum size of the file by right clicking on the log and going to Properties.

Generally, it will take some looking to find what logs you want to enable to capture what you want. In many cases, it's fairly straight forward. If you think you are having a WMI problem, under the Windows folder, go look for anything that says WMI. Start enabling those logs and see what kind of data it produces.

At first, don't worry if you know what the messages mean.  Look for errors and warnings and then search the internet for those specific messages.  You will begin to learn what events are important if you regularly use these logs to troubleshoot. 

Look for errors or warnings that occur over and over again.  Look for errors and warnings with the problem in mind.  You might be looking for a WMI problem because you run the get-wmiobject cmdlet in powershell and get a WMI error.  Keep this in mind as you go through the logs as it may help you pick out which events are useful.

Typically, when I am looking through log files, I export to a .csv file.  That way I can use filters to remove irrelevant events. I cannot emphasize this enough... USE FILTERS... There are other tools out there for parsing logs as well. (Notepad++, Baregrep, Text Analysis Tool, etc.)

Unless you have reason not to, remove "Information" from the Level column.  Search for Powershell using the search tool.  Search for the command you entered into Powershell that failed.

Finally, keep in mind that when you start one of these logs, you will get the following prompt:

If you have captured data previously and you want to keep it, make sure you export the log before you start the log up again as you will lose existing log information when you start it.