Researching Event Log Errors in Windows 7

Home > Blogs > Windows 7 > Researching Event Log Errors in Windows 7

Researching Event Log Errors in Windows 7

Like This Blog 0 Steve Fullmer
Added by March 26, 2014

This morning’s email delivered a request from a former student. Following acquisition of a brand new Windows 7 system a few months ago, the event log started to fill with error and warning messages. As of this writing, they claim more than 7000 (you read that correctly), warning and error messages in just a few months. The system is still running, although Internet services are intermittently interrupted.

I continue to teach – ‘find and repair the cause, rather than merely treating the symptoms’ – and the Event Viewer is an ideal starting point.

Administrative Events is the default Custom View provided in the Windows 7 Event Viewer. My student remembered to Right-Click (Alt-Click) on Administrative Events and select Save All Events in Custom View As … .

Having the exported .evtx file enabled me to assist with some research on his behalf.


Opening his file indeed reveals more than 7,000 administrative events. (I am glad he used the filter of Admin Event Log, given that this was 5 MB, the entire log file must be enormous.)

Whether you are receiving assistance, or merely want to have a snapshot as reference during your research, a saved copy is a simple way to perform research from a clean, and functional system.

I have created several videos in my Troubleshooting Windows 7 series that demonstrate the use of Event Viewer.

The focus of this blog, is assisting with the subsequent research. So, on to the Admin Event Log.


The events are listed in chronological order in the above log snapshot. You may choose to sort any of the columns, for instance Date and Time, Source, or Event ID to look for patterns. In fact, you probably want to start by looking at each sort to discover when errors started to proliferate, which occur most often, and which tend to follow others.

Select one of the entries, by clicking it once. I chose Event ID 4 since the Source looked interesting (less common?), and lower Event ID numbers tend to be kernel or driver related and may often point at a root cause that leads to subsequent warnings or errors.


Read the General Information. Take a screen shot or snapshot (I used Snagit from TechSmith for this blog). Make some notes focusing on keywords, specific files identified, or devices named. These aim you toward possible root-cause.

Then select your favorite search engine. You might even try a couple of different search engines to see which results appear at the top of the search result list consistently or most often.

Search using a string that looks like ‘Event ID nnnnn <keyword> <’keystring’>’  where nnnn is the Event ID, and keyword or ‘keystring’ are the notes you took while looking at the General description. Make sure you use the quote ticks if you enter a message string that contains spaces.

For the above screenshot, I searched for Event ID 4 k57nd60a. The number one hit took me to EventID.Net for a general description. is a good general source for identifying the source of Event Log errors. You may obtain general information for free, and more detailed information with a low cost subscription. Subscription includes a free event log analyzer that might be an alternative to intense manual searches, and that can help with event pattern and root cause recognition. EventID is not, however, a repair tool.

The results for Event ID 4 in this case suggest a problem with the Broadcom Netlink Gigabit Ethernet Adapter driver. One simple repair option is running the system file checker (SFC) from an elevated/administrative command prompt. Even better, running it from the Recovery Environment or booting from an external Pre-Execution (PE) media. SFC /Scannow will repair any damaged drivers by replacing them with the originals from the Microsoft OS image .wim file.

Wait a minute. Never rely on a single source or review a single Event ID result before taking action, however. That would merely be treating the symptoms of single instance.  We want to find the culprit so that the issue does not return.

As I searched for results based on additional, different Event IDs, I continued to gather additional information. The most frequently visited sites included:

Note, I was not looking for a quick fix. You want to research all the causes to look for a pattern. If you fix the wrong root cause, you may remove a symptom, though cloud the true disease.

After researching five or six Event ID’s, an obvious pattern related to networking started to emerge. Suggested solutions for a new Windows 7 platform included disabling IPv6, changing the default NIC drivers, and taking ownership of a registry key to affect a manual change. Note that not a single one of these changes would resolve all of the warning and errors identified in the Admin Event Log.

Keep looking until you find the pattern, and before you start radical, component replacing surgery. Even if necessary, you don’t want to race toward total OS or system replacement. After all, in this case it is a new PC, and either the OEM or Microsoft should be able to help repair or replace a system under warranty.

Don’t be lazy. Or fearful. Results can be plentiful. Capture them all, since they may be components of the overall solution. Bookmark links, or copy and paste material into a Word document. Place the source link before or within any captured suggestions so that you may return to the information source. Whether you find the information useful or not, input for future researchers helps the community. Provide your lessons learned, and the lessons learned by others will help your future endeavors.

Ultimately, we found two symptoms related to a particularly nasty variant of the ‘ttdasndku.exe’ malware package that must have been accidentally acquired within days of installing and connecting the new system to the Internet, before all the necessary hardening, firewall, and anti-malware components were enabled and fully configured.

Another lesson learned. Don’t connect your system to the Internet until you have a plan for secured access and have it implemented. That is, unless you desire another opportunity to become proficient with analyzing and researching Event Log entries.

Best of luck!   See you in the classroom or online.

Steven Fullmer
Interface Technical Training Staff Instructor

Videos You May Like

A Simple Introduction to Cisco CML2

0 3902 0

Mark Jacob, Cisco Instructor, presents an introduction to Cisco Modeling Labs 2.0 or CML2.0, an upgrade to Cisco’s VIRL Personal Edition. Mark demonstrates Terminal Emulator access to console, as well as console access from within the CML2.0 product. Hello, I’m Mark Jacob, a Cisco Instructor and Network Instructor at Interface Technical Training. I’ve been using … Continue reading A Simple Introduction to Cisco CML2

Creating Dynamic DNS in Network Environments

0 646 1

This content is from our CompTIA Network + Video Certification Training Course. Start training today! In this video, CompTIA Network + instructor Rick Trader teaches how to create Dynamic DNS zones in Network Environments. Video Transcription: Now that we’ve installed DNS, we’ve created our DNS zones, the next step is now, how do we produce those … Continue reading Creating Dynamic DNS in Network Environments

Cable Testers and How to Use them in Network Environments

0 735 1

This content is from our CompTIA Network + Video Certification Training Course. Start training today! In this video, CompTIA Network + instructor Rick Trader demonstrates how to use cable testers in network environments. Let’s look at some tools that we can use to test our different cables in our environment. Cable Testers Properly Wired Connectivity … Continue reading Cable Testers and How to Use them in Network Environments

Write a Comment

Share your thoughts...

Please fill out the comment form below to post a reply.