Update scan reports not installed when scanned via COM api despite update is installed `Update for Windows Security platform - KB5007651 (Version 10.0.29628.1000) `

Question

Update scan reports not installed when scanned via COM api despite update is installed `Update for Windows Security platform - KB5007651 (Version 10.0.29628.1000) `

Yuvraj Garhwal 0

On device update with title Update for Windows Security platform - KB5007651 (Version 10.0.29628.1000) is installed but when scanned for updates using script below same update appears again with same update id, revision and kb id. Update is not visible in Windows Update UI and update history also shows update as installed but COM Api returns same updates when queried for not installed updates.

Can someone help to understand why is there such discrepancy ? is this expected ?

Device is using Windows 11 Pro, version: 10.0.26200

$session  = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$result   = $searcher.Search("IsInstalled=0")

$result.Updates | ForEach-Object {
    [PSCustomObject]@{
        Title          = $_.Title
        KB             = ($_.KBArticleIDs -join ",")
        UpdateID       = $_.Identity.UpdateID
        RevisionNumber = $_.Identity.RevisionNumber
        IsDownloaded   = $_.IsDownloaded
        IsHidden       = $_.IsHidden
        MsrcSeverity   = $_.MsrcSeverity
    }
} | Format-Table -AutoSize

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

1 answer

Your answer

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Answer 1

Daphne Huynh (WICLOUD CORPORATION) 1,570 Microsoft External Staff Moderator

Welcome to Microsoft Q&A!

Thank you for providing the detailed information, including the operating system version, the scan results, and the PowerShell code used to reproduce the behavior.

Based on what you've described, the behavior you're seeing with KB5007651 (Windows Security platform update) can occur and does not necessarily indicate that the update is missing from the device.

Unlike a traditional cumulative Windows update, KB5007651 is a Windows Security / Microsoft Defender platform update. These updates use their own applicability and detection logic, which can occasionally result in differences between the installation status reported by Windows Update History and the status returned by the Windows Update Agent (WUA) COM API.

When you run: $searcher.Search("IsInstalled=0")

The query returns updates that the Windows Update Agent currently considers applicable. For Defender platform updates, the detection state maintained by WUA does not always align perfectly with:

Windows Update History
Windows Security UI
Defender platform version reporting

As a result, it is possible for the same UpdateID, RevisionNumber, and KB article to continue appearing in COM API scan results even after the update has been successfully installed. In such cases, the behavior is generally considered a detection-state or metadata evaluation discrepancy rather than evidence that the update is missing.

To verify the true installation state, I would recommend checking the currently installed Defender platform version:

Get-MpComputerStatus |

Select-Object AMProductVersion, AMServiceVersion

If AMProductVersion reports 10.0.29628.1000 (or a newer version), that would indicate the Windows Security platform update has already been applied successfully, even if KB5007651 continues to appear in the results of Search("IsInstalled=0").

If you'd like to investigate further, reviewing the following logs may provide additional insight into why the update is being reoffered:

Microsoft-Windows-WindowsUpdateClient logs
WindowsUpdate.log
Microsoft-Windows-Windows Defender/Operational log

These logs can help determine whether the behavior is related to applicability evaluation, cached detection metadata, or another update detection condition.

In summary, if the Defender platform version is already 10.0.29628.1000 and Update History shows KB5007651 as successfully installed, then seeing the same update returned by the COM API query can be an expected reporting anomaly and does not, by itself, indicate an installation failure.

I hope this helps clarify the behavior.

Reference: Microsoft Update Catalog

If you find this information helpful, please click Accept Answer.

Thank you for using Microsoft Q&A.

Yuvraj Garhwal 0 Reputation points

2026-09-11T10:06:15.61+00:00
Some follow up questions on response.

Above response seem to classify the update mentioned as defender update but it is categorised as definition update here . This might be a noob question but can we classify all definition updates as defender updates ? are these two categories of update related in any way ?

As per above message it seems like we can't treat COM API with IsInstalled=0 to fetch updates which are not installed on device, is there some reliable and robust way to scan and fetch not installed updates using CLI (powershell) which i am able to see in windows UI (i.e visible in Settings -> Windows Updates).

I strongly believe that there is some issue with this specific update. I have multiple devices and only this specific update reappears right after installation and same behavior across multiple devices. Attaching link of recording of a device which is facing the issue. Can you treat this as update specific issue and investigate https://drive.google.com/file/d/1dYwDKFOLX37Ng5ffRWXYtm6EGnhIW6xR/view?usp=drivesdk

For a specific update (not necessarily this one) if the update is installed successfully can same update appear again in future on device for installation. (When i say same update i don't mean just title, it means with same update id, revision and kb id too).

The above response contain details fetch AMProductVersion and compare that against update version to determine if update is installed but that only applies to defender updates as mentioned. How can i classify updates which are not installed vs installed on device precisely and reliably for any kind of updates ? How accurate is it to classify update installed using install history and rest of updates which are not installed and offered via COM API as not installed.
Daphne Huynh (WICLOUD CORPORATION) 1,570 Reputation points Microsoft External Staff Moderator

2026-09-14T07:20:44.73+00:00
Thank you for the follow-up questions. You raised several valid points, and I would like to clarify the earlier response.

1. Are all Definition Updates Microsoft Defender updates?

No. Definition Updates is a Windows Update classification, not another name for Microsoft Defender updates.

Microsoft defines a Definition Update as a frequently released update containing additions to a product’s definition database. These databases can be used to detect malware, phishing websites, junk mail, or other items with specific attributes. Therefore, not every update classified as a Definition Update is necessarily a Microsoft Defender security-intelligence update.

For KB5007651 specifically, it was described as a Windows Security app update. It updates the Windows Security application and its underlying service. In the Microsoft Update Catalog, it is published with the Definition Updates classification and the Microsoft Security platform category.

Therefore, a more accurate description is: KB5007651 is a Windows Security platform update distributed under the Definition Updates classification.

It should not be described as a Microsoft Defender signature or security-intelligence update solely because of that classification.

2. Is Search("IsInstalled=0") a reliable way to find missing updates?

The query is valid. However, its results should be understood as updates that the selected Windows Update service currently considers applicable and not installed. You can make the query more specific by excluding hidden updates and drivers:

$session = New-Object -ComObject Microsoft.Update.Session

$session.ClientApplicationID = "UpdateInventory"

$searcher = $session.CreateUpdateSearcher()

$result = $searcher.Search(

    "IsInstalled=0 and Type='Software' and IsHidden=0"

)

$result.Updates | ForEach-Object {

    [PSCustomObject]@{

        Title          = $_.Title

        KB             = $_.KBArticleIDs -join ","

        UpdateID       = $_.Identity.UpdateID

        RevisionNumber = $_.Identity.RevisionNumber

        IsDownloaded   = $_.IsDownloaded

        RebootRequired = $_.RebootRequired

    }

}

Nevertheless, the COM API result is not guaranteed to match the list displayed under Settings > Windows Update exactly.

The Settings experience may use additional logic related to policy, update source, update category, staged rollout, safeguard holds, supersedence, optional-update handling, and other user-experience filters. The COM API returns the Windows Update Agent scan result rather than a direct representation of the Settings page.

I am not aware of a supported PowerShell command that guarantees a one-to-one reproduction of every update displayed in the Windows 11 Settings interface.

It is also important to confirm the scan source. Depending on device configuration, the scan may use Windows Update, Microsoft Update, WSUS, or a source selected through policy. Scans using different sources or policy contexts can return different results.

3. Can this be treated as a KB5007651-specific issue?

The fact that the problem occurs consistently across several devices is meaningful and justifies further investigation. However, this alone is not enough to classify it as a confirmed Microsoft known issue.

The public documentation for KB5007651 describes the update, its classification, its category, and how to verify the installed Windows Security version. However, I could not find an official known-issue statement confirming that version 10.0.29628.1000 is incorrectly returned by the WUA COM API after installation.

Therefore, the most accurate conclusion is: This appears to be a reproducible update-specific detection or applicability issue, but it should remain classified as a suspected issue until Microsoft documents it or Microsoft Support confirms it through diagnostic analysis.

The recording is helpful for demonstrating the behavior, but Windows Update logs are required to determine why the update remains applicable.

On an affected device, collect the following immediately after installation and again after the update reappears:

Get-AppPackage Microsoft.SecHealthUI |

    Select-Object Name, Version, PackageFullName

Get-MpComputerStatus |

    Select-Object AMProductVersion, AMServiceVersion

Get-WindowsUpdateLog -LogPath "$env:TEMP\WindowsUpdate.log"

You should also capture the complete COM scan output, UpdateID, revision number, Windows edition and build, update source, applicable Windows Update policies, installation result code, restart status, and relevant Windows Update Client events.

Avoid resetting Windows Update components or deleting the SoftwareDistribution folder before collecting the logs, because doing so may remove information needed for investigation.

4. Can the same UpdateID and revision be offered again?

Yes. The same UpdateID, revision number, and KB can technically be offered again if a later applicability scan still determines that the update is required.

The UpdateID and revision number identify the published update metadata. They do not guarantee that the device will permanently satisfy the update’s installed-state detection rules.

The update may be offered again if the installation was recorded but its detection rule is no longer satisfied. It may also happen if the update contains multiple components and one component is missing, a repair or rollback changed the installed state, a restart is still required, the scan source changed, or the update contains a detection issue.

Microsoft has documented reoffering behavior for other Windows updates. Therefore, reoffering is technically possible, but that does not confirm that the same cause applies to KB5007651. If the identical update revision reappears immediately after a successful installation and required restart, particularly across multiple devices, the behavior should be investigated rather than automatically treated as normal.

5. How can installed and missing updates be determined accurately?

There is no single command that can precisely verify the installation state of every type of Windows update. Different update technologies use different installation and detection mechanisms.

For Windows cumulative or quality updates, verify the current OS build, servicing package state, restart status, and applicable Windows Update scan results.

For Component-Based Servicing packages and servicing stack updates, use DISM /Online /Get-Packages or Get-WindowsPackage -Online.

For a Windows Security platform update such as KB5007651, use the version-verification method documented in the KB5007651 support article.

For Microsoft Defender security-intelligence updates, verify the installed signature version and signature timestamp.

For driver updates, verify the installed driver version through the Plug and Play driver inventory or Device Manager.

For feature updates, verify the Windows version, edition, and OS build.

For Microsoft Store applications, verify the installed AppX or MSIX package version.

For firmware updates, verify the firmware version reported by the device or the hardware manufacturer’s management tools.

Within the Windows Update Agent:

IsInstalled=0 means the current scan considers the update applicable and not installed.

IsInstalled=1 means WUA currently considers the update installed.

Update History records previous installation attempts and their results.

Update History should not be treated as a complete representation of the device’s current state. An update can appear as successfully installed in history and later be removed, rolled back, replaced, repaired, or fail its applicability detection rule.

For reporting purposes, I recommend separating updates into the following states:

Applicable now: Returned by the current WUA scan.

Historically installed: Recorded as successful in Update History.

Currently verified: Confirmed through the appropriate package, build, driver, application, or product-specific version check.

Pending completion: Installed but awaiting a restart or another finalization condition.

Needs investigation: Recorded as successfully installed but returned again with the same identity after a new scan and required restart.