winget configure fails in limit mode: "Failed to open processor path ... Win32 error 1920" when dsc.exe is an app execution alias (1.29 regression)

[denelon]

Relevant area(s)

WinGet CLI, DSC Resource

Relevant command(s)

winget configure

Brief description of your issue

Starting with WinGet 1.29 (release candidate, v1.29.250), running winget configure against a configuration that uses the Microsoft.WinGet/Package DSC v3 resource fails before any unit is applied. The configuration set processor cannot be created because the new processor path integrity verification (introduced in #6193) fails to open the DSC v3 executable.

The DSC v3 executable that WinGet resolves is the app execution alias at:

C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\Microsoft.DesiredStateConfiguration_8wekyb3d8bbwe\dsc.exe

This is a zero-byte IO_REPARSE_TAG_APPEXECLINK reparse point (0x8000001b). It can be executed (dsc --version works and reports dsc 3.2.2), but it cannot be opened as a regular file — CreateFile without FILE_FLAG_OPEN_REPARSE_POINT returns Win32 error 1920 (ERROR_CANT_ACCESS_FILE).

In limit mode (self-elevation / remoting server), the isAlias flag is not making it through to ProcessorPathIntegrity.VerifyAndOpen, so the verification takes the regular-file branch instead of the alias branch and fails on the reparse point. The error message text in the log is the non-alias branch wording, confirming isAlias arrived as false.

The exact same configuration file succeeds on 1.28.240 (stable), which predates the integrity-verification feature and simply uses the alias path directly.

Root cause analysis

PR #6193 ("Configuration processor auditing improvements", merged 2026-05-14) introduced processor-path hash verification and the app-execution-alias handling. In limit mode the alias flag is propagated client → server as JSON:

• src/AppInstallerCLICore/ConfigurationDynamicRuntimeFactory.cpp only writes processorPathIsAlias into the metadata if the DscExecutablePathIsAlias factory-map value is present.
• src/ConfigurationRemotingServer/Program.cs reads it as ProcessorPathIsAlias ?? false.
• src/Microsoft.Management.Configuration.Processor/DSCv3/Helpers/ProcessorSettings.cs → EnsureProcessorPathVerified() calls VerifyAndOpen(path, hash, isAlias: DscExecutablePathIsAlias ?? false).
• src/Microsoft.Management.Configuration.Processor/DSCv3/Helpers/ProcessorPathIntegrity.cs → with isAlias == false, it calls CreateFile(GENERIC_READ, FILE_ATTRIBUTE_NORMAL) (no FILE_FLAG_OPEN_REPARSE_POINT), which returns 1920 on the APPEXECLINK reparse point.

When the auto-discovered DSC path is an app execution alias, the alias bit is not carried into the limit-mode metadata, so the server defaults to false and the regular-file open path is taken against a reparse point that cannot be opened that way.

Steps to reproduce

1. On WinGet 1.29.250, have DSC v3 installed as an MSIX (Microsoft.DesiredStateConfiguration 3.2.2.0), so that dsc.exe resolves to the WindowsApps app-execution-alias reparse point.
2. Use a configuration file whose unit uses the Microsoft.WinGet/Package DSC v3 resource (schema 0.3, processor: identifier: dscv3). Example: a foo.winget configuration file that installs a WinGet package requiring elevation.
3. Run:

   winget configure .\foo.winget --verbose-logs
   

Expected behavior

The configuration applies successfully, as it does on WinGet 1.28.240. The processor-path integrity verification should detect that dsc.exe is an app execution alias and open/hash it via the reparse-point branch (this is the case PR #6193 explicitly intended to support).

Actual behavior

The set processor cannot be created and every unit fails. With --verbose-logs:

<I> [CONF] The set processor factory is running in limit mode: True.
<V> [CONF] Creating set processor for ``...
<E> [CONF] System.InvalidOperationException: Failed to open processor path
   'C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\Microsoft.DesiredStateConfiguration_8wekyb3d8bbwe\dsc.exe': Win32 error 1920
   at Microsoft.Management.Configuration.Processor.DSCv3.Helpers.ProcessorPathIntegrity.VerifyAndOpen(String path, String expectedHash, Boolean isAlias)
   at Microsoft.Management.Configuration.Processor.DSCv3.Helpers.ProcessorSettings.EnsureProcessorPathVerified()
   at Microsoft.Management.Configuration.Processor.DSCv3.Helpers.ProcessorSettings.get_EffectiveDscExecutablePath()
   at Microsoft.Management.Configuration.Processor.DSCv3.Helpers.ProcessorSettings.ToString()
   at Microsoft.Management.Configuration.Processor.DSCv3ConfigurationSetProcessorFactory.CreateSetProcessorInternal(ConfigurationSet set, Boolean isLimitMode)
   at Microsoft.Management.Configuration.Processor.Factory.ConfigurationSetProcessorFactoryBase.CreateSetProcessor(ConfigurationSet incomingSet)
<E> [CONF] Configuration unit Microsoft.WinGet/Package[PowerShell7] failed with code 0x80131509 and error message:
The text associated with this error code could not be found.
<E> [CLI ] Terminating context: 0x8a15c005 at ...\Workflows\ConfigurationFlow.cpp:966

For comparison, on 1.28.240 the same file logs limit mode: False and ... done creating set processor. and proceeds normally.

Environment

Windows Package Manager v1.29.250
Windows: Windows.Desktop v10.0.26200.8655
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.29.250.0

DSC v3: Microsoft.DesiredStateConfiguration 3.2.2.0 (MSIX), Status: Ok
dsc.exe resolves to app execution alias (reparse tag 0x8000001b / IO_REPARSE_TAG_APPEXECLINK)

Working version for the same configuration file: WinGet 1.28.240
Likely culprit: PR #6193 (Configuration processor auditing improvements)