Repository navigation
Description
Brief description of your issue
On ARM64 installation validation, the package installs successfully but the pipeline then fails the Installation Validation step when the metadata-collection harness throws a System.TypeInitializationException while initializing System.Management.WmiNetUtilsHelper. The inner exception is:
System.ComponentModel.Win32Exception (193): Failed to load required native library
'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\wminet_utils.dll'.
at System.Management.WmiNetUtilsHelper..cctor()
The install itself succeeds — the InstallationVerification log shows Package Installed Successfully. immediately before the exception. The failure occurs during the post-install data/metadata collection phase, so a clean package is failed for a reason unrelated to the package.
This is a validator-image / harness defect, deterministic on the affected ARM64 environment. Community contributors already refer to it as the "infamous wminet_utils.dll glitch" for ARM64 validations, with no consistent workaround found. Repeated @wingetbot run retries do not clear it (e.g. PR #384487 was retried 8 times over 6 days with the identical result).
Probable root cause
The path being loaded is C:\Windows\Microsoft.NET\**Framework64**\v4.0.30319\wminet_utils.dll — the x64 .NET Framework directory — on an ARM64 validation host. On ARM64 Windows there is no native Framework64 WMI interop, so a .NET Framework component in the collector that depends on System.Management (WMI) fails to initialize. This points at the metadata collector running as an x64 process (or targeting the x64 Framework path) on ARM64 rather than at anything in the submitted manifests.
Affected pull requests (open, currently blocked by this signature)
- New version: Hanselman.WingetTUI version 0.11.0 #375827 —
Hanselman.WingetTUI 0.11.0(alsoModerator-Approved; a vetted package blocked purely by this defect) - New package: Myriad-Dreamin.Typlite version 0.14.18 #384487 —
Myriad-Dreamin.Typlite 0.14.18 - GitHub.Copilot version v1.0.66 #395514 —
GitHub.Copilot v1.0.66(first-party). ARM64 leg (copilot-win32-arm64.zip) hits this WMI exception and an arm64 Defender scan-completion failure (Installer failed security check … Result: 0x80004005"resource missing" — the scan could not complete; no threat detected). Deterministic across repeated runs. - New package: Moonfin.Moonfin version 2.3.1 #407624 —
Moonfin.Moonfin 2.3.1(Flutter/Dart desktop app). The ARM64 leg hit this WMI /wminet_utils.dllsignature on its first validation run (2026-07-25); the x64 leg is unblocked once the correct per-arch VCRedist dependency is set (Microsoft.VCRedist.2015+.arm64for the arm64 installer).
Historically observed in ARM64 runs on PRs whose current blocker later became something else: #387868, #392295.
Reproduction / evidence
Reproduces on ARM64 InstallationVerification. From PR #384487, ADO build 341503 (InstallationVerificationLogs artifact, latest *Log_InstallationClient* transcript):
Package Installed Successfully.
> Blocked/Waiting on data collection completion.
> Unblocked on data collection completion.
Stopped Metadata collection
> ---> System.TypeInitializationException: The type initializer for 'System.Management.WmiNetUtilsHelper' threw an exception.
> ---> System.ComponentModel.Win32Exception (193): Failed to load required native library
'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\wminet_utils.dll'.
The corresponding ValidationResult artifact shows InstallationVerification_Result.json OverallResult = Error while InstallerScan, ManifestPolicy, UrlValidation, UrlDomainValidation, and ContentCatalogVerification all pass.
Suggested fix
Ensure the ARM64 metadata/collection harness does not depend on the x64 Framework64 WMI interop — e.g. run the collector as an ARM64 (or ARM64-compatible) process, avoid the System.Management/WMI code path on ARM64, or provision the correct native WMI interop for the ARM64 validator image.
Activity
zhoufenqin commentedon Oct 26, 2026
Another matching ARM64 validation case: #456609 (
GitHub.Copilot.modernization.agent1.0.77).The validation diagnostics posted by Stephen Gillie (@stephengillie) are here:
#456609 (comment)
They include the same exception signature:
The diagnostics list executables under
runtimes\win-arm64\native, and end withFull Scan Operation Failed.The PR currently hasValidation-Defender-Error; the posted diagnostics do not include a malware detection name.Our previous release, 1.0.76, also repeatedly encountered the same WMI exception and scan-failure message in #438345, which was ultimately merged on October 12:
#438345 (comment)
For 1.0.77, both MSI hashes in the submitted manifest match the corresponding GitHub release asset SHA256 digests, so we have not found a manifest/release hash mismatch.
Could the validation team confirm whether #456609 is affected by this known ARM64 harness issue, and whether there is a fix or a supported validation workaround?
To keep the symptoms separate: the log also reports
STATUS_DLL_NOT_FOUNDfor two bundled ARM64 computer-use helper executables. Their dependency requirements still need investigation; we are not assuming that every executable exit code is caused by the WMI issue. Likewise, #399077 may be relevant to the scan-completion failure, but we do not have the Defender logs needed to confirm that connection.