Azure-managed Hotpatch deployments fail for KB5122882 and KB5126655 with error 0x800F0982 (PSFX_E_MATCHING_COMPONENT_NOT_FOUND)

gieenrile 0 Reputation points
2026-10-27T16:17:24.86+00:00

CBS references Microsoft-Windows-msmq-powershell-Opt-WOW64-Package version 10.0.20348.4294. DISM ScanHealth and SFC VerifyOnly both pass. A comparable Azure VM, Server1, with the same patch orchestration settings has successfully reached build 20348.5761. Request investigation of the servicing baseline and a supported remediation procedure.

Azure Update Manager
Azure Update Manager

An Azure service to centrally manages updates and compliance at scale.

0 comments No comments

2 answers

Sort by: Most helpful
  1. Jose Benjamin Solis Nolasco 13,021 Reputation points Volunteer Moderator
    2026-10-27T21:52:12.77+00:00

    Welcome to Microsoft Q&A

    Hello @gieenrile I hope you are doing well,

    The error:

    0x800F0982 (PSFX_E_MATCHING_COMPONENT_NOT_FOUND)

    typically indicates that the servicing stack cannot find a component version expected by the update package. Given that:

    • Both DISM /ScanHealth and SFC /VerifyOnly complete successfully.
    • Another VM (Server1) with similar patch orchestration settings has successfully advanced to build 20348.5761.
    • CBS logging consistently references:

    Microsoft-Windows-msmq-powershell-Opt-WOW64-Package

    Version 10.0.20348.4294

    the issue appears more consistent with a servicing baseline/component store mismatch than with general OS corruption.

    I would recommend reviewing:

    1. CBS.log and DISM.log around the KB5122882 and KB5126655 installation attempts to identify the exact package chain that fails.
    2. The installed package inventory on the affected VM versus the working VM (Server1) to determine whether the referenced MSMQ PowerShell optional component is at a different revision level.
    3. Whether any Features on Demand, optional components, language packs, or package removals were performed on the affected VM after deployment.
    4. The Azure Update Manager update history to identify the first update that failed and establish whether the issue started after a specific servicing baseline.

    Could you share:

    • The exact Windows Server edition (for example, Windows Server 2022 Datacenter: Azure Edition).
    • Whether Hotpatch is currently enabled.
    • The relevant CBS.log entries immediately preceding the 0x800F0982 failure.

    That information may help identify the specific package dependency that is missing.

    References

    If my answer helped you resolve your issue, please consider marking it as the correct answer. This helps others in the community find similar solutions.

    Was this answer helpful?

    0 comments No comments

  2. AI answer

    2026-10-27T16:17:53.6+00:00

    0x800F0982 during Azure-managed hotpatch deployment indicates the VM is likely not on a valid servicing baseline for the hotpatch being applied, or the servicing stack has underlying component-store issues that are blocking delta patch applicability.

    A supported investigation and remediation path is:

    1. Verify hotpatch eligibility and orchestration mode Confirm the VM is still running Windows Server 2022 Datacenter: Azure Edition or later, uses a supported Azure Marketplace image lineage, and has patch orchestration set to AutomaticByPlatform. Check on the VM:
         (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").ProductName
         (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").DisplayVersion
      
      Check orchestration mode in Azure:
         az vm show --resource-group <resource-group> --name <vm-name> --query "osProfile.windowsConfiguration.patchSettings"
      
      In the portal, verify Virtual machines > VM > Updates > Update settings shows Azure-orchestrated.
    2. Check whether the baseline cumulative update is stale Hotpatches are delta patches layered on the latest cumulative baseline. If the baseline was missed, later hotpatches can fail until the latest cumulative update is installed, and that install requires a reboot. Check recent cumulative update history:
         $session = New-Object -ComObject Microsoft.Update.Session
         $searcher = $session.CreateUpdateSearcher()
         $history = $searcher.QueryHistory(0, 20)
         $history | Where-Object { $_.Title -match "Cumulative" } |
             Select-Object Date, Title, ResultCode -First 5
      
      If the last cumulative update is older than 3 months, install the latest cumulative update from Azure Update Manager:
      • Go to the VM > Updates > One-time update
      • Select Include all update classifications
      • Deploy the update
      • Allow the reboot
      This is the supported way to re-establish the baseline. After the baseline is current, subsequent hotpatches should install without reboot.
    3. Check the hotpatch extension health In the portal, go to Virtual machines > VM > Extensions + applications and verify Microsoft.CPlat.Core.WindowsHotpatch is healthy. If it is failed:
      • Select the extension
      • Uninstall it
      • Wait for uninstall to complete
      • Trigger a new update assessment from Updates so the extension is reinstalled automatically
    4. Check for Windows Update policy conflicts WSUS or other Windows Update Group Policy settings can interfere with Azure Update Manager hotpatch delivery. Run:
         gpresult /h C:\Temp\gpresult.html
      
      Review:
      • Computer Configuration > Administrative Templates > Windows Components > Windows Update
      • Configure Automatic Updates
      • Specify intranet Microsoft update service location
      • Do not connect to any Windows Update Internet locations
      For Azure Edition VMs using hotpatching, the recommended configuration is Azure Update Manager without WSUS.
    5. Investigate component-store evidence even if ScanHealth and SFC pass A passing DISM /ScanHealth and SFC /VerifyOnly does not rule out servicing issues affecting a specific hotpatch delta. Review CBS.log for patterns that indicate whether repair is possible or whether the image is in a more severe state. Relevant log patterns include:
      • STATUS_SXS_COMPONENT_STORE_CORRUPT
      • HRESULT_FROM_WIN32(14098)
      • CBS_E_SOURCE_MISSING (0x800F081F)
      • Attempting to mark store corrupt
      • CBS_E_IMAGE_UNSERVICEABLE (0x800F0830)
      • PSFX_E_MATCHING_BINARY_MISSING
      Log locations:
      • C:\Windows\Logs\CBS\CBS.log
      • C:\Windows\Logs\CBS\CbsPersist_*.log
      • C:\Windows\Logs\DISM\dism.log
    6. Collect logs before escalation if the VM still fails while a comparable VM succeeds Since Server1 has reached a later build with the same orchestration settings, the failing VM likely has a VM-specific servicing or baseline problem rather than a general Azure Update Manager configuration issue. Collect before contacting Azure support:
      • WindowsUpdate.log generated by Get-WindowsUpdateLog
      • C:\Windows\Logs\CBS\CBS.log
      • C:\Packages\Plugins\Microsoft.CPlat.Core.WindowsHotpatch\<version>\
      • C:\Windows\Logs\DISM\dism.log
    7. Expected supported remediation The supported remediation is to bring the VM onto the latest cumulative baseline through Azure Update Manager, allow the required reboot, confirm the hotpatch extension is healthy, and remove any WSUS-conflicting policy. If hotpatch still fails after that, use the collected logs for Azure support investigation.

    If CBS.log shows severe servicing patterns such as CBS_E_IMAGE_UNSERVICEABLE or repeated delta-matching failures, the issue is no longer a normal hotpatch eligibility problem and requires deeper servicing investigation using the collected logs.


    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.