Windows 11 MDM: Win32AppInventory CSP Get returns 404 after KB5127648 (inventory cache "Schema mismatch")

Amin Khabbazi 0 Reputation points
2026-10-19T11:37:41.07+00:00

Question: Is the Win32AppInventory 404 after KB5127648 a known issue, and is rebuilding the inventory cache (below) the supported way to fix affected devices until an update fixes it?

Environment

  • Windows 11 Enterprise 25H2, build 26200.9711 (KB5127648), MDM-enrolled with a third-party OMA-DM server
  • Worked on 26200.9457, before the update

What happens Since KB5127648 the device answers this Get with 404 on every sync:

Get ./Vendor/MSFT/Win32AppInventory/Win32InstalledProgram?list=StructData

Other commands in the same session succeed, the programs are still installed, and WMI (Win32_InstalledWin32Program) still lists them. Nothing is logged in the DeviceManagement-Enterprise-Diagnostics-Provider Admin or Operational logs.

What I found An ETW trace (Microsoft-Windows-Application-Experience, verbose) during an MDM sync shows, right after the MDM client's license and allow checks for the node:

SqliteInvCache::CreateTable, 1966, Schema mismatch [0x80004005]
SqliteInvCache::Initialize, 838, CreateTable failed [0x80004005]
TelCacheProvider::Initialize, 638, SqliteInvCache::Initialize failed [0x80004005]

The cache is C:\Windows\AppCompat\Programs\InventoryApplication.db. On the affected device it stopped updating just before the update, and its table InventoryApplication_0 lacks a column the new aeinv.dll (10.0.26100.9711) creates: "SentDetailedInv" INTEGER.

What I tried As administrator, renamed the cache and ran an MDM sync:

Get-ChildItem C:\Windows\AppCompat\Programs -Force -Filter 'InventoryApplication.db*' |
    Rename-Item -NewName { $_.Name + '.old' }

Windows recreated it with the new column and the Get returned 200 with all programs again, and it stayed fixed on later syncs.

Steps to reproduce

  1. MDM-enroll a Windows 11 25H2 device with an OMA-DM server; the Get above returns 200 on 26200.9457.
  2. Install KB5127648 (26200.9711).
  3. Send the same Get: it returns 404.

Reported in Feedback Hub: https://aka.ms/AA13vnec Trace output, before/after table schema and check script: https://github.com/Dude-One/kb5127648-win32appinventory-404

Windows for business | Windows Client for IT Pros | Devices and deployment | Other
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-10-19T12:01:01.67+00:00

    The Win32AppInventory failure is not currently listed by Microsoft as a known KB5127648 issue, and renaming InventoryApplication.db* should be treated as an effective but undocumented workaround—not a Microsoft-supported repair procedure.

    Current status

    • KB5127648 is the October 13, 2026 update that installs OS build 26200.9711 on Windows 11 25H2. Its published known-issues section does not identify a Win32AppInventory 404, SQLite schema mismatch, or SentDetailedInv migration problem.^1^
    • The CSP documentation confirms that Get is supported for both ./Vendor/MSFT/Win32AppInventory and its Win32InstalledProgram node on Windows 11 Enterprise.^2^
    • Microsoft does not publish a procedure for deleting, renaming, or reconstructing C:\Windows\AppCompat\Programs\InventoryApplication.db. The documented “reset software inventory cache” procedure applies to Configuration Manager’s root\ccm\invagt inventory state, not the Windows Win32AppInventory CSP database, so it should not be substituted here.^3^

    Therefore, the available public information does not support calling this an officially acknowledged regression or the cache rename an officially supported interim fix.

    Assessment of the observed workaround

    Your before/after evidence establishes a narrow and reproducible correlation:

    1. The failure begins after moving from build 26200.9457 to 26200.9711.
    2. ETW records cache initialization failing with Schema mismatch.
    3. The existing table lacks the column expected by the updated component.
    4. Renaming the database causes Windows to create a compatible schema.
    5. The same CSP request then returns 200 and remains functional.

    That is strong diagnostic evidence for escalation, but it does not establish Microsoft supportability. Because the database is an internal Windows artifact and no public contract documents its schema or reconstruction, avoid deploying the workaround broadly unless Microsoft Support approves it.

    For devices that must be restored before an update is available, use the workaround only as a controlled mitigation:

    • Pilot it on representative devices first.
    • Preserve the renamed files rather than deleting them.
    • Record the OS build, aeinv.dll version, database timestamps, schema, ETW trace, and MDM response before and after.
    • Confirm that the replacement database is populated and the CSP returns 200.
    • Do not modify the SQLite schema directly.
    • Stop deployment if Windows does not recreate the database or if other inventory functions regress.

    Renaming files under C:\Windows changes undocumented operating-system state; retain a rollback copy and use it only under your organization’s change-control process.

    Open a Microsoft support case and include:

    • The exact build transition and reproduction sequence.
    • The failing SyncML request and complete 404 response.
    • Application-Experience ETW events showing SqliteInvCache::CreateTable and Schema mismatch.
    • PRAGMA table_info(InventoryApplication_0) output before and after reconstruction.
    • File versions and hashes for aeinv.dll.
    • The preserved pre-update and affected database files, if Support requests them.
    • Evidence that other commands in the same OMA-DM session succeed.
    • The Feedback Hub report and your minimal reproduction package.

    Ask Microsoft to confirm three points explicitly:

    1. Whether this is a schema-migration defect in build 26200.9711.
    2. Whether renaming InventoryApplication.db and its companion files is approved as an interim mitigation.
    3. Which servicing update or Known Issue Rollback addresses it.

    Continue testing newer cumulative or out-of-band updates on a pilot ring. Microsoft’s update-history guidance recommends installing the latest update because later cumulative updates include earlier fixes, but no currently supplied release note identifies a Win32AppInventory correction.^4^

    References

    1. October 13, 2026—KB5127648 (OS Builds 26300.9711, 26200.9711 and 26100.9711) | Microsoft Support
    2. Win32AppInventory CSP
    3. How to Reset the Software Inventory Cache
    4. Windows 11, version 25H2 update history | Microsoft Support
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

    1 person found this answer helpful.
  2. Chance Maurice Niyonzima 825 Reputation points Independent Advisor
    2026-10-20T08:33:50.69+00:00

    Hello Amin,

    Thank you for posting your question on the Microsoft Windows Forum!

    I appreciate the detailed investigation and for sharing both the ETW findings and the reproduction steps. Based on the evidence you've collected, you've already isolated the issue much further than most inventory-related cases.

    Is this a known KB5127648 issue?

    At the time of writing, I reviewed the published known issues for October 13, 2026—KB5127648 (OS Builds 26300.9711, 26200.9711 and 26100.9711) and do not see any documented issue related to:

    • Win32AppInventory CSP
    • Win32InstalledProgram
    • InventoryApplication.db
    • SQLite schema migrations
    • 404 responses from the Win32AppInventory node
    • Missing SentDetailedInv columns

    Therefore, based on currently published Microsoft information, this is not an officially acknowledged known issue and there is no documented Known Issue Rollback (KIR) or servicing fix associated with this behavior. [support.mi...rosoft.com]

    What the evidence suggests

    Your findings establish a very strong and reproducible correlation:

    1. The issue appears after upgrading from:
    26200.9457

    to:

    26200.9711 (KB5127648)
    1. ETW traces show:
    SqliteInvCache::CreateTable
Schema mismatch

    during cache initialization.

    1. The existing inventory database schema does not contain the:
    SentDetailedInv

    column expected by the updated component.

    1. Renaming:
    C:\Windows\AppCompat\Programs\InventoryApplication.db*

    causes Windows to recreate the database with the updated schema.

    1. After rebuild, the same CSP request returns:
    200 OK

    and continues to function correctly.

    Based on that evidence, the most reasonable working theory is a schema migration failure involving the local Win32 application inventory cache, rather than an MDM communication issue, enrollment problem, or CSP implementation error.

    Is rebuilding the inventory database a supported fix?

    This is where I would be cautious.

    Your testing clearly demonstrates that rebuilding the cache is an effective workaround.

    However, I could not find Microsoft documentation that identifies:

    C:\Windows\AppCompat\Programs\InventoryApplication.db

    as a supported administrator-managed cache or recommends deleting, renaming, or reconstructing it as an official repair procedure.

    Similarly, Microsoft's documented procedure for resetting the software inventory cache applies to Configuration Manager inventory state and not to the Windows Win32AppInventory CSP. Therefore, that documentation should not be treated as approval to reset this database. [support.mi...rosoft.com]

    In other words:

    Effective workaround

    Not currently documented as a Microsoft-supported remediation

    Recommended approach

    For environments affected today, I would treat the rename/rebuild process as a controlled mitigation, not a general repair recommendation.

    If you use the workaround:

    • Preserve the original database files instead of deleting them.
    • Validate that Windows recreates the database successfully.
    • Confirm the CSP returns 200 after regeneration.
    • Avoid modifying the SQLite schema directly.
    • Test on a pilot group before broader deployment.

    Since this database is an internal Windows component and its schema is not publicly documented, I would avoid making assumptions about long-term supportability without Microsoft guidance.

    Recommended escalation

    I believe you've collected enough evidence to justify a Microsoft support escalation.

    Include:

    • The build transition (26200.9457 → 26200.9711)
    • The failing SyncML request and 404 response
    • ETW traces showing:
      • SqliteInvCache::CreateTable
        • Schema mismatch
        • Database schema comparison before and after recreation
        • File version information for aeinv.dll
        • The Feedback Hub submission
        • Your minimal reproduction package

    My Assessment

    Based on the evidence presented, I would currently characterize this as a strongly supported regression hypothesis with a validated workaround, but not yet a Microsoft-documented known issue or a Microsoft-supported repair procedure.

    Your ETW traces, schema comparison, and successful cache regeneration provide compelling evidence that the failure is occurring during inventory-cache initialization rather than within the Win32AppInventory CSP itself.

    References

    I hope this answer has brought you useful information. If so, please click on "Accept Answer" and consider upvoting it. Doing so helps other community members identify useful solutions to similar issues.

    Thanks,

    Maurice

    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.