Event ID 4673 flood: why the Security log is full and the PC is slow

Event 4673 is Windows saying "A privileged service was called". A few a day are normal. Dozens per second, from chrome.exe, msedgewebview2.exe or Code.exe, make the Windows Event Log service eat whole processor cores – and the log falls minutes or hours behind.

1. How to recognise the flood

• Task Manager shows Service Host: Windows Event Log using 10 % or more of the processor, all the time.
• Event Viewer (eventvwr.msc) › Windows Logs › Security is full of 4673, Sensitive Privilege Use, keyword Audit Failure.
• Explorer, the Start menu or Event Viewer itself hang for seconds.
• The newest entry in the Security log is minutes old, although things happen all the time: the log is behind.

Count the entries of the last two minutes in PowerShell (as administrator):

$q = "*[System[(EventID=4673) and TimeCreated[timediff(@SystemTime) <= 120000]]]"
(Get-WinEvent -LogName Security -FilterXPath $q -ErrorAction SilentlyContinue).Count / 120

More than a few per second is a flood. To see which programs and which right:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4673} -MaxEvents 500 |
  Group-Object { Split-Path $_.Properties[8].Value -Leaf }, { $_.Properties[6].Value.Trim() } |
  Sort-Object Count -Descending | Select-Object Count, Name

2. Why Chrome, Edge WebView and VS Code cause it

Chromium-based programs regularly ask Windows how much memory their own processes use. For that query Windows checks the right SeProfileSingleProcessPrivilege. A normal user does not have it, so Windows refuses – and with privilege auditing on, it writes an Audit Failure 4673 for every refusal. The program simply carries on and asks again a moment later.

The programs are not dangerous, but they ask far more often than they need to. One open VS Code window with a few extensions, a browser and the Edge WebView behind Teams or Outlook can produce 50 to 100 entries per second – millions a day.

3. Why it slows the whole PC down

Every entry has to be written by the Windows Event Log service. At this rate it needs one or two whole processor cores, and when the processor is busy with other programs too, it falls behind. We have measured a Security log that was over an hour behind. Programs that read the log (Event Viewer, Explorer's file properties, security tools) then wait for it.

A log that is behind is also a security problem: everything that reads the Security log – failed logins (Event 4625), firewall blocks, port scans – sees it that much later.

4. Does Event 4673 have security value?

Some, but only in rare entries. It depends on which right was used and by which program:

Right in the event	What it can mean
SeLoadDriverPrivilege	A program loads a driver. Attackers do this to switch off antivirus software (“bring your own vulnerable driver”).
SeTcbPrivilege	A program acts as part of the operating system – unusual outside Windows itself.
SeDebugPrivilege	Access to other programs' memory, for example password theft from lsass.exe.
SeProfileSingleProcessPrivilege	Memory queries from browsers and editors. No security value.

The useful entries are a handful a day. In a flood they are buried under millions of failures. And the dangerous uses are mostly successes (the program really had the right) – which is why unticking only Failure keeps the valuable part.

5. Find the policy behind it

Run as administrator:

gpresult /h "%TEMP%\gp.html" && start "" "%TEMP%\gp.html"

In the report, under Computer Details › Settings › Policies › Windows Settings › Security Settings › Local Policies/Audit Policy, look for Audit privilege use and the Winning GPO. The effective setting on this computer (names are shown in the Windows language):

auditpol /get /subcategory:"{0CCE9228-69AE-11D9-BED3-505054503030}","{0CCE9229-69AE-11D9-BED3-505054503030}"

Watch out for the old category settings: unless the security option "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings" is enabled, Audit privilege use switches on all its subcategories, including the noisy ones.

6. The fix: untick Failure

1. On a domain controller open Group Policy Management (gpmc.msc) and edit the GPO you found. On a single PC: gpedit.msc.
2. Go to Computer Configuration › Policies › Windows Settings › Security Settings › Local Policies › Audit Policy.
3. Double-click Audit privilege use, keep Define these policy settings ticked, tick Success, untick Failure, OK.
4. On the affected computers: gpupdate /force.
5. Check: auditpol /get /category:"Privilege Use" (or the GUID command above) should now say Success only.

If your Security team does not use privilege auditing at all, Not Defined is also fine. Do not switch off logon auditing or Filtering Platform Connection / Packet Drop while you are there: failed-login and firewall monitoring need them.

7. After the fix: the log has to catch up

Do not be surprised if the processor stays busy for a while: the Event Log service first writes out the backlog from before the change. When the log was an hour behind, that can take another hour or more.

To skip the wait, end the service's process and start it again, as administrator. The entries still waiting are then lost – almost all of them the flood, but also the other Security entries of that time:

taskkill /F /FI "SERVICES eq EventLog"
sc start EventLog

If you do not run sc start, Windows restarts the service by itself after a minute. Services that depend on it (for example the Windows Event Collector) may need a start, too.

8. Let Coinetic watch the Event Log for you

Coinetic reads the Security log all the time for failed logins and firewall blocks, so it notices when the log cannot keep up:

• Measured, not guessed: entries per second over two minutes, which events and programs cause them, the share of Audit Failure, the Event Log service's processor use and how far the log is behind.
• The cause by name: the Group Policy and the exact setting behind the flood. For a domain policy Coinetic changes nothing – Copy text for your administrator gives your IT the exact request.
• No policy behind it? One click switches off only the noisy logging Coinetic does not need, back to the Windows default.
• A warning when it matters: when the log is more than ten minutes behind, Coinetic tells you once a day, because attacks are then seen late. Security › System self-test shows the details any time.
• Ask AI (Pro + AI): “Why is my PC slow?” – the AI analyst measures the log and explains it in plain words.

More guides: all Coinetic guides.

Frequently asked

Is Event 4673 from chrome.exe a sign of malware?

No. Audit Failure 4673 for SeProfileSingleProcessPrivilege from Chrome, Edge, Edge WebView or VS Code is normal Chromium behaviour. Look closer only at successes for rights such as SeLoadDriverPrivilege or SeDebugPrivilege from programs you do not know.

Can I switch off only the Chrome entries?

No. Windows can switch privilege auditing on or off only per category and per Success / Failure, not per program or per right. Unticking Failure is the closest you get.

Should I just make the Security log bigger?

It does not help: the problem is the Event Log service writing 50–100 entries per second, not the size of the file. A bigger log only keeps the noise longer.

Is it safe to end the Event Log service's process?

Windows starts it again (or sc start EventLog does at once), and nothing breaks. You lose the entries that were still waiting to be written, so do it only when you do not need those minutes of the Security log.

What about Event 4674 and 4703?

4674 (an operation on a privileged object) belongs to the same category and goes away with the same change. 4703 (a token right was adjusted) comes from Audit process tracking; at a few per second it is harmless.