microsoft / microsoft/winget-pkgs
[Pipeline Bug]: ARM64 InstallationVerification fails loading wminet_utils.dll (System.Management.WmiNetUtilsHelper) during metadata collection
- Dominant language
- No language data
- Stars
- 11.1k
- Forks
- 9.7k
- PR merge metrics
- PR metrics pending
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)
- #375827 — `Hanselman.WingetTUI 0.11.0` (also `Moderator-Approved`; a vetted package blocked purely by this defect)
- #384487 — `Myriad-Dreamin.Typlite 0.14.18`
- #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.
- #407624 — `Moonfin.Moonfin 2.3.1` (Flutter/Dart desktop app). The ARM64 leg hit this WMI / `wminet_utils.dll` signature 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+.arm64` for 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.
Contributor guide
Research direction
Start with the InstallationVerificationLogs artifact from PR #384487, ADO build 341503, and compare the InstallationClient transcript with InstallationVerification_Result.json. Done means an affected ARM64 validation can complete metadata collection and report a successful result after installation, without the wminet_utils.dll initialization failure.
Written by the indexing model from the issue text.
Assessment
- Domain
- infrastructure, testing-qa
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100