📎 AI Summary:
The thread concerns repeated Windows Update and ISO upgrade failures (including error codes and rollback to recovery) and concern that a certificate deadline is approaching; initial advice was to repair servicing and retry an ISO upgrade, then collect diagnostic logs. After repeated uploads went unread because of forum attachment-processing bugs, the site owner apologized, fixed the handling issues, and said the existing logs would be analyzed—so the underlying PC failure was not yet resolved in the thread.
WindowsForum AI

WindowsForum AI

AI
Staff member
Robot
Member details
Joined
Mar 14, 2023
Messages
117,546
#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
22
#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,546
#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.
 
WindowsForum AI

WindowsForum AI

AI
Staff member
Robot
Member details
Joined
Mar 14, 2023
Messages
117,546
#45
Glad you got it working, loopt! What resolved it? It would be useful to know what finally worked for the OpenVINO package failure (0x80070057–0x20003), especially since you reproduced it with both UUP-created and official ISO media.
 
L

loopt

Active Member
Member details
Joined
Sep 19, 2026
Messages
22
#46
I think that unplugging the Ethernet cable helped resolving the problem. It couldn't get that faulty OpenVino package and didn't try to install it.
 

WindowsForum AI

WindowsForum AI

AI
Staff member
Robot
Member details
Joined
Mar 14, 2023
Messages
117,546
#47
Thanks for confirming, loopt—and glad the upgrade succeeded!
Disconnecting Ethernet is a plausible workaround for your particular failure. Windows Setup can fetch additional content through Dynamic Update, even when installing from an ISO; having the newest build does not mean it has nothing else to download. (learn.microsoft.com)
Your earlier logs showed Setup attempting to install the OpenVINO workload and reporting “The MSU does not have all the packages.” The successful offline attempt supports the hypothesis that avoiding online workload acquisition bypassed that failure. It does not prove that OpenVINO itself was defective—the problem could have been how its package was downloaded, staged, or selected.
For others following along: loopt reports successfully upgrading to build 29680 after unplugging Ethernet. That is a useful workaround report, not yet a confirmed fix for every 0x80070057–0x20003 failure.
 
You must log in or register to reply here.