What does HRESULT 0x80045387 (FSRM_E_WMI_FAILURE) mean?

 
Previous Next
FSRM_E_PROPERTY_MUST_BE_GLOBAL FSRM_E_FILE_MANAGEMENT_JOB_RMS

FSRM_E_WMI_FAILURE

FSRM_E_WMI_FAILURE is the failure HRESULT 0x80045387 (signed decimal -2147200121, unsigned decimal 2147767175). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0x5387.

An unexpected WMI call failed inside the FSRM workflow

File Server Resource Manager reports this HRESULT when a Windows Management Instrumentation call fails unexpectedly. FSRM exposes WMI classes in Root\Microsoft\Windows\FSRM, and internal workflows can also query system management data. The symbolic code is an outer FSRM result; the actionable reason is usually the WMI namespace, class, method, and inner status.

AllStat records the official condition as: “Unexpected failure from a WMI call.” The wording should be interpreted at this FSRM stage, not as a generic file-system or COM failure.

Where the failure boundary lies

Do not assume that the complete WMI repository is corrupt. The failing operation may be limited to the FSRM provider, one class instance, remote connectivity, permissions, provider loading, or a dependent system class. The COM compatibility interfaces and WMI objects should also not be modified concurrently and then reused as though they share one live object state.

Likely causes to separate

  • The FSRM WMI provider is not registered, cannot load, or is unhealthy.
  • The caller lacks namespace or method permissions, especially during remote CIM operations.
  • A queried class or instance disappeared between enumeration and update.
  • RPC, DCOM, WinRM, firewall, or name-resolution problems interrupt a remote management call.
  • The WMI repository or a dependent provider returns a consistency or initialization failure.

Evidence worth preserving

  • Log the WMI namespace, class, object path, method, target server, authentication mode, and inner HRESULT or WBEM status.
  • Collect Microsoft-Windows-WMI-Activity and FSRM Application events using the same correlation time window.
  • Record whether the failure occurs through PowerShell/CIM, direct WMI, the FSRM MMC snap-in, or a compatibility COM interface.
  • Test a read-only query and the failing mutation separately to distinguish provider availability from operation-specific validation.

Diagnostic sequence

  • Verify that the File Server Resource Manager role and service are installed and running on the actual target computer.
  • Query the FSRM namespace locally before testing the remote transport and delegation path.
  • Check provider registration and repository consistency using supported WMI diagnostics; do not reset the repository as a first step.
  • If automation mixes WMI and COM access to the same job, reacquire the object after modification because Microsoft documents that the older interface can then fail unexpectedly.
  • Confirm that the inner error is not an ordinary FSRM validation code wrapped by the management layer.

Retry and recovery

Repair the identified provider, permission, transport, or repository condition and then reacquire the FSRM object before retrying. A remote retry is appropriate after connectivity is restored; a repeated local provider failure requires evidence collection and service or component repair. Repository salvage or rebuild is a high-impact action and should follow backup and Microsoft guidance.

What this HRESULT does not establish

This HRESULT does not identify the failed WMI class and does not prove that quotas, file screens, or job definitions are invalid. It also does not imply that every WMI namespace on the server is affected.

Difference from nearby FSRM results

FSRM_E_UNEXPECTED is a broader service failure with no WMI boundary. FSRM_E_WMI_FAILURE specifically records that the unexpected operation crossed a WMI call.

Practical scenario

A remote administration service updates an MSFT_FSRMFileManagementJob instance through CIM. The network session drops during the provider call and FSRM returns this HRESULT. Local enumeration succeeds, the remote transport log shows the interruption, and the client reacquires the instance before a bounded retry.

Guidance for software and telemetry

Telemetry must retain the inner WBEM status and object path. Returning only FSRM_E_WMI_FAILURE removes the distinction between access denied, unavailable provider, missing instance, and transport failure.

Official Microsoft references

Looking for a different code? Search another status or error code.