Relevant area(s)
WinGet CLI
Description of the new feature / enhancement
Problem Statement
When an installer exits due to locked files (e.g. exit code 6 mapped to packageInUse or packageInUseByApplication in the manifest schema), WinGet outputs a localized message:
"The files modified by the installer are currently being used by another application. Please close the applications, then try again."
However, WinGet provides no visibility into which specific application or process is holding the lock.
In automated workflows, silent upgrades (-h / --silent), or scenarios involving shared DLLs/drivers, users are left completely in the dark.
Real-World Example
Upgrading OBSProject.OBSStudio from 32.2.1 to 32.2.2 silently fails with exit code 6 when an Electron/Chromium app (such as VS Code, Discord, Slack, or Antigravity) has loaded obs-virtualcam-module64.dll via DirectShow camera device enumeration. Even if the user closes OBS Studio itself, the lock remains held by an unrelated background process. Identifying the culprit currently requires manual inspection of process modules or handles.
User Value
Displaying the locking process names and PIDs allows users to immediately identify and close the conflicting application without guesswork, without running interactive installers, and without opening external tools like Process Explorer.
Proposed technical implementation details
Proposed Architecture
- Trigger Condition:
In AppInstallerCLICore (InstallFlow.cpp / ShellExecuteInstallerHandler.cpp), execute the detection flow only when an installer returns an exit code mapped to ReturnResponse::packageInUse or ReturnResponse::packageInUseByApplication (e.g. exit code 6).
- Process Enumeration via Windows Restart Manager:
Utilize the native Win32 Restart Manager API (rstrtmgr.h / rstrtmgr.dll):
- Call
RmStartSession to obtain a session handle.
- Register the target package install path or modified files via
RmRegisterResources.
- Call
RmGetList to obtain the array of RM_PROCESS_INFO structures (retrieving strAppName and Process.dwProcessId).
- Clean up with
RmEndSession.
- CLI Output Format:
Render the list of blocking processes directly in the error block:
The files modified by the installer are currently being used by another application:
- Antigravity (PID: 9468)
Please close these applications and try again.
Installer failed with exit code: '6'
Relevant area(s)
WinGet CLI
Description of the new feature / enhancement
Problem Statement
When an installer exits due to locked files (e.g. exit code 6 mapped to
packageInUseorpackageInUseByApplicationin the manifest schema), WinGet outputs a localized message:Real-World Example
Upgrading
OBSProject.OBSStudiofrom 32.2.1 to 32.2.2 silently fails with exit code 6 when an Electron/Chromium app (such as VS Code, Discord, Slack, or Antigravity) has loadedobs-virtualcam-module64.dllvia DirectShow camera device enumeration. Even if the user closes OBS Studio itself, the lock remains held by an unrelated background process. Identifying the culprit currently requires manual inspection of process modules or handles.User Value
Displaying the locking process names and PIDs allows users to immediately identify and close the conflicting application without guesswork, without running interactive installers, and without opening external tools like Process Explorer.
Proposed technical implementation details
Proposed Architecture
In
AppInstallerCLICore(InstallFlow.cpp/ShellExecuteInstallerHandler.cpp), execute the detection flow only when an installer returns an exit code mapped toReturnResponse::packageInUseorReturnResponse::packageInUseByApplication(e.g. exit code 6).Utilize the native Win32 Restart Manager API (
rstrtmgr.h/rstrtmgr.dll):RmStartSessionto obtain a session handle.RmRegisterResources.RmGetListto obtain the array ofRM_PROCESS_INFOstructures (retrievingstrAppNameandProcess.dwProcessId).RmEndSession.Render the list of blocking processes directly in the error block: