Skip to main content

Endpoints Returning Partial Inspections Due to Missing or Corrupted WMI Provider (cimwin32)

Updated over 2 weeks ago

Issue Summary

Some Windows endpoints may begin returning partial Liongard inspections, fail to auto-update, or stop responding to remote commands from RMM tools. In almost all cases, this issue is triggered by a corruption or removal of the WMI cimwin32 provider, which is responsible for core system information on Windows.

When the cimwin32 provider is missing, unregistered, or damaged, Windows Management Instrumentation (WMI) can no longer respond to standard system queries—impacting Liongard and many other endpoint tools.

Symptoms

On the endpoint:

  • Liongard inspections return partial results (e.g., missing hardware, missing system info, or “software-only” output).

  • Liongard Agent fails to auto-update.

  • RMM platforms fail to:

    • Execute remote commands

    • Retrieve files

    • Query services or hardware info

  • Monitoring/AV/EDR tools intermittently fail with:

    • Invalid class

    • Not found

    • Empty WMI responses

In Liongard:

  • Windows Workstation or Server inspector results suddenly lose:

    • Hardware details

    • Operating system information

    • Logical disks

    • Services

    • Other core configuration data

Root Cause

The issue is caused by a missing or unregistered WMI provider:
​cimwin32.mof / cimwin32.mfl

This provider defines foundational WMI classes such as:

  • Win32_ComputerSystem

  • Win32_OperatingSystem

  • Win32_LogicalDisk

  • Win32_Service

  • …and dozens more.

When these classes are not registered, WMI cannot answer system queries, causing Liongard and many endpoint tools to return incomplete or failed results.

What Breaks and Why

Component Affected

Reason for Failure

Liongard Agent

Relies heavily on WMI to collect system, OS, hardware, and service data. Missing classes = partial inspections.

Liongard Auto-Update

Update logic uses WMI to validate system context and running services. Missing providers prevent update checks from succeeding.

RMM Remote Commands

Platforms like NinjaOne, CW Automate, and N-central rely on WMI for file ops, remote processes, and scripting. Missing providers cause failures.

Monitoring/AV/EDR Tools

Tools performing system checks via WMI receive Invalid class / empty responses when Win32_* classes are missing.

Why It Often Affects Multiple Machines

Common triggers include:

1. Windows Updates / Servicing Stack Repairs

Some updates may fail to re-register cimwin32.mof correctly, leaving the system without core WMI classes.

2. RMM “WMI Repair” Scripts

Scripts that delete the repository (e.g.,
​rd /s /q C:\Windows\System32\wbem\Repository)
but do not recompile the MOF files afterward.

3. Cloned/Imaged Systems

If the base image had a corrupted WMI repository, every clone inherits it.

4. Antivirus / Endpoint Security Tools

Occasionally quarantine or block:

  • cimwin32.dll

  • MOF/MFL files

  • Related WMI providers

Technical Explanation of the Fix

What mofcomp Does

mofcomp = Managed Object Format Compiler.

When you run:

mofcomp cimwin32.mof mofcomp cimwin32.mfl

You are:

  • Recompiling the cimwin32 provider definitions

  • Restoring the Win32_ class definitions* under root\cimv2

  • Re-registering the provider with WMI

  • Re-linking the compiled MOF to provider DLLs (e.g., cimwin32.dll)

Afterward, restarting the WMI service (winmgmt) reloads all repaired classes.

Why This Fix Works Without Rebuilding WMI

Rebuilding the entire repository is disruptive and can break:

  • Monitoring agents

  • Performance logs

  • Event subscriptions

  • RMM integrations

Recompiling the MOFs:

  • Targets only the missing classes

  • Requires no reboot

  • Is safe for production systems

  • Immediately restores WMI functionality

This is the correct fix when the repository is still “consistent.”

Resolution Steps

1. Recompile the missing WMI provider

Run the following PowerShell or CMD commands as Administrator:

$wbem = "$env:windir\System32\wbem" mofcomp "$wbem\cimwin32.mof" mofcomp "$wbem\cimwin32.mfl"

2. Restart the WMI service

Restart-Service winmgmt -Force

Verification Steps

Validate WMI health

Run:

wmic computersystem get Name

Or:

Get-CimInstance Win32_ComputerSystem | Select Name

A successful return (your machine name) confirms WMI is functioning correctly.

Validate Liongard functionality

After the next inspection cycle:

  • Hardware data returns

  • System information populates normally

  • Agent auto-update resumes

  • RMM remote actions succeed again

Summary for Support Teams

Trigger:

Missing or unregistered cimwin32 provider.

Impact:

  • Partial Liongard inspections

  • Agent auto-update failures

  • RMM command/file retrieval failures

  • AV/monitoring errors

Resolution:

Recompile the WMI provider:

$wbem = "$env:windir\System32\wbem" mofcomp "$wbem\cimwin32.mof" | Out-Null mofcomp "$wbem\cimwin32.mfl" | Out-Null Restart-Service winmgmt -Force

Next Steps (Optional):

Deploy the fix across multiple machines using:

  • RMM PowerShell scripts

  • Group Policy Startup Scripts

  • Liongard’s Windows Agent Remediation tooling (if applicable)

Did this answer your question?