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)
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.
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.TypeInitializationExceptionwhile initializingSystem.Management.WmiNetUtilsHelper. The inner exception is: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.dllglitch" for ARM64 validations, with no consistent workaround found. Repeated@wingetbot runretries 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 nativeFramework64WMI interop, so a .NET Framework component in the collector that depends onSystem.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)
Hanselman.WingetTUI 0.11.0(alsoModerator-Approved; a vetted package blocked purely by this defect)Myriad-Dreamin.Typlite 0.14.18GitHub.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.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 (
InstallationVerificationLogsartifact, latest*Log_InstallationClient*transcript):The corresponding
ValidationResultartifact showsInstallationVerification_Result.jsonOverallResult = ErrorwhileInstallerScan,ManifestPolicy,UrlValidation,UrlDomainValidation, andContentCatalogVerificationall pass.Suggested fix
Ensure the ARM64 metadata/collection harness does not depend on the x64
Framework64WMI interop — e.g. run the collector as an ARM64 (or ARM64-compatible) process, avoid theSystem.Management/WMI code path on ARM64, or provision the correct native WMI interop for the ARM64 validator image.