Why Windows Stopped Logging Event ID 4688 (and the fix nobody mentions)

A few weeks ago I was debugging why a Windows box wasn't logging any process creation events. I'd followed the standard guide: enabled Audit Process Creation through gpedit, checked the box, done. Except nothing showed up in the Security log. Not one 4688 event.

I spent way too long on this before I found the actual cause, so I'm writing it down in case it saves someone else an afternoon.

The obvious checks (that didn't fix it)

First I ran through the usual suspects:

auditpol /get /subcategory:"Process Creation"

This showed the policy as enabled. Audit Process Creation was on. Command line auditing was on. Everything looked correctly configured. And still, nothing in the log.

I also checked for the known Windows 11 22H2 bug (KB5020044) where process creation auditing silently broke after an update. Worth ruling out, but that wasn't it either in my case.

The actual cause: legacy audit policy silently wins

Here's the part that isn't obvious from the Microsoft docs: Windows has two separate audit policy systems — the old category-level policy (the one under Local Security Policy → Audit Policy) and the newer Advanced Audit Policy Configuration (the one with granular subcategories like "Process Creation").

If a specific registry value isn't set, Windows lets the legacy policy silently override your advanced settings. So you can have "Process Creation: Success" enabled in Advanced Audit Policy, auditpol can even report it as enabled, and events still won't show up, because the legacy policy underneath is quietly winning.

The fix:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v SCENoApplyLegacyAuditPolicy /t REG_DWORD /d 1 /f
auditpol /set /subcategory:"Process Creation" /success:enable
gpupdate /force

A reboot made it take effect cleanly on my machine, though in theory gpupdate should be enough.

How to verify it's actually working

Don't just trust the policy state, check that events are actually landing:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 10 | Select-Object TimeCreated, Message

If this returns nothing after the fix above, also check:

• You're running Event Viewer / PowerShell elevated (as admin) — some setups quietly hide Security log entries otherwise
• You're not on an affected 22H2 build without KB5020044
• A GPO further up isn't re-disabling the subcategory on refresh

Why this matters beyond troubleshooting

Event ID 4688 is genuinely useful; it's the only built-in way to get a record of every process that started, including the full command line if you enable that too. The problem is it's a passive log; nothing watches it for you, nothing notifies you. You still have to go looking.

That's actually the exact itch that got me building SysPulse — it watches for new processes (plus USB devices, startup changes, and CPU/RAM thresholds) and pings a Telegram bot the moment something happens, so you're not stuck manually querying the Security log after the fact. I wrote up the full enable → verify → read workflow in more detail here: How to Detect New Processes on Windows.

Anyway — if you've hit this exact "policy says enabled but nothing logs" issue, check SCENoApplyLegacyAuditPolicy before anything else. It's an easy one to miss.