DISM and reliability on WMI

Question

Normally when I run DISM, it takes maybe 5 minutes or so.

Since the last round of Windows updates, there has been a big change, and now DISM scans to around 60%, then comes to a crawl.

I let it run, and scan finally reaches 100% after more than 15 minutes extra time.

DISM sits on 100% for another 5-10 minutes before completing, with no problems reported.

When the slowdown starts, I check Task Manager, and notice WMI is hogging the system.

I exited WMI, went back to DISM, and it had stopped, with the message "Remote procedure call failed", so obviously the two programs are reliant upon each other.

Is this normal?

Did a repair install of Windows 11, but that made no difference.

Appreciate any suggestions, please.

Answer 1

Hello Kenneth Starick,

This is most likely normal, and your image is probably fine. DISM's /RestoreHealth seems to be doing a deeper check and pulling/validating from Windows Update, so it can crawl around the 60% mark and then sit at 100% for a while before it actually wraps up. It looks frozen, but it's usually still working.

The "Remote procedure call failed" probably wasn't a separate fault — it likely happened because you exited WMI. DISM leans on WMI and the RPC service to do its thing, so stopping it mid-run can kill the operation even when nothing's actually wrong. I'd just leave WMI alone while DISM runs and see if it behaves.

If you'd rather not guess whether it's stuck, open PowerShell as admin and run:

• Get-Content C:\Windows\Logs\CBS\CBS.log -tail 10 -wait

You should see new lines appear as it works, and it's genuinely done once you spot**"Ending TrustedInstaller finalization."** Given it does reach 100% with no problems reported, I'd lean towards this being a post-update quirk rather than corruption.

Answer 2

DISM relying on WMI and taking significantly longer after recent updates is expected behavior in some scenarios, especially when the Windows image or related repositories are large or when validation work increases.

Key points from the available guidance:

1. DISM is designed to perform extensive health checks
   • DISM /Online /Cleanup-Image /RestoreHealth performs a deep scan and repair of the component store and related system components.
   • It can legitimately take many minutes, especially when corruption checks or repairs are more complex, or when the repair source is Windows Update.
   • The documentation explicitly notes that these operations can take several minutes and that DISM is the recommended tool to repair Windows Update and image corruptions.
2. WMI activity and high CPU during validation are known behaviors
   • On earlier versions of Windows (Windows 7 / Windows Server 2008 R2), Microsoft documented that WMI repository validation can cause high CPU usage and long startup times when the WMI repository is large. This is due to full validation of the repository being time‑consuming.
   • Although that article targets older versions, it shows that heavy WMI validation and high CPU usage during system health checks are known and expected behaviors when the repository is large or complex.
3. DISM and WMI interaction
   • DISM is a servicing and management tool that interacts with system components and services, including WMI, to inventory and repair the Windows image.
   • Because of that, DISM operations can trigger WMI activity. Terminating WMI (or the hosting svchost/RPC infrastructure) while DISM is running can cause errors such as “Remote procedure call failed,” since DISM depends on those services.
   • Stopping WMI or related services during DISM is therefore not recommended; it can interrupt the operation and cause failures even if the image itself is healthy.
4. What is considered normal vs. problematic
   • Normal:
     • DISM taking significantly longer than before, especially after updates.
     • High CPU usage from WMI-related processes during DISM.
     • DISM reaching 100% and then remaining there for several minutes before reporting success.
   • Problematic:
     • DISM failing with errors when WMI/RPC services are left running and the system is otherwise idle.
     • Repeated failures even after following the standard repair sequence (DISM /RestoreHealth followed by sfc /scannow) and ensuring a stable repair source.
5. Recommended approach
   • Allow DISM to complete without terminating WMI or related services.
   • Use the standard repair sequence when needed:
     1. DISM.exe /Online /Cleanup-image /Restorehealth
     2. sfc /scannow
   • If DISM reports “The restore operation completed successfully” and sfc /scannow finds no integrity violations, the image is considered healthy even if the operation was slow.
   • If DISM commands fail, the guidance is to:
     • Ensure the correct, up-to-date DISM version is used.
     • Avoid mounting or working in protected folders.
     • Consider running from WinPE and temporarily disabling antivirus if DISM processes are being interrupted.

Given that DISM completes successfully and RPC failures only occur when WMI is manually terminated, the behavior described (longer run time, heavy WMI usage, and reliance on WMI/RPC) is consistent with normal, documented characteristics of DISM and WMI interaction rather than a sign of corruption.

---

References:

• Fix Windows Update corruptions and installation failures
• Repair a Windows Image
• High CPU usage or a lengthy startup process occurs during WMI repository verification when a large WMI repository exists in Windows 7 or in Windows Server 2008 R2
• Unexpectedly slow startup or logon process in Windows Server 2008 R2 or in Windows 7
• DISM Overview
• Modify a Windows image using DISM
• DISM Reference (Deployment Image Servicing and Management)