0xC0000185 STATUS_IO_DEVICE_ERROR — Windows Error Code

Q: What does the Windows error code 0xC0000185 mean?

It is the Win32 / NTSTATUS code STATUS_IO_DEVICE_ERROR (decimal -1073741435). The request could not be performed because of an I/O device error. Often a failing disk.

Q: How do I decode 0xC0000185 in PowerShell?

Run [ComponentModel.Win32Exception]::new(-1073741435).Message in any PowerShell session. For HRESULT-style codes, use err.exe from the Windows SDK or the WinDbg !error command.

Q: Where does Windows typically log this error?

It depends on the originating subsystem (Windows Update → %WinDir%\WindowsUpdate.log; AD/Kerberos → Security event log on the DC; BSOD → minidump under C:\Windows\Minidump; MSI → %TEMP%\msi*.log; WMI → Microsoft-Windows-WMI-Activity). Always cross-reference the timestamp and module name with the Application and System event logs.

Description

STATUS_IO_DEVICE_ERROR (hex code 0xC0000185, decimal -1073741435) is a Windows critical-level error code in the NT Status Codes family. Microsoft surfaces this code through the Win32 API, the Common Language Runtime, the kernel, the event log, PowerShell, command-line tools (sfc, dism, gpupdate, sc), and Windows-side applications such as Outlook, Teams, Office, and System Center.

The request could not be performed because of an I/O device error. Often a failing disk.

This page documents what triggers 0xC0000185, the most common scenarios where it appears, the likely root causes, and a step-by-step troubleshooting workflow you can run against affected endpoints. It is intended for system administrators, MSP technicians, helpdesk engineers, and anyone diagnosing Windows behavior in a managed environment.

In-depth explanation

This is a critical-severity Windows error. It typically indicates a kernel-mode failure, an unrecoverable security violation, hardware failure, or a fatal driver bug. Treat any occurrence as a P1 incident: isolate the host, capture a memory dump if available, and pull the latest minidump from C:\Windows\Minidump for analysis.

It is an NTSTATUS code (returned from kernel APIs). Win32 may translate it into a more familiar ERROR_* equivalent through RtlNtStatusToDosError.

The code can be looked up programmatically in PowerShell with [ComponentModel.Win32Exception]::new(-1073741435).Message (for Win32 / NTSTATUS codes that map cleanly), or with net helpmsg <decimal> for the legacy decimal range. For HRESULT-style codes, decode the facility and code with err.exe from the SDK or via the WinDbg !error command.

Common causes

Kernel-mode caller passed an invalid parameter or handle.
Driver bug in a third-party filter, antivirus, or backup agent.
Memory pressure — paged or non-paged pool exhausted.
Concurrent access conflict on a kernel object.
Volume / registry hive corruption preventing the operation.

Troubleshooting steps

Inspect the System event log around the failure for the matching NTSTATUS entry, including the originating process and module.
If a kernel-mode driver is implicated, capture a kernel dump and analyze with WinDbg (!analyze -v).
Run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth to rule out OS-level corruption.
Check for matching Win32 errors via RtlNtStatusToDosError — most NT statuses have a more familiar ERROR_* sibling that is easier to triage.
Repro with Process Monitor (procmon) to capture the exact API call, parameters, and stack at the moment of failure.

Decode in PowerShell

# Decode 0xC0000185 (-1073741435) in PowerShell
[ComponentModel.Win32Exception]::new(-1073741435).Message

# Or via WinDbg / err.exe (Windows SDK)
# err 0xC0000185

# Or net helpmsg (legacy decimal range only)
# net helpmsg <decimal>

Frequently asked questions

What does the Windows error code 0xC0000185 mean?

It is the Win32 / NTSTATUS code STATUS_IO_DEVICE_ERROR (decimal -1073741435). The request could not be performed because of an I/O device error. Often a failing disk.

How do I decode 0xC0000185 in PowerShell?

Run [ComponentModel.Win32Exception]::new(-1073741435).Message in any PowerShell session. For HRESULT-style codes, use err.exe from the Windows SDK or the WinDbg !error command.

Where does Windows typically log this error?

It depends on the originating subsystem (Windows Update → %WinDir%\WindowsUpdate.log; AD/Kerberos → Security event log on the DC; BSOD → minidump under C:\Windows\Minidump; MSI → %TEMP%\msi*.log; WMI → Microsoft-Windows-WMI-Activity). Always cross-reference the timestamp and module name with the Application and System event logs.

Is this code recoverable?

Critical-severity codes usually require kernel-level investigation (driver, hardware, system file repair). Error and warning codes are typically recoverable through the troubleshooting workflow on this page — start with the elevated-shell + log review steps.

Should I open a Microsoft support case for this?

Open a case if the error reproduces after applying the troubleshooting steps, particularly if it blocks production workloads, occurs across multiple endpoints, or is associated with a security boundary (BitLocker recovery, Kerberos failure, DCOM hardening, SmartScreen / WDAC). Have a fresh CBS log, minidump, or Get-WinEvent export ready before opening the case.