2022 Gartner® Magic Quadrant™ SIEM
Get the reportMore
In a perfect world, computers would function properly on the network at all times. There would be no issues with the operating system and no problems with the applications. Unfortunately, this isn’t a perfect world. System failures can and will occur, and when they do, it is the responsibility of system administrators to diagnose and resolve the issues. But where can system administrators begin the search for solutions when problems arise? The answer is Windows event logs.
At their core, Windows event logs are records of events that have occurred on a computer running the Windows operating system. These records contain information regarding actions that have taken place on the installed applications, the computer, and the system itself. Windows event logs include both actions taken by users and those taken by processes executing on the computer. If there is an issue with the system, they can provide an admin with crucial context for reaching a resolution.
Imagine for a moment that an application on your Windows machine fails, and you’re presented with an obscure error message that is relatively useless for identifying the cause of the problem. In addition, let’s say that there are no proprietary log files for this application that can assist you in identifying and fixing the issue. This is an example of an instance where the Windows event logs may be of use. Simply navigate to the Event Viewer (more on this later) and you will likely have a starting point for resolving the problem.
When troubleshooting any computer-related incident, it is crucial that you understand the information that’s available to you -- and in order to understand the information, you must first understand the format in which it is presented. One advantage of working with Windows event logs is that all event logs (whether collected for the system itself, for an application, or for auditing purposes) are organized in a standardized and concise manner to make them as easy to understand as possible. Let’s take a look at the major elements of Windows event logs:
So now that we know what Windows event logs are, let’s discuss Windows Event Viewer. Windows Event Viewer is a tool provided by Windows for accessing and managing the event logs associated with both local and remote Windows machines. This tool can be accessed by searching via the start menu or navigating to the administrative tools portion of the control panel on a Windows machine.
Once Event Viewer is opened on your machine, accessing the log files is fairly straightforward. In the left navigation panel, you will see a drop down labeled “Windows logs.” Expanding this drop down will allow you to select the event log file that you wish to view. The major log files that will likely be used for most Windows troubleshooting are application, security, and system. Left-clicking on any of the keys beneath the “Windows logs” drop down will open the selected log file in Event Viewer. Note: If you wish to view the Windows event log files on a remote machine, simply right-click on the Event Viewer link in the left pane and select the option to “connect to another computer.”
The display of the log file is divided into two panes located in the center of Event Viewer. The top pane displays the major details surrounding each event in a list format. This can be sorted by clicking on any of the headers located at the top of the top pane (see image below). The bottom pane displays the details associated with whichever event record is selected from the list of event logs above.
As mentioned earlier, the Event Viewer is typically utilized in response to reported system, application, and security issues. It’s possible for the administrator to search through the logs randomly in hopes of identifying the problem; therefore, the Event Viewer is only useful if the administrator can find the event logs related to the issue being experienced. With that said, finding a particular event record requires context.
This context will almost certainly include the time at which the issue was encountered and the application or system process in which the problem occurred. In addition, the user and computer name will be valuable. This information can be leveraged to search for the event by selecting the correct log file and scrolling through the entries, or it can be used to filter the event records to find the relevant information more efficiently.
After selecting the appropriate log file, you can filter by clicking on the “filter current log” link in the actions pane located on the right side of the Event Viewer. This opens the filter modal window (shown below) where the user can make the appropriate selections to filter the records that will be shown in the selected log file. For instance, if the administrator wishes to limit the results to “critical” events triggered by the user “jdoe,” then he/she would check the box labeled “critical” beside the event level and enter the username “jdoe” in the text area labeled “user.” After clicking “OK,” the Event Viewer would filter the event records accordingly.
Another useful feature of the Event Viewer is the ability to save event logs for use outside of the component. This is done by selecting the appropriate log file in the left pane and then clicking the “save all events as” link in the actions pane on the right. This link opens the traditional “save as” modal, which will allow the administrator to choose a location and filename for the exported event records.
In some instances, it may make sense to clear the event logs. This can be done through Event Viewer as well. After selecting the appropriate log file to clear via the left navigation, there is a “clear log” link located in the actions pane on the right. Clicking this link will open a confirmation dialog where the administrator will be asked to confirm the decision to clear the selected log file. Event Viewer gives the option to save the event logs upon clearing or to clear without saving.
Above, I discussed the steps to identify, search, and filter the event log files in order to try to diagnose an issue with a Windows machine. This is a primary method of troubleshooting an issue using the event viewer. It is just as important to take the information provided by the event log and use it appropriately. Many of the recorded events will have a corresponding event ID and message. The message may be enough to go on to resolve the issue; however, even if it isn’t, it is usually a good place to begin researching the issue. Performing a search online with the event ID, message, and associated source will likely turn up something useful.
While the Event Viewer is a good place to start when beginning to analyze Windows event logs, you may not like the interface. In this instance, consider Sumo Logic as a log management platform for collecting and monitoring your Windows event logs for easier log analysis and issue investigation. The process for setting up the Windows event log collection in Sumo Logic is pretty straightforward. After installing a Sumo Logic collector, you simply need to configure a Windows event log source for remote or local collection.
The process doesn’t take long and makes it easier than ever to glean valuable insights from Windows event logs (something a system administrator is sure to appreciate). This is helpful in cutting down on the time it takes to diagnose and resolve any bug, whether system, application, or security-related. For a full rundown on the Sumo Logic configuration process, be sure to visit the Sumo Logic documentation for configuring local and remote Windows event log sources. Sumo Logic now makes getting started even easier with a free trial, helping businesses test out the log management platform for themselves at no cost.
Reduce downtime and move from reactive to proactive monitoring.
Build, run, and secure modern applications and cloud infrastructures.Start free trial
Observability has become one of the most important areas of your application and infrastructure landscape, and the market has an abundance of tools available that seem to do what you need. In reality, however, most products – especially leading open-source based products – were created to solve a single problem extremely well, and have added additional supporting functionality to become a more robust solution; but the non-core functionality is rarely best of breed. Examples of these are Prometheus and Grafana.