Skip to content

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

Open

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)

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

  1. zhoufenqin commented on Oct 26, 2026

    @zhoufenqin
    Member

    Another matching ARM64 validation case: #456609 (GitHub.Copilot.modernization.agent 1.0.77).

    The validation diagnostics posted by Stephen Gillie (@stephengillie) are here:
    #456609 (comment)

    They include the same exception signature:

    Caught exception while trying to kill child processes:
    System.TypeInitializationException: The type initializer for
    'System.Management.ManagementPath' threw an exception.
     ---> 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 diagnostics list executables under runtimes\win-arm64\native, and end with Full Scan Operation Failed. The PR currently has Validation-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_FOUND for 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Area-Validation-PipelineIssues related to the manifest validation pipeline.Issue-BugIt either shouldn't be doing this or needs an investigation.

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions