Repository navigation
I'm struggling to understand the cause(s) of "wminet_utils.dll"-related errors in the pipeline. #326285
Description
Among the affected PRs:
- New package：Microsoft.DotNet.Runtime.2_2 version 2.2.8.28209 #324922 (comment)
- New package：Microsoft.DirectX.Mesh version 2025.10.28.1 #325936 (comment)
- OBSProject.OBSStudio: Add portable installers for x64 and arm #320323
- New version: liule.Snipaste version 2.11.2 #322996 (comment)
- New version: ImageMagick.Q16 version 7.1.2.11 #323044
- Update libvips.libvips version 8.18.0 #324760
- New version: MaaAssistantArknights.MaaAssistantArknights version 6.0.0 #322308
- Added ARM32：Microsoft.DotNet.AspNetCore.3_1 version 3.1.32 #328442
- New package: DavidSungaila.SoundReaver version 1.0.6.0 #322361
The error message in question:
Failure to parse win 10, attempting win 11
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'.
Executable C:\Users\Validator\AppData\Local\Microsoft\WinGet\Packages\Microsoft.DotNet.Runtime.2_2__DefaultSource\dotnet.exe returned exit code: -2147450751
In the case of the first 2 PRs, I presumed that adding Microsoft.DotNet.Framework.DeveloperPack_4 as a package dependency would fix it, but apparently it doesn't. So that leaves me unsure as to whether it's a client-side dependency problem, or if the .dll error is on the pipeline VMs' part?
Reacted by RC Chuah
Activity
UnownPlain commentedon Dec 25, 2025
That error shows up on all arm64 validations so it's probably a pipeline issue. It doesn't cause the run to fail so you should ignore them.
evilbananas commentedon Dec 25, 2025
Most things just need the .NET Framework RUNTIMES that already come packaged with the latest versions of windows.
I would be surprised if you really needed the DEVELOPER pack. I would not be adding
Microsoft.DotNet.Framework.DeveloperPack_4unless you are absolutely sure it is needed.DandelionSprout commentedon Dec 25, 2025
(To UnownPlain) Good to know.
(To evilbananas) I predicted that kind of situation and thus made #325400, but ironically that PR itself is struggling, since fresh stock installs of W11 will have it silently fail to install.
evilbananas commentedon Dec 25, 2025
I could see #325400 creating a couple of issues which is probably why it isn't currently in the repo.
1.) People will install it unnecessarily
For most users, it is already included as part of their Windows installation. Because winget does not register its presence, users will assume they don’t have it and install this package needlessly. It just creates confusion as to what users have on their system.
2.) Manifests will include it as a dependency when it’s not needed
If it is added, I expect an influx of manifests—especially from new contributors—declaring it as a dependency without realizing it’s already part of Windows. I think it will just create more maintenance work for contributors in the future having to remove unneeded dependencies.
Maybe I'm missing something though and others have a different view on this.
summoning-sudo commentedon Dec 26, 2025
UnownPlain commentedon Dec 26, 2025
The cause of Validation-Executable-ErrorPost-install executable validation returned an unexpected result; review is required.
is due to one of the executables returning a non-zero exit code.
DandelionSprout commentedon Jan 10, 2026
So… what's the plan? Should all packages affected by the
wminet_utils.dllbug be manually tagged and/or treated the same way asValidation-Completedpackages, and could thus be considered ready for merging?DandelionSprout commentedon Jan 15, 2026
After some weeks of me trying all sorts of things to get #325400 to pass validation, I eventually got it to get "Validation-Completed" after I made the package ARM64-only. Since it's after all ARM64 that is the sole arch affected by it, then the package will work as planned nevertheless once it gets merged.
DandelionSprout commentedon Jan 17, 2026
So eventually it was able to get merged, and so began the task of seeing if this would work for stuck packages:
As of at the time of writing, this fix has a success rate of hardly even 25%, leaving the question still lingering in the air of what to do with the rest. Surely the pipelines can be adjusted server-side so that any errors involving failing to load
wminet_utils.dllget tagged by pipelines as "Validation-Completed" instead of "Validation-Executable-Error"… or?UnownPlain commentedon Jan 17, 2026
Validation-Executable-Error happens because one of the executable installed returns a non-zero exit code when run. It's a common error for CLI programs to have since most of them return an error when run with no arguments. It probably isn't related to the
wminet_utils.dllerror you're seeing.DandelionSprout commentedon Jan 17, 2026
You probably have a good point. And since I've certainly done my best to try out and/or eliminate various possible causes, "The pipelines struggle to handle non-zero exit codes" is among the more likely ones remaining.
This, in my eyes personally, makes it more important than ever that the pipelines' auto-taggings should become more accurate when it comes to situations that involve such non-zero exit codes.
UnownPlain commentedon Jan 17, 2026
#157749
dlemstra commentedon Jan 19, 2026
In our case the problem looks like the "Installation Validation" tries to execute our arm64 executable on an x64 host? But I am unable to find the code of the azure function that is being used.
DandelionSprout commentedon Jan 19, 2026
Wouldn't surprise me at this point, and you're probably onto something.
DandelionSprout commentedon Mar 25, 2026
It seems to me that the glitch has got almost wholly fixed by now… although mostly because #323120 surpassed it in severity.
DandelionSprout commentedon Jun 29, 2026
It has certainly become a problem again in general.
DandelionSprout commentedon Jul 2, 2026
Almost certainly related, so I'll link to it so I myself in particular won't forget about it or something like that: