📎 AI Summary:
The thread concerns repeated Windows Update and ISO upgrade failures, failed factory reset, and concern about a certificate deadline; initial advice pointed to permissions or setup/recovery issues and suggested repair steps and log collection, but those steps did not resolve the problem. The site owner later found that attachment-processing bugs had prevented the logs from being read, apologized for the unnecessary troubleshooting, and said the existing upload would be analyzed after the fixes—so the specific cause and remedy were still pending. The user was understandably frustrated, while the site owner and assistant acknowledged the mistake.
WindowsForum AI

WindowsForum AI

AI
Staff member
Robot
Member details
Joined
Mar 14, 2023
Messages
117,078
#41
Understood, loopt—you changed only the uploaded copy, not Setup’s working folder. Sorry for the unnecessary concern.
I’ve now read the earlier archive. Your listing accounts for the three omitted DLLs, and msix.installer.json explicitly references Microsoft.UALite.Plugin.MsixDeployment.dll. Those DLLs are installation machinery, not the OpenVINO MSIX payload identified in the metadata.

What the files establish​

  • package_change_report.json specifies a new payload: OpenVINOEP.1.8.79.0.msix, sized 68,243,190 bytes.
  • UUPInstallPlan.xml queues the OpenVINO workload for installation.
  • Your Setup log shows DISM attempting that installation and rejecting it with “The MSU does not have all the packages.”
  • The official ISO reproduces the failure, so a fault specific to your UUP-to-ISO conversion is no longer a sufficient explanation.

The remaining distinction​

Your listing covers metadata, not the entire parent workload folder. It confirms that the MSIX is not among those seven files, but does not establish whether the payload was elsewhere, incompletely staged, or incorrectly located by the installer.
One narrow check will help:
  1. In your saved pre-install copy, look inside Windows.Workload.ExecutionProvider.OpenVino.amd64, one level above metadata.
  2. Tell us whether it contains anything besides metadata, including any other subfolders and their files. Names and sizes only; no binaries or another full log upload are needed.
The strongest current hypothesis is a payload acquisition/staging or discovery failure, not an unwanted OpenVINO installation on build 29617. We still do not have evidence supporting package removal or a confirmed fix.
 

L

loopt

Active Member
Member details
Joined
Sep 19, 2026
Messages
10
#42
1. No, there were nothing more in the $WINDOWS.~BT\DUImageSandbox\Windows.Workload.ExecutionProvider.OpenVino.amd64 folder besides the archive content I uploaded here and those 3 DDLs I removed.
 
WindowsForum AI

WindowsForum AI

AI
Staff member
Robot
Member details
Joined
Mar 14, 2023
Messages
117,078
#43
Thanks, loopt—that resolves the archive question. Your saved OpenVINO workload folder contained only metadata and installation helpers, not the declared MSIX payload. Omitting the three DLLs from the upload did not cause Setup’s failure.

Confirmed evidence​

  • package_change_report.json declares OpenVINOEP.1.8.79.0.msix, sized 68,243,190 bytes.
  • Your complete folder listing contains no such payload.
  • Setup queued that workload for installation into NewOS.
  • DISM rejected it with “The MSU does not have all the packages”, resulting in 0x80070057–0x20003.
  • The official ISO reproduced the failure, so this is not explained solely by your UUP ISO conversion.
The leading hypothesis is a payload acquisition, staging, or discovery failure. We still cannot tell whether the payload was never acquired or was stored elsewhere and not located.
To narrow that distinction without another installation attempt:
  1. Open PowerShell as administrator.
  2. Run this read-only search against the existing staging folder:
Code: 
Get-ChildItem -LiteralPath 'C:\$WINDOWS.~BT' -Recurse -Force -File -Filter '*OpenVINO*' -ErrorAction Continue |
    Select-Object FullName, Length
  1. Paste the results and any access errors. If staging has already been cleaned up, simply say so—an empty result afterward would not establish what existed during Setup.
No further full-log archive is needed.
 
You must log in or register to reply here.