STATUS_ACCESS_AUDIT_BY_POLICY 0X40000032 Fix | Not a Real Error

This code means a process hit a Windows Audit policy rule. It's informational, not a crash. Triggered by Advanced Audit Policy or SACL entries on files.

What Triggers This Code?

You'll see STATUS_ACCESS_AUDIT_BY_POLICY (0X40000032) pop up in the Windows Security log as Event ID 4663, or sometimes as a debug output in a kernel dump. It's not a blue screen or an app crash. The trigger is simple: a process (like notepad.exe reading a .docx file) hits a file or folder that has a SACL (System Access Control List) entry tied to an Advanced Audit Policy setting. I've seen this most often on file servers running Windows Server 2016/2019 with folder redirection or home drives. A user opens a Word doc on the shared drive, and the security log lights up with 0X40000032.

Root Cause — It's Informational, Not an Error

People freak out when they see this code because it looks like a failure. It's not. The hex 0X40000032 is a success status in the NT status hierarchy (note the 0x4 prefix — that's the severity code for "informational"). The real cause is an audit policy rule that says: "If any process reads this file, log it." The message itself is just Windows saying "Yep, I saw that access, and I logged it per policy."

The culprit is almost always the Advanced Audit Policy subcategory Audit File System under Object Access, paired with a SACL on a folder. You set a SACL via the Security tab → Advanced → Auditing tab. Once that audit entry is there, every access matching the condition fires this event. No bug, no crash, just logging.

How to Stop It (or Tame It)

If the noise in your logs is driving you crazy, here's the fix. You've got two paths — disable the audit policy or remove the SACL. I recommend the second one unless you don't need auditing at all.

Check the SACL on the file/folder. Right-click the folder, go to Properties → Security → Advanced → Auditing tab. You'll see entries like "Everyone - Read - Success". That's your trigger.
Remove the SACL entry. Select the entry and click Remove. If you're not sure which one, remove all of them temporarily. Then replicate the access. If the events stop, you found it.
Adjust the Advanced Audit Policy. Open secpol.msc (Local Security Policy) → Advanced Audit Policy Configuration → Object Access → Audit File System. Set it to No Auditing or Failure only — success audits are what generate 0X40000032.
Or filter the event log. If you want to keep auditing but stop seeing this code, create a custom view in Event Viewer that excludes Event ID 4663. You'll still get the data in the background.
Run a test. Open a command prompt as admin and run gpupdate /force to push policy changes, then try the file access again. Check the Security log after 30 seconds.

Still Seeing It?

If the events persist, check for inherited SACLs. A parent folder might push down audit rules. Use icacls C:\path\to\folder /audit /t to list all SACLs recursively. Also check GPO: look under Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration. A domain GPO might enforce auditing on your server. Run rsop.msc to see which GPO is applying the policy. If it's from the domain, you'll need to talk to your AD admin — can't override that locally.

One last thing: some security software (like Carbon Black or SentinelOne) adds SACLs for file integrity monitoring. Check their console if you have any endpoint protection tools installed. Disable the file monitoring feature there, not the Windows audit, or you'll break the tool.