Fix STATUS_AUDITING_DISABLED (0xC0000356) in Windows

You tried to query or read an audit event that Windows isn't collecting. STATUS_AUDITING_DISABLED means the audit policy subcategory for that event is off, so no records exist to return.

You're poking around Event Viewer or running a script that reads the Security log, and instead of events you get a failure with STATUS_AUDITING_DISABLED (0xC0000356). The message is blunt: the specified event is currently not being audited. This usually shows up when an application calls AuditQuerySystemPolicy or tries to read a category that Windows has never been told to record. A common trigger: you enable Object Access in Local Security Policy, reboot, and still can't find file or registry audit entries in the log. Drop to a command prompt, run auditpol /get /category:*, and you'll see why.

What's actually happening here

Windows splits auditing into categories and subcategories. The top-level categories (Logon/Logoff, Object Access, Policy Change, etc.) are just containers. The real switches live one level down: File System, Registry, Handle Manipulation, Process Creation, and so on. If you enable a category but not its subcategories, or if the local policy gets overwritten by a domain GPO, the subcategory stays at No Auditing.

When any tool asks Windows for the current audit state of a subcategory that's set to No Auditing, the kernel returns STATUS_AUDITING_DISABLED. It's not a crash. It's not corruption. The API is honestly telling you there's nothing there because nobody turned the tap on.

The reason this trips people up: on Windows 7 and later, the old Audit: Force audit policy subcategory settings behavior changed. Category-level settings from the legacy UI can be silently ignored when subcategory policy is enforced by GPO. So the checkbox in Local Security Policy looks enabled, but auditpol reports No Auditing for the subcategory that actually matters.

Fix it

See what's actually enabled. Open an elevated Command Prompt and run:
```
auditpol /get /category:*
```
Scan for No Auditing on the subcategory you care about. If you're chasing file access, look under Object Access → File System. If you want logons, check Logon/Logoff → Logon.
Turn on the specific subcategory. Don't enable the whole category. Be precise:
```
auditpol /set /subcategory:"File System" /success:enable /failure:enable
```
For process tracking:
```
auditpol /set /subcategory:"Process Creation" /success:enable
```
Swap the subcategory name for whatever auditpol /list /subcategory:* shows on your build. Names differ slightly between Windows 10, Server 2016, and Server 2022.
If Group Policy is in play, fix it at the GPO level. Local changes get steamrolled at the next gpupdate. On a domain, edit the GPO that's linked to the OU containing the machine:
```
Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies
```
Enable the matching subcategory there. Then on the machine run gpupdate /force and re-check with auditpol /get /category:*.
Confirm the SACL is set on the object. Even with the subcategory enabled, file and registry auditing needs a system access control list entry on the target. Right-click the folder → Properties → Security → Advanced → Auditing → Add. Pick the principal (usually Everyone) and the access type (Read, Write, etc.). No SACL means no event, no matter what auditpol says.
Restart the audit service and reproduce.
```
net stop eventlog && net start eventlog
```
Then trigger the action you're trying to capture. Open a file you set a SACL on, or log off and back in for logon events. Check Event Viewer → Windows Logs → Security.

If it's still failing

Check which GPO won. Run gpresult /h gpreport.html and look for the audit settings. If two GPOs conflict, the one applied last wins. The report tells you exactly which one that was.
Watch for the legacy vs. advanced trap. If Audit: Force audit policy subcategory settings is disabled, legacy category settings can override your subcategory changes. Enable that policy (it's under Security Options) so subcategories take priority.
Security log might be full or wrapped. A 20 MB default log on a busy Server 2019 box wraps in minutes. Bump it: Event Viewer → Security → Properties → set max size to at least 1 GB, and choose Overwrite events as needed or archive on full.
Third-party agents can mask it. Some EDR products hook the audit APIs and return their own codes. Temporarily stop the agent and retest — if the error disappears, talk to the vendor.
Registry-level sanity check. Under HKLM\SYSTEM\CurrentControlSet\Control\Lsa, the AuditBaseObjects and AuditBaseDirectories values affect base-object auditing. Leave them alone unless you know why you're touching them — most people don't need to.

The short version: STATUS_AUDITING_DISABLED is Windows refusing to hand over data that was never collected. Enable the right subcategory, set the SACL, and verify with auditpol before you blame the API.