Windows Event Logs
A lot of this was copied from old notes. So, these may be good notes to have reviewed. For the time being, be cautious about details found in this section.
This section is largely about the actual log files.
For information about specific types of messages found in the log files, also check out Windows Event Log Messages. For example, that resource may provide some details about what a specific message means.
Some further information about writing a log entry may be found from behind the scenes: reporting events.
- The classic Windows Event Logs
These logs have been (retro-actively) given a name when viewed by Windows Server 2008 (or probably Windows Vista), when using the Computer Management over RDP to view an XP machine. (Maybe that name should be the title of this section of documentation.)
These are supported by Windows NT and operating systems derived from NT code (including XP and newer mainstream (desktop/server) Windows systems). (This is not supported by Win9x/ME: For details on a similar type of log for these operating systems, see the Application-specific information for Windows Scripting Host.)
- [#wnvwevtl]: Viewing the Event Logs
- Graphically: Opening the Event Viewer
One way is to run “
” (or “
” which should use the .MSC file which may be in the %windir%\System32\ folder). Alternatively, use the Event Viewer interface that is part of “Computer Management” (“Compmgmt.msc”). Remote systems may be accessed using Computer Management's “Connect to another computer ...” menu option (on the Action menu, or under the shortcut/context menu when the name of the viewed machine is highlighted). Alternatively, use “Server Management” if the machine is a server. (Further details are mentioned in the section called “Computer Management”, and the quite similar “Server Manager”.) Alternatively, open up
and add the snap-in for Event Viewer or Computer Management.
- Command line tool
This may vary a bit based on what operating system is being used?
“Command Line Kung Fu” Blog, Episode #66: “Log Jam” mentions this software, as well as using
/fimultiple times in order to have multiple conditions.
- Using WMI to parse logs
That may be fairly slow: a simple query has been known to take nearly 40 minutes on a desktop machine (which had a recent record number of about 750,000 : the system has been running for years). e.g.:
Or, for more details:
Time restrictions can be added. e.g.:
"Logfile=LIST BRIEF /format:htable.xsl
'4776') and TimeGenerated >=
'12/25/2012 12:59:58'AND message like
(Some of that was inspired by SANS PDF page 28. (not currently tested extensively, at the time this was written.))
More information about using WMI is available (via the hyperlink).
(This does exist in Windows 7.)
qecan be used to query events.
Some information used to be here, but the amount of information kept growing, and so information on this program can now be seen in a new section: Using
to Query Events.
- Other formats
Microsoft KB Q927229: Win2KRK Tools for Administrative Tasks refers to a
“Dump Event Log”. NirSoft's MyEventViewer may support command line options to convert information from a log file to another format.
- Generally preferred logs
If the issue is with something specific, like DNS or PowerShell, and there is a log specifically for that topic, it probably makes sense to start with the specific log. So, start by checking to see what logs are available.
Otherwise, for hardware issues, start with the system log. The security log may also be useful to know some specific things that typically go in the security log, such as when a service stopped or started, and when the system rebooted. For most other issues, start with the application log. (Software problems generally go into the Application log. If a service has a problem, it usually goes into the Application log, but the System log's details about services having issues, hardware issues, and sometimes other issues, is also helpful. So, for issues related to services, the Application log and the System log might be approximately tied regarding which one is nicest to check first, and checking both may often be worthwhile.) To see if anybody tried to authenticate, the Security log may have useful information.
TechNet: Event Viewer (specifically, the MSDN article on Event Sources (“Event Descriptions” section)) and and MSDN article on Event Sources provide some guidelines on what types of software/messages should be using which log. The security log may be limited to
(noted by Wikipedia's Article on (Windows) Event Viewer: “Overview” section).
- Types of info found in the event logs
There are key pieces of information that each Event should have. Combining these types of events can lead to successful automation, including putting these details into a search engine, having a computer respond automatically to certain types of alerts, and tracking. An example of tracking is so that a report can be provided on often events with a certain combination of these key values, such as “Error events on the System Log coming from eventlog with an Event ID 6008”, occur to a certain type of computer such as a computer with a specific unique name, or a group of computers on a certain subnet, or computers at a certain location or computers owned by a certain organization.
- Log name
(This section was written before/without consideration of being in a section about info found WITHIN the logs.) (An update may be prudent.)
A log is used as a record of logged events. Different logs are mainly different collections of logged events. Wikipedia's info on Windows Event Log may suggest a 300MB limit with OS's older that Vista?
The primary category of logs is which log the event goes to. This is primary because, when using the Windows Event Viewer, just one of the logs may be viewed at a time. (To view multiple logs, multiple copies of Event Viewer may be used.)
There is some available documentation for the purpose of some of the main logs:
- Security Log
Microsoft's “Event Sources” documentation on MSDN says “The Security log is for system use only.” TechNet: Event Viewer, “Event Logs” section describes some types of information that may be placed into that log. Attempting to use “
” (followed by some other parameters) results in the command showing “
” (followed by a blank line). The security log may be intended to be limited to
ERROR: Access is denied. Custom events cannot be created into security log.
(noted by Wikipedia's Article on (Windows) Event Viewer: “Overview” section)
- System log
- Microsoft's “Event Sources” documentation on MSDN says “Device drivers should add their names to the System log.” TechNet: Event Viewer, “Event Logs” section has some information, including these notes: “The System log records events logged by the” [operating system's] “system components. For example, the failure of a driver or other system component to load during startup is recorded in the System log.”
- Application log
Microsoft's “Event Sources” documentation on MSDN says “Applications and services should add their names to the Application log or create a custom log.” TechNet: Event Viewer, “Event Logs” section says “Applications and services should add their names to the Application log or create a custom log.”
(Of those two options, using the general “Application log” is frequently better for important events, as many IT professionals will typically look there first, so there is less searching. However, if a program is going to output numerous log entries, a custom log may be more appropriate than using the system-wide log that is shared with different programs.)
As indicated by the notes about the “Application” log, software may use “a custom log”. So a system may use additional logs besides just those three logs which are very commonly used (by many pieces of software). Running “
” (or the longer version, “
”, which lists the logs on a system, output 1,051 lines on a (sample non-special) Windows 10 machine.
Logs with no entries in them may look different in Event Viewer. (So, a blank log may be represented by a different icon.)
- [#wnevttyp]: Event type/Keywords
There are five event types.
Very often problems encountered by key software will use an “Event Type” called “Error” or an “Event Type” called “Warning”. Searching for these things in an event log may help identify when the computer first started detecting some problems. Resolving issues of these types may help troubleshooting later (because a person can quickly scan through the event logs for entries with the red or yellow icons) and may help resolve some problems or potential problems. (When viewing the security log, problems are more likely going to be noticed when using the type called “Failure Audit”).
These are called “types” by the MSDN documentation on “Event Types”, but the Event Viewer in Vista has a sortable column for these types and calls the column “Keywords”.
Note: The type of event in an application or system log is not an entirely reliable way to determine how critical to consider the event that is being described by the logged event. For instance, if a system begins to run out of memory to the point where the operating system starts to have troubles, event logs may start showing errors and warning messages occuring at a time when the system begins to have some very noticable troubles. However, a system may have an Info Event that is rather serious. (The phrase “an Info Event” refers to an event using the “Info” type.) For example, an Info Event from the source “Application Popup”, and with Event ID 26 and a description of “The application failed to initialize properly (0xc0000###)” (with some specific hexadecimal digits instead of the number signs), may reference an error, providing a a clue that problems started earlier. (This specific example might be discussed a bit further in a section about Windows Event Logs: Event Source: Application Popup.)
There are some traditional visual representations:
A red circle. In Windows XP, this also commonly had a white X in it.
(In Windows 10's Event Viewer, an Error message was seen with a white exclamation point. That feels more similar to the Warning type's traditional representation, and so using the exclamation point is not recommended.)
- A yellow triangle, possibly with a black exclamation mark in it
- A white “speech bubble”, possibly with a blue lowercase “i” in it
- “success” audit
- A key
- “failure” audit
- (not sure offhand. A lock, maybe?)
Documentation: MSDN: Event Types provides the intended description/purpose of each of these “types”.
- [#wnevtlvl]: Event Level
The event types seem to often be related to the numeric “Level” of an event. In newer versions of Event Viewer (likely starting around the time of Windows Vista), the Event Viewer can display an event's raw data, and can also place the Event's data into some XML. When viewing the XML, the tag named “Level” will show a number that corresponds to the Event Type. The numbers, and corresponding types, are:
- 0 = Information or “Audit Success”
- 1 = Critical
- 2 = Error (Red circle, white X)
- 3 = Warning
- 4 = Information
- 5 = Verbose
So, for example, using
command to create an event using the Error type will result in an event that specifies Level 2. Similarly, creating a Warning resulted in an event that was Level 3, and creating an informational event resulted in an event that specified Level 4.
When using the Event Viewer graphical program's “Filter Current Log” screen (in Windows Vista and newer), checking the “Information” checkbox will add “Level=4 or Level=0” to the filter. So, informational events may use either level. Azure LogLevel documents zero to be “logs at all levels”. Using Level 4 seems to be more clear about indicating that the intended type is an Information event, so that is the preferred number that is recommended for anyone creating an Information event.
XML data suggests that logs using the “Audit Success” icon havel Level 0. MSDN page: “Event Sources” indicates that Audit Success has a value of 8. (However, information on that page might not apply. That page also indicates Warnings have a value of 2, so that page might not be using the same values as the events.) Also, MSDN: Event Types had a &lduqo;Community Addition” comment noting that Type 8 seemed to indicate Audit Success.
MSDN page: “Event Sources” indicates that Audit Failure has a value of 0x10, which would be a value of 16. (However, that page also indicates Warnings have a value of 2, so that page might not be using the same values as the events.)
Although this “level” seems similar to event types, a “level” does seem to be different than a type. MSDN article provides some numeric values for the types (although the order of Error, Warning, and then Information does seem to be common).
- Event Source
The Event Source is how a program identifies itself. As evident by the existance of the
command, it is rather trivial for a program to be able to use any desired string as the “source”.
It is common, though not required, for a program to be registered, showing up in HKLM\System\CurrentControlSet\Services\EventLog (in the registry). (MSDN page: “Event Sources” indicates that the subkeys underneath that location are called “event sources”.)
(If the amount of information shown is more than desired, consider leaving off the
/s, and be prepared to specify a sub-key like
On a (specific, sample, non-special) Windows 10 machine, adding a
/Cto the above command showed there were
results. Another command, which is supposed to list event publishers, “
”, showed 1,078 entries.
According to MSDN article on “Event Sources”, Community Addition #1 (by the_gigi_hotmail.com): “EventSource name limit” says, “The EventSource name is limited to 21 characters. I discovered it via trial and error. If you specify a longer name nobody complains not when you create the event source and not when you write an entry. However, the entry is simply not recorded.” In a later comment, Sune Pelle clarified that the limit might not be enforced in some location(s) (where a source was “registered”, possibly referring to the registry), but the limit may exist elsewhere, affecting “the event log source display” (presumably in Event Viewer (MMC)).
- “Event ID” number
People often use these Event ID numbers to help identify specific error messages. The Event ID number should be considered to be a third piece of information. Other pieces of information, which should probably be used first when filtering, are the Event's “Source”, and which event log is being used. The combination of all of these values can be helpful when looking at “Windows Event Logs”-related online resources.
Actually, the “Event ID” value may be mentioned rather frequently, even moreso than the Event Source. However, there have been cases of an Event ID number being used by multiple sources. In some cases, the other sources seem to be using some common code, and so the Event ID seems to end up having some useful meaning regardless of what source is used. However, there can be other times when the Event ID is used by a different source and have a very different meaning. This is why the the event's “Source” should be given some attention, instead of people only paying attention to the Event ID number.
When using the
/?to display help, that command will note that “
valid custom message ID is in the range
” That range is only a limitation of that program. Definitely, don't think that 1000 is the largest Event ID that can exist. Events are commonly found with higher Event ID numbers than that.
of 1 - 1000.
- Task Category
It seems this information is often ignored (without negative consequences).
Finding out when a problem occurred can be helpful, possibly to match when a user may have been using the system but more often such a benefit is found on machines with automated tasks that are scheduled for a specific time, as that may help find out what programs were running at the time of logged events.)
Note that with the “
” program, there is some sort of limit. (Maybe it is 255 characters for the whole command line; or maybe that limit is specific to just the description text?)
The previously-listed properties are some of the most common properties that people pay attention to. For instance, the
command has parameters for specifying common properties.
There can be additional properties related to an event (like the time that the event occurred). A list of properties actually logged can be seen using “
”. (This is particularly true when outputting in XML, by not using
/f:text”. For more details on that command, see Using
to Query Events.) Some documentation related to these properties can be seen by MSDN: Event (Log) XML Schema; particularly the sub-section: MSDN: Event (Log) XML Schema: EventScheme Elements.)
If troubleshooting, quickly scan for event types that are undesirable: Errors or warnings (for many logs), or login failures (for others). Other than perhaps the type of event (although even that can be misleading, because Info events may have some useful information including reporting errors), the main thing to look for is going to be the “Event Source”. An “Event ID” is a number that is often useful for automation,
Fortunately, a lot of software that uses privileged resources, such as device drivers, and even a lot of other types of software, do tend to create decent log entries (that identify the Event Source somewhat sensibly, and uses a fairly unique event ID number for unique types of events which often helps trackability, including the ability to track down solutions that may have been found by others).
- Limitations to this log file format
- e.g. size limitations/etc.
- The newer format, called “Windows Event Log”
- Wikipedia's article on (Windows) Event View: section called “Windows Event Log”
- Tracing down a source
- Possibly infeasible
In theory, it may not be possible to easily trace down an source. A simple reason, at least for low-numbered Event IDs (between zero and 1001), is seen by what the
program can do. The program can make a log entry with any source or Event ID. Since it is rather trivial code to be able to run
doesn't log any information about what called
(other than the passed information, such as the fully customizable value used for the “
/SO” parameter), a program can easily create a log entry without being easily traceable. Also, in theory the same “source” may be used by multiple programs. For example, when working with multiple computers that may be using various software products, a reference to SAV could mean Sophos Antivirus or it could reference Symantec AntiVirus.
- Registered sources
Although an event log does not need to be registered (as shown by the possibility of the
command), some sources do register themselves.
- Seeing registered sources in Microsoft Windows Vista (and Server 2008) and newer
A list of sources is available by running:
For further information about a single source, see:
The quotes are optional if there isn't a space in the service name. As two examples:
Perhaps methods from Server 2003 and/or XP may still work?
- Seeing registered sources in Windows XP and/or Windows Server 2003
Some Event Sources may be found under HKLM\System\Current Control Set\Services\EventLog, either under Application (and then listed by the application name) or under System (listed under the driver name). That may or may not be too helpful, as these events often aren't described. However, the EventMessageFile may be a list of files separated by semi-colons (with most entries having just one list), and those files may be
*.DLL files but also may be
Reading “the content” of those files requires use of “Microsoft's Event Log APIs”, according to EventID.Net's information on Event Sources, a page that offers a program called MessageParser to subscribers of that website.
- Checking drivers
An idea, which may or may not be true, so this may or may not pan out well: Often the source may be named after the “Module Name” of a driver. A bit of information may be found by running:
driverquery/FO LIST /V
This will typically show a “Display Name” and a “Description”. However, the “Description” is often the same as the “Display Name” and in some cases (perhaps half of the cases?) the “Display Name” may often be the same as the “Module Name”. So in many cases this may not help at all, but additional information (from those other names, or possibly the file path) may be helpful.
Other ideas might be to check out the list of services. See Windows Service Names and/or NirSoft's ServiWin which shows info on services and drivers. Perhaps also see: NirSoft's Driverview. Wikipedia's List of Microsoft Windows Components may also mention names of some important software that may often be found running.
The “Event Message Browser” from Netikus.net's freeware NTToolkit may also be a free solution, according to Blog Entry called “Event Log Message Files (The Description for Event ID ... cannot be found)”. That same blog article also references using EventSentry (from EventSentry.com).
Beyond these ideas already presented, the best way to learn about unknown event sources may be to use information that isn't pre-existing on the computer, either by using an Internet search engine or by reading some other resource. (e.g. see the “Service name” column of Wikipdia's list of Microsoft Windows components (section on “Services”).)
- [#wevtlnet]: Online resources
- Microsoft's event info
- Microsoft Events and Errors Message Center: Search page can seem a bit inflexible. Try leaving the “Version” at “--All Versions--” so that information isn't ignored just because it was initially provided for, and categorized under, an older version. (For example, looking up Event ID 55 from the Source of “ntfs” and the product "Windows Operating System" shows things for version 5.0 (Win2K) and 5.2 (Server 2003), but not 5.1 (XP)). Consider just leaving the other fields blank.
This site provides a way to look up items by Event ID and then by source. Subscription allows access to download EventID.Net's MessageParser program, may click directly on hyperlinks to Microsoft articles (e.g. a hyperlink to M###### refers to a Microsoft KB article number ######), and can read the “English, please!” sections.
The “English, please!” sections may help gives some context, such as what the program does and perhaps what types of results the software expected (instead of the results that the software actually got). These alternate descriptions will rarely lead to resolution, although they might be useful, especially for newcomers, to gain some context.
Sometimes the comments may refer to a technical resource. For paid subscribers, the technical resource may be accessed simply by following a hyperlink to the resource. For others, the hyperlink will lead to a web page encouraging people to subscribe. If the technical resources starts with the letter M and then just contains six or, less commonly five digits, that is likely a reference to an MS KB number. Otherwise, the technical resource might be located in the “Links” section further towards the bottom of the web page, but the most clear method to identify the technical documentation being referenced may be to just subscribe.
A good thing about an EventID subscription: It's priced fairly reasonably, so it's generally fairly affordable for a paid professional who uses Event logs enough that such a website is repeatedly useful for.
EventID.Net's URLs are something that can easily be used to automatically point to information about an event. (This may be useful for an automated ticketing system: since automation is occurring, automatically creating a potentially useful hyperlink may be handy.) For an example of what such a hyperlink might look like, http://eventid.net/display.asp?eventid=55&source=Ntfs&phase=1 will show information about messages from the Event Source called “Ntfs” and which use the Event ID 55. (Generally less useful, information about a specific Event ID number, regardless of the source, may be seen by removing everything after the first ampersand in that URL.)
Information on the source may be viewed by following the hyperlink on the page that is about the combination of the source and the Event ID, which goes to a page such as http://eventid.net/source.asp?source=Ntfs but such pages generally don't have as much super useful information. Therefore, the web visitor is often better served by checking out another resource if the source is unfamiliar.)
Note that a lot of information on Event ID is frequently not applicable. For example, references to a hotfix that resolves a problem is great information for people to whom that will be a working solution, but for people with a newer operating system or who already have the fix applied (by using a later service pack or by using the hotfix) won't likely find resolution from such hints that may be on the EventID.Net site.
- ][Cyber Pillar]['s list of events
This may not be as volumous as other resources, but if there is information available then that information may be more limited to what is likely to be relevant and accurate. (In contrast, EventID.net may more frequently point to some hotfixes of older operating systems that may not be useful for users of newer operating systems.) The Event log entries section may have some info about a few of the more common events. More details may be found in problematic messages found in the Windows Event Log(s).
- Ultimate Windows Security
This appears to allow easily customized URLs, by specifying the name of the log file and the event ID. For instance, UltimateWindowsSecurity.com “Security Log” Encyclopedia: Event ID 4624 used this as a URL:
- ChicagoTech.Net's Windows Event ID page
- This web page lists dozens and dozens of events, and some proposed resolutions.
- SpiceWorks Community
This is sometimes seen in some search results of fairly taxing issues. Perhaps there is a search box at SpiceWorks Community Page: section about Windows Event Logs.
- [#evtlogen]: Some events (event log entries)
Here is some information about some types of events, generally categorized by a combination of which event log the event was logged to, which Event Source was provided along with the logged information, and which Event ID number was used.
- [#noevtdsc]: Missing info
- The log entries
What this looks like:
- As seen in Vista
The description for Event ID ### from source WhateverSource cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer."\n\n"If the event originated on another computer, the display information had to be saved with the event."\n\n"The following information was included with the event:"\n\n(Any info that was included.)
- As seen in Windows Server 2003
- “The description for Event ID ( # ) in Source ( WhateverSource ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description see Help and Support for details. The following information is part of the event:”
What this indicates is that the log entry used a Message File (I think??), but there wasn't an entry in HKLM\System\Current Control Set\Services\EventLog under a key named after the log, and in a key under that named after the Event Source, in a REG_EXPAND_SZ value named EventMessageFile.
If the description shown in event viewer is what is shown below, but also says \n\n“the message resource is present but the message is not found in the string/message table” (after any data that was included), that means the registry key (folder) existed but didn't include the EventMessageFile data (or whatever other key is needed for messages to be fully shown).
In such a case, finding the relevant message file, adding the relevant entry into the registry, and restarting the event viewer may actually cause existing event logs to have more readable details. (This doesn't likely fix a problem that may have caused the event to be logged, but it may provide more information that will help.)
The actual message file used may be (or perhaps necessarily is) a file with an executable header, and could be
doesn't actually contain useful information, so an EventMessageFile pointing to
may technically work to produce log entries but isn't likely to resolve the issue of readable information still lacking. Event Log Blog page on Log Message Files says “Oracle is notorious for not including the message file, in particular with the Express Edition.” (Acronis may be another???)
- [#wnlogrbt]: Rebooting
The most reliable way to tell when a system restarted is to look in the System Log for events from the Source called EventLog. When the system starts up, the System log will have an Info event with Event ID 6009 that identifies the operating system, and (immediately) afterwards will have an Info event with ID 6005 showing that the Event Log service started.
Before these events, there will generally be an Info event with Event ID 6006, showing that the Event log service was stopped (and this suggests that the operating system was shut down cleanly), or an event which is of the “Error” event type and which uses Event ID 6008. The presense of a 6008 error from EventLog indicates that the system shutdown was not done cleanly. (It is possible that the system remained up sometime past the point of the time referenced in the Event ID 6008: Perhaps that is when the registry files were last modified? Microsoft KB Q326564: “Event ID 6008 is unexpectedly logged to the System event log after you shut down and restart your computer” describes a specific known issue with Server 2003 (fixed via a Hotfix) but also provides information about the cause in that scenario: the Event Log service wasn't notified about a shutdown event.) An Event ID 6008 does generally indicate the system ran the risk of corrupting the file system structures. (The other type of event most frequently found from EventLog is an Info event with Event ID 6013.)
The other event source which is sometimes seen in the system log and presents information about rebooting is USER32. This may show what user or process initiated the reboot, as well as any reason that the user entered when performing the reboot (if a reason was supplied).
After the computer starts and notices the last shutdown wasn't clean, the operating system may ask the user who logs in to enter the cause of the shutdown. (This may be even more annoying because the user may not know the cause of the shutdown, and may be interested in viewing the event logs to find out the cause, but the login session won't allow the user to do anything, including viewing the event logs, until after some sort of answer is provided. Such an answer is not likely to be very informative.) ??? I'm not offhand sure what this event looks like. This may be more likely to happen with a “Server” operating system ???.
If the process that initiated the shutdown is
, this is Windows Update Automatic Updates (command line tool? client?).
A log may show a warning-type message from USER32 and Event ID 1073 that says that an attempt to restart or shutdown “failed”. Some example information is from MS's page on this. However, as noted by EventID.Net's info on Event ID 1073 from User32 (type “Warning”), this can be easily caused by the user choosing to abort a shutdown. For example, if a program with an unsaved document is open, part of the way that the application responds to a request to be cleanly closed may be to ask the user if the unsaved document should be saved. If the user selects “Cancel”, this may cause the program to reject the request to cleanly close, and the operating system may abort the shutdown with this sort of warning.
Source WindowsUpdateClient Event ID 22 may say “Restart Required: To complete the installation of the following updates, the computer will be restarted within 15 minutes”. To try to combine updates to use fewer reboots, see Microsoft KB Q296861: How to install multiple Windows (NT 4.0 - Server 2003) updates or hotfixes with only one reboot.
- Windows (Automatic) Updates
- If about this may be found from Event Sources of WindowsUpdateClient, Windows Update Agent, NTServicePack. Event Source Servicing (Event ID 4371). Also, some information may be in the %windir%\WindowsUpdate.log and %windir%\SoftwareDistribution\ReportingEvents.log files.
These events just listed are just some of the more common events worth knowing about. For details on some more specific events, see Windows Event Log entries: Fixes for specific issues.
(End of details on specific events.)
- Specific Windows Event Log field entries
- [#winlgsrt]: Recommendations for sorting Event info
For end users, sorting by date and then by time will likely help provide a rather chronological explanation of events.
Many web sites that provide information about Windows error logs seem to sort by Event ID. In some cases that may be more useful than trying to look information up based on a source. As an example, an Event ID 55 may come from various disk-related sources and all have similar meanings. However, very often a more logical way to sort are by Source. This way, various messages from the same program are in the same area. If an error message isn't fully understood by somebody, perhaps a person relatively unfamiliar with the software reporting the error, seeing some of the other messages from the same Event Source might help the person to understand the purpose of the software. So, check by source. If a choice needs to be made about the default view for categorizing error messages or information related to such messages, sorting by Event Source first will likely be best.
The next most useful sorting factor will likely be by log type. Then by Event type. Then, finally, at long last, the Event ID may be the next-best method to sort by.