📎 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.
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.
@loopt, thanks for reporting this. Build 29671 has not resolved the upgrade failure on your machine, so simply telling you to wait for a newer build would not be enough.
I also need to correct our earlier certainty: we treated the suspected regression as established too quickly. Your message matches ProfPieHunter’s ISO error, but matching error codes alone do not establish the same underlying cause. SetupDiag and the surrounding Setup log entries are needed to distinguish them.
Please start with these read-only checks, without retrying the installation:
I also need to correct our earlier certainty: we treated the suspected regression as established too quickly. Your message matches ProfPieHunter’s ISO error, but matching error codes alone do not establish the same underlying cause. SetupDiag and the surrounding Setup log entries are needed to distinguish them.
Please start with these read-only checks, without retrying the installation:
- Run
winverand tell us your currently installed build. Are you also upgrading from 29617? - Tell us whether the 29671 attempt used Windows Update or an ISO. If ISO, where did you obtain it?
- In File Explorer, enter
%windir%\Logs\SetupDiagand attachSetupDiagResults.xml, if present. Windows Setup normally writes its automatic diagnostic report there. Please check that its date corresponds to the 29671 attempt. (learn.microsoft.com)
Last edited:
@loopt, your report identifies a specific package-processing failure, rather than confirming the earlier
What remains uncertain: whether the missing package content originated in the UUP-created media, Setup’s update downloads, or another servicing issue. This report alone cannot distinguish those possibilities.
0x80070005 issue.What is confirmed
DISM reported:Setup failed during Safe OS, while adding
Windows.Workload.ExecutionProvider.OpenVino.amd64 from C:\$WINDOWS.~BT\DUImageSandbox, with 0x80070057–0x20003.What remains uncertain: whether the missing package content originated in the UUP-created media, Setup’s update downloads, or another servicing issue. This report alone cannot distinguish those possibilities.
Minimum next checks
- Tell us whether you selected “Not right now” for downloading updates during Setup, or allowed Setup to download them.
- Share
setupact.logandsetuperr.logfromC:\$WINDOWS.~BT\Sources\Panther, corresponding to the September 19, 12:52 failure. Review them for personal information before uploading.
datawizard0103
Excellent Member
The disk space is not the issue here. Since both Windows Update and an ISO upgrade fail and Factory Reset also fails, I’d check Windows Recovery Environment (WinRE) and the recovery partition before doing anything destructive. Run reagentc /info in an elevated Command Prompt. If WinRE shows Disabled or has no location, check whether C:\Windows\System32\Recovery\Winre.wim exists. A missing or broken WinRE setup can explain both Reset and upgrade failures. Also run DISM /Online /Cleanup-Image /RestoreHealth followed by sfc /scannow, then reboot and try the upgrade again. Microsoft specifically recommends repairing the component store for update failures. If WinRE is missing, I’d fix that rather than repeatedly retrying the ISO.
nellahere
Active Member
If this is a software/system upgrade, I’d avoid trying to fix each error individually at first. Check the upgrade logs for the first error—later errors are often just consequences of that one. Also verify that 29639 is compatible with your current version and that the required dependencies/repositories are available. If you paste the exact error output or log here, I can help narrow down the cause.
@nellahere, the diagnostic reports are already in the thread. One important refinement: in Windows Setup logs, the first line marked “Error” is not necessarily the failure that stopped the upgrade. Microsoft recommends using the result and phase codes to locate the relevant log, then examining the final occurrence and the operations immediately before it.
The reports identify two different failures:
The reports identify two different failures:
- ProfPieHunter’s August 1 attempt:
0x80070005–0x2000A. In Safe OS, Setup could not moveC:\WindowstoC:\Windows.oldwhile relocating the OS; the log says access denied. - loopt’s September 19 attempt to install 29671:
0x80070057–0x20003. In Safe OS, DISM failed while addingWindows.Workload.ExecutionProvider.OpenVino.amd64to the new OS; its message says “The MSU does not have all the packages.”
Last edited:
@loopt, confirmed: your 29680 attempt fails on the same OpenVino package operation as your 29671 attempt. I compared both archives, including their SetupDiag reports and the extracted failure sections of
Both reports identify:
The failing operation is adding:
to
In both attempts, that operation fails before the restart, is retried in Safe OS, and fails again at 49% during Install updates. The subsequent “Cannot revert execution … Add boot entry” message follows that package failure; it is not evidence that you should repair boot partitions.
This establishes a repeatable package-processing failure—not its ultimate cause. The available excerpts cannot determine whether the package content is incomplete, the media-building process is involved, or Setup incorrectly handles otherwise valid content. They do not justify removing OpenVino, changing permissions, or repairing WinRE.
If you have not already tried that explicit switch, I suggest one controlled attempt using your existing 29680 ISO:
If it succeeds, that implicates the Dynamic Update path. If it fails again, stop repeating the same installation; the same displayed code alone would not prove the same package failed. The next avenue is reviewing the media/package construction or escalating this reproducible failure—not resets or registry cleanup.
You have supplied enough evidence to show that moving from 29671 to 29680 did not resolve your particular failure. I would not simply tell you to wait for yet another build.
So the next test is to get the package from Microsoft rather than from that ISO:
setupact.log.What the two attempts show
| Attempt | Fatal log timestamp | Result |
|---|---|---|
| 29671, September 19 | 22:06:30 | OpenVino package installation fails |
| 29680, October 3 | 04:19:44 | Same package and failure |
Code:
The MSU does not have all the packages.
Failed to install UUP package.
0x80070057 - 0x20003C:\$WINDOWS.~BT\DUImageSandbox\Windows.Workload.ExecutionProvider.OpenVino.amd64to
C:\$WINDOWS.~BT\NewOS.In both attempts, that operation fails before the restart, is retried in Safe OS, and fails again at 49% during Install updates. The subsequent “Cannot revert execution … Add boot entry” message follows that package failure; it is not evidence that you should repair boot partitions.
This establishes a repeatable package-processing failure—not its ultimate cause. The available excerpts cannot determine whether the package content is incomplete, the media-building process is involved, or Setup incorrectly handles otherwise valid content. They do not justify removing OpenVino, changing permissions, or repairing WinRE.
One targeted test—not another identical retry
Your observation about no downloads is partly supported: both logs show zero packages in the initial Setup-update scan. However, that does not establish that every subsequent update operation was disabled. Dynamic Update covers more than obtaining a newer Windows build. Microsoft provides an explicit/DynamicUpdate Disable switch to disable its search, download, and installation operations.If you have not already tried that explicit switch, I suggest one controlled attempt using your existing 29680 ISO:
- Back up important files, retain both diagnostic archives, and have your BitLocker recovery key available if encryption is enabled. This is a real upgrade attempt, not a read-only scan.
- Close any running Windows Setup window.
- In File Explorer, right-click the ISO and select Mount. Note its drive letter under This PC.
- Disconnect Ethernet and turn Wi-Fi off.
- Search Start for Command Prompt, then select Run as administrator.
- Run the following, replacing
D:with the mounted ISO’s actual drive letter:
D:\setup.exe /DynamicUpdate Disable - Continue from within Windows. Proceed only if “Keep personal files and apps” is selected. Otherwise cancel. The command-line switch avoids relying on an update-choice screen appearing.
- After installation completes—or rollback returns you to Windows—reconnect Ethernet or turn Wi-Fi back on.
If it succeeds, that implicates the Dynamic Update path. If it fails again, stop repeating the same installation; the same displayed code alone would not prove the same package failed. The next avenue is reviewing the media/package construction or escalating this reproducible failure—not resets or registry cleanup.
You have supplied enough evidence to show that moving from 29671 to 29680 did not resolve your particular failure. I would not simply tell you to wait for yet another build.
If that test fails too
The logs point at the installation media more than at your PC. In both attempts Setup adds OpenVino as a conditional workload (one it includes only on qualifying hardware), then skips downloading it (Skipping UUP Product package download) and expects the package to be on the ISO. The The MSU does not have all the packages error that follows fits an ISO built from UUP files that is missing part of that workload.So the next test is to get the package from Microsoft rather than from that ISO:
- Upgrade through Settings > Windows Update instead of the ISO, where Setup can download the workload itself; or
- Use an official Microsoft Insider ISO for this build if one is available, or rebuild your UUP ISO from a fresh download.
Last edited:
Adding better large file support for the AI.. although this type of 10MB error log will likely exceed context limits. We can try to filter such files for errors automatically. (A bit off topic)
Mike
Yeah, I know that setupact.log is enormously huge. But your bot explicitly asked for it.😅 Then he choked on it and went silent for two weeks. He got offended, I suppose.😆
WindowsForum AI
What is this package OpenVino for? Google says: “An official Microsoft Windows ISO does not natively pre-install the Intel OpenVINO package out of the box.“ But I built my ISO from the MS UUP service. It has to be identical to the official MS ISO. It least I have never seen evidences against it.
Yeah, I know that setupact.log is enormously huge. But your bot explicitly asked for it.😅 Then he choked on it and went silent for two weeks. He got offended, I suppose.😆
WindowsForum AI
What is this package OpenVino for? Google says: “An official Microsoft Windows ISO does not natively pre-install the Intel OpenVINO package out of the box.“ But I built my ISO from the MS UUP service. It has to be identical to the official MS ISO. It least I have never seen evidences against it.
@loopt — no offence taken 😄. You supplied what was requested; the silence was a failure on our side. Sorry.
OpenVINO is for running AI models, but the package in your log is not necessarily the standalone Intel development toolkit Google is describing.
Your pasted SetupDiag report identifies:
That name is consistent with the Windows execution-provider component—not evidence that you installed Intel’s complete developer toolkit. Microsoft also lists OpenVINO among Windows ML’s supported execution providers. The report alone does not identify which particular Windows feature needs it on your machine.
So the Google statement does not establish that this package should be absent: a standalone toolkit and a Windows-managed execution-provider component are different things. Microsoft’s documentation confirms the latter exists. (support.microsoft.com)
If you used UUP dump, distinguish that project from Microsoft’s UUP infrastructure: UUP dump explicitly states that it is not affiliated with Microsoft.
The defensible conclusion is a package-servicing failure involving the Windows OpenVINO execution provider—not a proven bad ISO. I would not recommend installing or removing OpenVINO manually on the strength of that report.
OpenVINO is for running AI models, but the package in your log is not necessarily the standalone Intel development toolkit Google is describing.
What this package does
Microsoft explicitly documents an Intel OpenVINO Execution Provider as a Windows AI component. It lets Windows and applications run machine-learning models using supported Intel CPUs, GPUs and NPUs. An execution provider is the backend that translates model operations into work the hardware can execute efficiently. (support.microsoft.com)Your pasted SetupDiag report identifies:
Windows.Workload.ExecutionProvider.OpenVino.amd64That name is consistent with the Windows execution-provider component—not evidence that you installed Intel’s complete developer toolkit. Microsoft also lists OpenVINO among Windows ML’s supported execution providers. The report alone does not identify which particular Windows feature needs it on your machine.
So the Google statement does not establish that this package should be absent: a standalone toolkit and a Windows-managed execution-provider component are different things. Microsoft’s documentation confirms the latter exists. (support.microsoft.com)
Is a UUP-built ISO identical to Microsoft’s ISO?
Microsoft-sourced installation files do not automatically mean an identical finished ISO. There is a separate conversion/assembly stage: the UUP converter’s own documentation describes building ISO/WIM media from UUP files and provides options affecting that process. That does not make your ISO defective—it means equivalence cannot simply be assumed from the files’ origin.If you used UUP dump, distinguish that project from Microsoft’s UUP infrastructure: UUP dump explicitly states that it is not affiliated with Microsoft.
What your evidence actually establishes
In the September 19 SetupDiag XML you pasted, Setup failed while adding that OpenVINO package to the new Windows installation. DISM reported:That establishes the failing servicing operation, but not why its expected package content was unavailable or could not be processed. It does not, by itself, prove your ISO is incomplete, that OpenVINO is incompatible with your computer, or that installing Intel’s standalone toolkit would fix it.
The defensible conclusion is a package-servicing failure involving the Windows OpenVINO execution provider—not a proven bad ISO. I would not recommend installing or removing OpenVINO manually on the strength of that report.
Last edited:
@WindowsForum AI
1. I'll try to run the Windows installation again if the build 29680 official ISO becomes available.
2. How can I check if that OpenVino package is installed on my current 29617 build? Then I can try to remove it. I definitely have no need for it.
1. I'll try to run the Windows installation again if the build 29680 official ISO becomes available.
2. How can I check if that OpenVino package is installed on my current 29617 build? Then I can try to remove it. I definitely have no need for it.
@loopt — yes, we can check without changing anything. But I would not remove it as an upgrade workaround yet. Your report shows Setup adding the package to
Paste just any matching rows and package details—no more large logs needed. We should identify exactly what is present and review its servicing status before considering removal.
C:\$WINDOWS.~BT\NewOS, not a failure removing or updating an existing copy in your current installation.Check your current build
- Open Command Prompt as administrator.
- Run this inventory command. It lists servicing packages in your currently running Windows, without installing or removing anything:
DISM /Online /Get-Packages /Format:Table - Search the output for
OpenVino. For a shorter, filtered view, run:
DISM /Online /Get-Packages /Format:Table | findstr /i "OpenVino ExecutionProvider" - If a matching package appears, check its State.
Installedmeans installed;Stagedis not the same as installed. For details, use the following command, replacing the placeholder with the complete package identity from your output, not the folder name from SetupDiag:
DISM /Online /Get-PackageInfo /PackageName:"PASTE_COMPLETE_PACKAGE_IDENTITY_HERE"
Why hold off on removal?
Your existing evidence does not establish that an installed OpenVINO component is causing the failure. Even if you do not use it, removing a current copy would not establish that Setup can skip the package when building the new installation.Paste just any matching rows and package details—no more large logs needed. We should identify exactly what is present and review its servicing status before considering removal.
Last edited:
@WindowsForum AI
1. I have no OpenVino package installed on my installed Windows build 29617.
2. I downloaded an official ISO of build 29671 and made another attempt to install it. It expectedly failed with the same error: 0x80070057 - 0x20003.
Here are extracts from setupdiagresults.xml and setupact.log:
setupdiagresults.xml:
setupact.log:
I also saved folder containing the OpenVino package before the Windows installation. Maybe you will get some clues from it. Or maybe not.
1. I have no OpenVino package installed on my installed Windows build 29617.
2. I downloaded an official ISO of build 29671 and made another attempt to install it. It expectedly failed with the same error: 0x80070057 - 0x20003.
Here are extracts from setupdiagresults.xml and setupact.log:
setupdiagresults.xml:
Code:
<SetupDiag xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="https://docs.microsoft.com/en-us/windows/deployment/upgrade/setupdiag">
<FailureDetails>RollbackErrorCode = 0x80070057, ExtendedCode = 0x20003, LastOperation = Add [1] package C:\$WINDOWS.~BT\DUImageSandbox\Windows.Workload.ExecutionProvider.OpenVino.amd64 to C:\$WINDOWS.~BT\NewOS, LastPhase = Safe OS</FailureDetails>
<Setup360Result>0x80070057</Setup360Result>
<Setup360Extended>0x20003</Setup360Extended>
<SetupPhaseInfo>
<PhaseName>Safe OS</PhaseName>
<PhaseStartTime>10/04/2026 16:23:05</PhaseStartTime>
<PhaseEndTime>01/01/0001 00:00:00</PhaseEndTime>
<PhaseTimeDelta>0:00:00:00.0000000</PhaseTimeDelta>
<CompletedSuccessfully>false</CompletedSuccessfully>
</SetupPhaseInfo>
<SetupOperationInfo>
<OperationName>Add [1] package C:\$WINDOWS.~BT\DUImageSandbox\Windows.Workload.ExecutionProvider.OpenVino.amd64 to C:\$WINDOWS.~BT\NewOS</OperationName>
<OperationStartTime>10/04/2026 16:37:48</OperationStartTime>
<OperationEndTime>01/01/0001 00:00:00</OperationEndTime>
<OperationTimeDelta>0:00:00:00.0000000</OperationTimeDelta>
<CompletedSuccessfully>false</CompletedSuccessfully>
</SetupOperationInfo>
</SetupDiag>setupact.log:
Code:
Feature added due to conditional: Group: UUPProduct, FMID: (null), Feature: Windows.Workload.ExecutionProvider.OpenVino.amd64
...
Installing feature: Group: UUPProduct, FMID: (null), Feature: Windows.Workload.ExecutionProvider.OpenVino.amd64
Installing using canonical Package: Windows.Workload.ExecutionProvider.OpenVino.amd64~~amd64~~2.2605.1.0
...
Skipping UUP Product package download from ActionList [Windows.Workload.ExecutionProvider.OpenVino.amd64.rum.json.cab]
...
Loading Ualite session for sandbox [C:\$WINDOWS.~BT\DUImageSandbox\Windows.Workload.ExecutionProvider.OpenVino.amd64\metadata]
...
2026-10-04 15:25:01, Warning MOUPG MoSetupPlatform: Error retrieving installed size for package [C:\$WINDOWS.~BT\DUImageSandbox\Windows.Workload.ExecutionProvider.OpenVino.amd64] -> [0x80070490]
2026-10-04 15:25:01, Info SP QueueAddCbsPackage called with package target: 1 type: 5, [1] paths
2026-10-04 15:25:01, Info SP QueueAddCbsPackage called with [1] paths
2026-10-04 15:25:01, Info SP QueueAddCbsPackage called with path C:\$WINDOWS.~BT\DUImageSandbox\Windows.Workload.ExecutionProvider.OpenVino.amd64; install size 0
2026-10-04 15:25:01, Info SP OPERATIONTRACK: Enqueue Operation: 36|Add [1] package C:\$WINDOWS.~BT\DUImageSandbox\Windows.Workload.ExecutionProvider.OpenVino.amd64 to C:\$WINDOWS.~BT\NewOS
2026-10-04 15:25:01, Warning MOUPG MoSetupPlatform: Error retrieving installed size for package [C:\$WINDOWS.~BT\DUImageSandbox\Windows.Workload.LanguageModel.amd64] -> [0x80070490]
2026-10-04 15:25:01, Info SP QueueAddCbsPackage called with package target: 1 type: 5, [1] paths
2026-10-04 15:25:01, Info SP QueueAddCbsPackage called with [1] paths
2026-10-04 15:25:01, Info SP QueueAddCbsPackage called with path C:\$WINDOWS.~BT\DUImageSandbox\Windows.Workload.LanguageModel.amd64; install size 0
2026-10-04 15:25:01, Info SP OPERATIONTRACK: Enqueue Operation: 36|Add [1] package C:\$WINDOWS.~BT\DUImageSandbox\Windows.Workload.LanguageModel.amd64 to C:\$WINDOWS.~BT\NewOS
...
2026-10-04 16:06:46, Info DISM MsuManager: PID=9312 TID=8376 Loading updateagent dll from C:\$WINDOWS.~BT\DUImageSandbox\Windows.Workload.ExecutionProvider.OpenVino.amd64\metadata\ualite.dll. - CDismMsuManager::ProcessWithUpdateAgent
2026-10-04 16:06:46, Error DISM MsuManager: PID=9312 TID=8376 The MSU does not have all the packages. - CDismMsuManager::ProcessWithUpdateAgent(hr:0x80070057)
2026-10-04 16:06:46, Error DISM MsuManager: PID=9312 TID=8376 Failed to install UUP package. - CDismMsuPackage::DoInstall(hr:0x80070057)
2026-10-04 16:06:46, Error DISM MsuManager: PID=9312 TID=8376 Failed to execute the install in expanded MSU folder C:\$WINDOWS.~BT\DUImageSandbox\Windows.Workload.ExecutionProvider.OpenVino.amd64. - CDismMsuPackage::ProcessMsu(hr:0x80070057)
2026-10-04 16:06:46, Error DISM MsuManager: PID=9312 TID=8376 Failed to apply the MSU unattend file to the image. - CDismMsuPackage::Install(hr:0x80070057)
2026-10-04 16:06:46, Error DISM API: PID=3932 TID=5516 Failed to install msu package C:\$WINDOWS.~BT\DUImageSandbox\Windows.Workload.ExecutionProvider.OpenVino.amd64 - CAddPackageCommandObject::InternalExecute(hr:0x80070057)
2026-10-04 16:06:46, Error DISM API: PID=3932 TID=5516 InternalExecute failed - CBaseCommandObject::Execute(hr:0x80070057)
2026-10-04 16:06:46, Error DISM API: PID=3932 TID=16180 CAddPackageCommandObject internal execution failed - DismAddPackageInternal(hr:0x80070057)
2026-10-04 16:06:46, Error SP CAddCbsPackage::DoExecute: Failed to add package Add [1] package C:\$WINDOWS.~BT\DUImageSandbox\Windows.Workload.ExecutionProvider.OpenVino.amd64 to C:\$WINDOWS.~BT\NewOS. Error: 0x80070057
2026-10-04 16:06:46, Info DISM API: PID=3932 TID=16180 Input parameters: Session: 2, ScanImage: 0, CancelEvent: 0x000000000000CEC8, Progress: 0x00007FF9AF29B730, UserData: 0x000000DD2668EDC0 - DismCheckImageHealthInternal
2026-10-04 16:06:46, Info DISM API: PID=3932 TID=16180 Successfully enqueued command object - CCommandThread::EnqueueCommandObject
2026-10-04 16:06:46, Info DISM API: PID=3932 TID=5516 ExecuteLoop: CommandQueue signaled - CCommandThread::ExecuteLoop
2026-10-04 16:06:46, Info DISM API: PID=3932 TID=5516 Successfully dequeued command object - CCommandThread::DequeueCommandObject
...@loopt — your archive does provide a useful clue. I read its extracted JSON and XML files, and your official-ISO test means a UUP-to-ISO conversion problem cannot explain all these failures.
That MSIX is not present in the extracted archive contents. The archive contains its metadata and installation instructions, including an 11,003-byte metadata CAB, rather than the expected 65 MiB payload.
Your log confirms that Setup queues this workload for the new Windows image, then fails with “The MSU does not have all the packages.”
Hypothesis: the required payload was not acquired or prepared correctly. We cannot yet establish why. Also, absence from the archive proves absence from the original folder only if you archived that entire folder.
The current evidence points to Setup failing to install newly selected workload content, not an established conflict with something already installed on build 29617.
What is confirmed
package_change_report.json specifies this payload:| Item | Expected value |
|---|---|
| Filename | OpenVINOEP.1.8.79.0.msix |
| Version | 1.8.79.0 |
| Size | 68,243,190 bytes — approximately 65 MiB |
| Package name | MicrosoftCorporationII.WinML.Intel.OpenVINO.EP.1.8 |
Your log confirms that Setup queues this workload for the new Windows image, then fails with “The MSU does not have all the packages.”
Hypothesis: the required payload was not acquired or prepared correctly. We cannot yet establish why. Also, absence from the archive proves absence from the original folder only if you archived that entire folder.
Two small checks
- Please confirm: does this archive contain the entire saved OpenVINO folder, or did you select only its metadata? If the saved folder remains accessible, open PowerShell in that folder and run this read-only inventory:
Code:Get-ChildItem -Recurse -File -Force | Select-Object FullName, Length - My earlier
DISM /Get-Packagescheck was incomplete for this purpose: the metadata now identifies an MSIX, which needs app-package inventory. In PowerShell as administrator, run these read-only checks:
Code:Get-AppxPackage -AllUsers -Name '*OpenVINO*' | Select-Object Name, PackageFullName, Status Get-AppxProvisionedPackage -Online | Where-Object { $_.DisplayName -match 'OpenVINO' } | Select-Object DisplayName, PackageName
The current evidence points to Setup failing to install newly selected workload content, not an established conflict with something already installed on build 29617.
Thanks, loopt. Were those three DLLs removed only from the copy you uploaded, or from the actual
If you omitted them only to make the upload smaller, that would not explain the installation failure. It also means we cannot use missing files in the uploaded archive as proof that Setup’s original package was incomplete—my earlier conclusion on that point was too strong.
The logs establish that DISM rejected the staged OpenVINO workload with “The MSU does not have all the packages.” They do not yet identify which payload or package relationship was missing.
Please provide just:
C:\$WINDOWS.~BT\DUImageSandbox folder before Setup ran? That distinction matters.If you omitted them only to make the upload smaller, that would not explain the installation failure. It also means we cannot use missing files in the uploaded archive as proof that Setup’s original package was incomplete—my earlier conclusion on that point was too strong.
The logs establish that DISM rejected the staged OpenVINO workload with “The MSU does not have all the packages.” They do not yet identify which payload or package relationship was missing.
Please provide just:
- The filenames and relative folder paths of those three DLLs—no need to upload the binaries.
- Whether you removed them only from the upload copy, or also from the folder Setup actually used.
Of course I didn't corrupt my actual $WINDOWS.~BT folder. I removed those DLLs from the archive I uploaded here because they wouldn't be useful for the analysis.
The entire content of folder $WINDOWS.~BT\DUImageSandbox\Windows.Workload.ExecutionProvider.OpenVino.amd64\metadata:
The entire content of folder $WINDOWS.~BT\DUImageSandbox\Windows.Workload.ExecutionProvider.OpenVino.amd64\metadata:
Code:
<DIR> .state
46 device_information.json
1447304 Microsoft.UALite.Plugin.MsixDeployment.dll
2875 msix.installer.json
1260 package_change_report.json
6163912 ualite.dll
6163912 UpdateAgent.dll
11003 Windows.Workload.ExecutionProvider.OpenVino.amd64.rum.json.cab
7 files 13790312 bytes
