Windows Event Log High CPU: Find What Keeps Writing Events

Windows Event Log high CPU usage needs a source check before you clear anything. A program or driver may be writing events repeatedly, while a monitoring tool can create work by reading the logs too often. First confirm that the busy process hosts the EventLog service. Then inspect events from the same time, save the relevant log, and repair the component behind the activity. Clearing a log may remove your best clue without stopping the next event.

The steps below focus on Windows 11 and Windows 10 PCs. A domain controller or event-collection server needs its administrator involved before changes to logging, retention or forwarding.

1. Confirm which process is using the CPU

Open Task Manager, sort Processes by CPU, and expand the busy Service Host row. Record its process ID (PID) from Details. Use Go to service(s), where available, to see which services belong to that process.

You can also run tasklist /svc /fi "PID eq 1234" in Command Prompt, replacing 1234 with the current PID. The command lists the services hosted by that process; it does not stop them. Look for EventLog. If several services share the PID, their presence is not a breakdown of CPU consumption. [1]

• EventLog is in the busy host: continue with the event checks below. Keep the time of the slowdown with the PID.
• Event Viewer or mmc.exe is busy: close the viewer after saving your work and compare CPU again. Loading or filtering a large view is a different problem from sustained background service load.
• WmiPrvSE.exe is busy: use the WMI Provider Host troubleshooting guide. A tool querying logs through WMI can be the initiating client.
• Another service is identified: follow the matching branch in our Service Host Local System guide.

For high disk usage, sort the Disk column too. Open resmon from Win + R and inspect Disk activity during the slowdown. A disk at 100% active time is not the same measurement as CPU at 100%, and neither tells you the cause by itself.

2. Look for the event that keeps returning

Open Event Viewer and start with Windows Logs → Application and System. Focus on the few minutes around the slowdown. If an event names another channel, open that channel under Applications and Services Logs. Administrative Events is an aggregate view; record the actual log named in the event.

Use Filter Current Log to narrow the time window. Initially keep all event levels: a flood can consist of informational entries as well as errors. Avoid repeatedly opening an unfiltered view of every historical event on a struggling PC.

For the repeated entry, write down:

• Log name and Source/provider: which component reports it.
• Event ID and message: the ID only makes sense with its provider and event details.
• Recent timestamps: whether new copies arrive during the slowdown.
• Named application, service, device or error: the next component to investigate.

Compare equal time windows. Filter the same provider and ID over a short interval during the problem, then an interval of the same length after one change. Use the filtered event count and the CPU trend together. Do not compare the total size of two logs or assume an old red error icon explains today’s load.

A repeated event is a lead, not an automatic culprit. It may report another component failing, or be a consequence of the slowdown. The useful test is whether a targeted change affects both the repeated activity and the original symptom.

3. Save the relevant log before making changes

Right-click the relevant log and choose Save All Events As, or save the filtered events if that is the available action. Keep an .evtx copy and note the time window and trigger. Store it privately: logs can contain account names, computer names and other identifying information.

For a command-line export, open Command Prompt as administrator. If %USERPROFILE%\Downloads exists, run wevtutil epl System "%USERPROFILE%\Downloads\System-before-fix.evtx". Replace System with Application when that is the relevant log, and use a different output filename. This exports the selected log; it does not clear it. Confirm that the file was created before proceeding. Microsoft documents the export operation as epl. [2]

Do not publish the exported file in a forum. Share the smallest necessary event details with trusted support, with private identifiers removed.

4. Repair the producer, then repeat the same test

Use the event details to choose one action:

• One ordinary app starts the repetition: close it normally and compare the next interval. If the activity settles, update or repair that app from its official source, then repeat the action that triggered the problem.
• A driver or device is named repeatedly: record the exact device and error. Check for a supported driver from the PC or device manufacturer. A recently changed optional peripheral can be a useful controlled test; do not remove storage or essential devices at random.
• A service repeatedly fails or retries: investigate that service’s specific failure message. Deleting the event does not repair a missing dependency, broken app installation or failed connection.
• Security software is involved: use its supported update or repair path, or contact its support team. Do not leave protection disabled to make the CPU graph quieter.

Example: opening one app coincides with repeated entries from the same provider. Closing that app stops new copies and the busy host settles. That supports investigating the app or the work it requests. If the entries stop but CPU stays high, the event stream was not the whole explanation. Keep looking instead of declaring the problem fixed.

After repair and any required restart, reproduce the same workload. Match the current PID again, compare CPU or disk activity, and check whether the same events resume. Improvement should persist with EventLog running.

If there is no obvious flood of new events

Reading logs can also create work. Microsoft’s WMI troubleshooting example traces queries involving the MS_NT_EVENTLOG_PROVIDER provider and Win32_NTLogEvent back toward a client process. That is why a monitoring or inventory tool deserves attention when the load follows its polling schedule. It does not mean every EventLog spike is a WMI fault. [3]

On a managed PC or server, give the administrator the process/PID, timestamps, recent monitoring changes and exported evidence. Ask them to examine query frequency, selected logs and forwarding subscriptions. Do not apply a home-PC “disable services” recipe to a domain controller or reduce security auditing without an approved plan.

If a log will not open or export, record the exact error. That is a reason for scoped log or Windows repair, not proof that all .evtx files should be deleted. If the load remains unexplained, support may need a performance trace captured while it happens.

When a malware check belongs in this diagnosis

High CPU alone does not establish infection. A check becomes useful if the problem follows an unknown installer or fake update, accompanies recurring security warnings, or arrives with unwanted browser or startup changes. A remaining task, service or bundled component may keep restarting unwanted activity.

In that situation, install Gridinsoft Anti-Malware, update its database, run a Full Scan, review the detections, remove detected threats and restart. Then repeat the original EventLog test. The scan checks for unwanted software; it does not promise to fix every logging fault or prove that no compromise occurred.

If the executable itself looks suspicious, follow the svchost.exe safety checks. Do not delete C:\Windows\System32\svchost.exe as a performance fix.

FAQ

References

1. Microsoft. “tasklist.” Microsoft Learn, updated February 3, 2023; accessed October 5, 2026. Process and service filters.
2. Microsoft. “wevtutil.” Microsoft Learn, accessed October 5, 2026. Event-log export commands.
3. Microsoft. “Troubleshoot WMI high CPU usage issues.” Microsoft Learn, accessed October 5, 2026. Identify WMI providers and querying clients.