Fix ERROR_AUDITING_DISABLED (0XC0090001) on Windows

You're running some script or trying to pull event logs and boom—ERROR_AUDITING_DISABLED (0XC0090001). This is Windows saying, "I'm not watching that event, so I can't give you what you want." It's not a crash, it's a policy thing.

I've seen this mostly on Windows Server boxes where someone tightened security and killed auditing to "reduce log noise." Then the compliance team shows up and wants logs. Or you're a dev trying to use the Event Log API and the audit trail for a specific action is just off. The fix is usually straightforward, but you need to know which knob to turn.

Cause #1: Group Policy has auditing disabled for the target event

The most common trigger: your local or domain Group Policy has the specific audit policy set to No auditing for the category that covers your event (like Logon/Logoff or Object Access). When any application tries to query that audit trail, Windows throws 0XC0090001.

I had a client last month—they couldn't run their custom security tool that reads login events. The tool kept failing with this exact code. Turns out the GPO from the parent domain had "Audit Logon Events" turned off for all workstations. Took me five minutes to find.

The fix: enable the relevant audit policy

Open Local Security Policy or Group Policy Editor:

1. Press Win+R, type secpol.msc for local policy, or gpedit.msc for group policy (on Pro/Enterprise). On Server, use gpedit.msc.
2. Go to Security Settings → Local Policies → Audit Policy (or Advanced Audit Policy Configuration on newer systems).
3. Find the category that matches your event. For example, if it's a logon event, look for Audit Logon Events.
4. Set it to Success (or both Success and Failure if you need failures too).
5. Click OK and close.

Then force a refresh:

gpupdate /force

Or if you're on a domain, wait for the next policy refresh. But don't just sit around—gpupdate is instant.

If the policy is set by your domain, you can't change it locally—the local setting will be greyed out. You'll need to ask your admin to update the GPO. That's a politics problem, not a technical one.

Cause #2: Auditpol has the subcategory disabled

Sometimes the policy looks fine in the GUI, but the actual active setting is off. That's because Windows splits auditing into categories and subcategories. The GUI might show one thing while auditpol shows another.

I ran into this on a Windows 10 box where "Audit Object Access" was enabled in secpol, but the subcategory "File System" was disabled. The app was trying to audit file access and got 0XC0090001.

The fix: use auditpol to check and set subcategories

Open an elevated Command Prompt or PowerShell and run:

auditpol /get /subcategory:"*"

This dumps every subcategory and its setting. Look at the ones you need. For file access, look for "File System" or "File Share". For logons, look at "Logon" under Logon/Logoff.

If any are No Auditing, enable them like this:

auditpol /set /subcategory:"File System" /success:enable /failure:enable

Replace the subcategory name and the success/failure flags as needed.

Then test your application again. If that clears it, you're golden. If not, check if there's a conflicting policy—sometimes a GPO overrides auditpol settings, but in my experience auditpol usually wins per machine unless the GPO is set to enforce.

Cause #3: Application is trying to audit an event that's not allowed by the security descriptor

Less common, but I've seen it. Some applications—especially older ones or custom internal tools—try to set up an audit ACE on an object (like a file or registry key) but the security descriptor doesn't allow auditing. The system then returns 0XC0090001 because auditing isn't enabled for that object.

This one's trickier because it's not a global policy—it's per-object. It usually happens when someone removed the System account's right to generate audits, or the object's SACL (System Access Control List) is empty and the app expects to add to it.

The fix: check and repair the object's SACL

First, identify which object the app is trying to audit. The error message often includes the object path. If not, you can use Process Monitor to see what it's hitting.

Once you know the object, open its Properties → Security → Advanced → Auditing tab. If it's empty, add an entry for Everyone (or the relevant user) with the permissions you need (like Read or Write).

But honestly, if the app is trying to modify the SACL programmatically, you might need to run it as Administrator. Some apps just don't handle the permission errors gracefully and give you this cryptic code instead.

In that case, run the app as admin (right-click → Run as administrator) and see if it clears. If it does, you know it's a permissions issue, not audit policy.

Quick reference table

Most of the time, it's the first one. Start there. You'll save yourself the headache.