winget hangs indefinitely after "Starting:" — installer process is never created (no prefetch entry, no child process); a control package on the same machine installs fine

[thefrederiksen]

Relevant area(s)

Installer behaviour / install

Brief description of your issue

winget install --manifest logs Starting: '<installer>' with arguments '<args>' and then waits forever. The installer process is never created — no child process, no Windows Prefetch entry, and (for a self-contained .NET single-file installer) no %TEMP%\.net extraction directory. winget never times out and never reports an error.

A control package installed through the identical local-manifest path on the same machine, minutes apart, works normally. The same installer binary, launched by hand from winget's own temp path with winget's own Mark of the Web still applied, runs in 3.4 seconds.

Steps to reproduce

1. Clean Windows 11 25H2 machine (restored from a snapshot before each run), user is a local administrator.
2. winget settings --enable LocalManifestFiles from an elevated process.
3. Local manifest, schema 1.6.0, InstallerType: exe, Scope: user, installer served from a GitHub release asset over HTTPS, with InstallerSwitches.Silent.
4. winget install --manifest <dir> --accept-package-agreements --accept-source-agreements

Last lines of the winget log — download and hash verification both succeed:

[CORE] Download completed.
[CORE] Started applying motw to ...\c8172a76... with zone: 3
[CORE] Finished applying motw
[CLI ] Installer hash verified
[CLI ] Successfully renamed downloaded installer. Path: ...\devthrottle-setup-cli-win-x64.exe
[CORE] Started applying motw using IAttachmentExecute to ...\devthrottle-setup-cli-win-x64.exe
[CORE] Finished applying motw using IAttachmentExecute. Result: 0 IAttachmentExecute::Save() result: 0
[REPO] Reading MSI UpgradeCodes
[CLI ] Installer args: install --role workstation
[CLI ] Starting: '...\devthrottle-setup-cli-win-x64.exe' with arguments 'install --role workstation'

Nothing further is ever logged.

Expected behavior

Either the installer process starts, or winget reports that it could not be started and exits non-zero.

Actual behavior

winget waits indefinitely and the installer never runs. Observed 20+ minutes after Starting::

• Get-Process — no installer process; winget still running, ~1.6 s CPU, idle
• Get-CimInstance Win32_Process -Filter "ParentProcessId = <winget pid>" — no children
• C:\Windows\Prefetch — no entry for the installer, so it never executed
• %TEMP%\.net — no extraction directory (this installer is a self-contained single-file app and creates one on startup)
• The installer writes its own log on startup; no log was created

What has been ruled out, each measured on the same clean machine:

Hypothesis	Test	Result
The installer binary is broken	Launched by hand with winget's exact arguments	Installed fully in 176 s
winget's temp path is the problem	Ran the binary in place from winget's own temp directory	Ran in 3.4 s
Mark of the Web blocks it	Same binary launched non-interactively, mark on vs mark off	Both ran
Something holds the file open	Exclusive File.Open on the installer	Succeeds — nothing holds it
Our install logic hangs	Replaced the silent switch with version (prints one line, exits)	Also never starts
PE subsystem (console vs GUI)	Repeated with a GUI-subsystem installer from the same publisher	Also never starts
winget local-manifest install is broken here	Control: Python 3.14.7 through the same local-manifest flow	Installed in 54 s, exit code 0

So the bytes, the path, the Mark of the Web, file locking, the install logic, and winget's local-manifest mechanism are all fine on this machine. Two installers from one publisher fail; a third party's succeeds.

What is different about the failing binaries: both are signed by a code-signing identity that is new — about two months of history through Microsoft Trusted Signing, with low download volume — and both are large self-contained .NET single-file executables (79 MB and 145 MB). The working control is a 33 MB installer from a long-established publisher.

That raises a question I cannot answer from outside: does the launch path consult application reputation, and if so, can an unrecognised binary cause process creation to stall rather than fail?

Two suggestions, independent of root cause:

1. Time out the wait for process creation and report an error. Today this produces a hang that looks unkillable, with nothing in the log after Starting:.
2. Log the result of the process-creation call — the Win32 error, or the new process id on success. Starting: is currently the last line written whether the process was created or not, which makes this class of failure invisible.

Happy to supply the failing package, full logs, or run further tests on the clean snapshot — it reproduces on demand.

Environment

winget v1.29.290  (Microsoft.DesktopAppInstaller_1.29.289.0_x64__8wekyb3d8bbwe)
Windows 11 Pro 25H2, build 26200.8037 (clean install, snapshot-restored per run)
Hyper-V guest; Smart App Control in Evaluation mode; Defender real-time protection on
User is a local administrator; LocalManifestFiles enabled from an elevated process