0XC00000FA

Fix STATUS_INVALID_PARAMETER_12 (0XC00000FA) in Windows Server

Server & Cloud Intermediate 👁 3 views 📅 Jun 5, 2026

This error means a service or API call got a bad 12th argument. Usually a corrupt driver, misconfigured service, or bad registry value.

Quick answer

Run sfc /scannow and dism /online /cleanup-image /restorehealth, then check the System event log for the exact service or driver triggering the error. Most common fix: reinstall or update that specific driver, or repair the service's registry parameters under HKLM\SYSTEM\CurrentControlSet\Services.

Why does this happen?

I know this error is infuriating – it usually pops up as a BSOD or a service crash with 0xC00000FA. I've seen it most often on Windows Server 2016 and 2019, but it can hit any NT-based system. The root cause: a kernel-mode function call received a parameter that's outright wrong – wrong type, null pointer, or out-of-range value – specifically for the twelfth argument. This isn't random. It's almost always a corrupt driver that's passing garbage, a misconfigured service that's feeding bad data to the kernel, or a registry key that's missing or malformed. The twelfth argument being the issue means the bug is deep in the call stack, often in a minifilter driver or a storage stack component.

I've debugged this on a client's file server running Windows Server 2012 R2 where a third-party backup driver was the culprit. Another time it was a corrupted registry entry for the LanmanServer service after a failed update.

Fix steps

  1. Identify the offending service or driver. Open Event Viewer (eventvwr.msc), expand Windows Logs > System. Filter by Source: Service Control Manager or BugCheck. Look for Event ID 20 or 1001 near the crash time. The details usually show the driver name, e.g., xxx.sys. Note it down.
  2. Run system file and image checks. Open an elevated Command Prompt (Run as Administrator) and type:
    sfc /scannow
    Wait for it to finish. Then run:
    dism /online /cleanup-image /restorehealth
    Restart. If the error persists, move on.
  3. Repair or reinstall the faulty driver. If you identified xxx.sys:
    • Check if it's a Windows driver – run driverquery /si to see its signed status.
    • If it's a third-party driver, download the latest version from the vendor's site and reinstall.
    • If it's a Microsoft driver (e.g., fltmgr.sys or rdbss.sys), run chkdsk /f on the system drive and then a repair install of Windows Server using the same ISO.
  4. Check the service's registry parameters. Go to HKLM\SYSTEM\CurrentControlSet\Services\[ServiceName]. Look for the Parameters key. If it's missing or has invalid data, export the key from a known-good server (same OS version) and import it. For example, for the LanmanServer service, ensure Parameters\IRPStackSize is a DWORD with value 15 (decimal).
  5. Disable the service temporarily. If you can't fix the driver, stop the service and set it to disabled via services.msc. Warning: this may break app functionality, so only do it for non-critical services (e.g., a backup agent).

Alternative fixes if the main one fails

  • Boot into Safe Mode – if the error disappears, it's a third-party driver. Use Autoruns (Sysinternals) to disable non-Microsoft drivers one by one.
  • Use Driver Verifier – risky but precise. Run verifier.exe and select "Create custom settings (for code developers)". Check "Force IRQL checking" and "Pool tracking". Select your suspect driver from the list. This will crash the system with a more detailed bugcheck if the driver is naughty.
  • Restore a previous system state – if you have a restore point from before the error started, roll back using rstrui.exe. Works surprisingly often after a bad Windows Update.

Prevention tip

Always test driver updates on a staging server first. I keep a VM snapshot of my production configuration – if a driver or service change breaks it, I roll back instantly. Also, enable Driver Verifier on your test environment periodically; it catches bad parameters before they hit production.

Was this solution helpful?