Anavem
EnglishFrancais
Anavem
Languagefr
CriticalCOM / DCOM

0x8000FFFF

E_UNEXPECTED

Unexpected COM failure — catastrophic error.

Hex code

0x8000FFFF

Decimal

-2147418113

Severity

Critical

Category

COM / DCOM

—

Description

E_UNEXPECTED (hex code 0x8000FFFF, decimal -2147418113) is a Windows critical-level error code in the COM & DCOM Errors 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.

Unexpected COM failure — catastrophic error.

This page documents what triggers 0x8000FFFF, 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 part of the COM / DCOM / OLE error space. It typically surfaces during COM activation (CoCreateInstance), DCOM hardening events (10016), or OLE-DB / RPC marshaling failures.

The code can be looked up programmatically in PowerShell with [ComponentModel.Win32Exception]::new(-2147418113).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

  • COM class not registered (regsvr32 missing or 32-bit / 64-bit mismatch).
  • DCOM Launch / Activation permissions stripped by Group Policy or hardening.
  • COM server crashed and is no longer responding to existing proxies.
  • Mismatched apartment threading model between caller and server.
  • Missing or corrupted dependency DLL referenced by the COM server.

Troubleshooting steps

  1. Identify the failing CLSID/AppID from the event log entry (Event 10016 in System log) or the calling application's trace.
  2. Open dcomcnfg, locate the AppID under Component Services > Computers > My Computer > DCOM Config, and verify Launch / Activation / Access permissions.
  3. Re-register the failing COM server: regsvr32 <server.dll> (use %WINDIR%\SysWOW64\regsvr32.exe for 32-bit on x64 Windows).
  4. Check dependencies with Dependency Walker or dumpbin /dependents — a missing DLL is a common root cause.
  5. Validate that the calling process matches the threading model expected by the COM server (STA vs MTA).

Decode in PowerShell

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

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

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

Frequently asked questions

What does the Windows error code 0x8000FFFF mean?
It is the Win32 / NTSTATUS code E_UNEXPECTED (decimal -2147418113). Unexpected COM failure — catastrophic error.
How do I decode 0x8000FFFF in PowerShell?
Run [ComponentModel.Win32Exception]::new(-2147418113).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.