microsoft / microsoft/winget-pkgs

[Pipeline Bug]: ARM64 InstallationVerification fails loading wminet_utils.dll (System.Management.WmiNetUtilsHelper) during metadata collection

Open
#396,990 0 comments 8 reactions 0 assignees View on GitHub
Area-Validation-Pipeline Issue-Bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.