[Regression 1.29.360] winget upgrade fails after hash verification with 0x80070020 in Filesystem.cpp(1376), works on 1.29.280

Relevant area(s)

WinGet CLI

Relevant command(s)

winget upgrade

Brief description of your issue

After Microsoft.DesktopAppInstaller / WinGet was updated to version 1.29.360, all package upgrades started failing with error 0x80070020:

"The process cannot access the file because it is being used by another process."

The failure occurs after the installer has been downloaded successfully and its SHA256 hash has been verified.

The WinGet verbose log shows the failure in:

AppInstallerSharedLib\Filesystem.cpp(1376)

I reproduced the issue with multiple unrelated packages, including:

• GIMP.GIMP.3
• KiCad.KiCad
• ShiningLight.OpenSSL.Light
• Nvidia.PhysX
• PointPlanck.FileBot
• Microsoft.VisualStudioCode
• OpenWhisperSystems.Signal
• astral-sh.uv
• Microsoft.DotNet.DesktopRuntime.10

I also forced WinGet to use WinINet instead of Delivery Optimization. The problem still occurred.

I then downgraded Microsoft.DesktopAppInstaller from 1.29.360.0 to 1.29.280.0 on the same Windows installation.

Without changing anything else, the exact same command:

winget upgrade --id astral-sh.uv --verbose-logs

succeeded immediately on WinGet 1.29.280.

This strongly suggests a regression introduced between WinGet 1.29.280 and 1.29.360.

Steps to reproduce

1. Install/update Microsoft.DesktopAppInstaller to version 1.29.360.0.

2. Confirm:

   winget --version

   Result:

   v1.29.360

3. Clear WinGet temporary files:

   Remove-Item "$env:TEMP\WinGet" -Recurse -Force -ErrorAction SilentlyContinue

4. Run:

   winget upgrade --id astral-sh.uv --verbose-logs

5. The package downloads successfully and its hash is verified.

6. WinGet fails with:

   0x80070020 The process cannot access the file because it is being used by another process.

7. The verbose log contains:

   Installer hash verified

   [FAIL] C:__w\1\s\external\pkg\src\AppInstallerSharedLib\Filesystem.cpp(1376)\WindowsPackageManager.dll 80070020 The process cannot access the file because it is being used by another process.

8. Downgrade Microsoft.DesktopAppInstaller to 1.29.280.0.

9. Confirm:

   winget --version

   Result:

   v1.29.280

10. Clear %TEMP%\WinGet again.

11. Run the exact same command:

    winget upgrade --id astral-sh.uv --verbose-logs

12. The installation succeeds:

    Archive extraction successful Starting package install... Command line alias added: "uvx" Command line alias added: "uv" Command line alias added: "uvw" Successfully installed

Expected behavior

After the installer has been downloaded and its SHA256 hash has been successfully verified, WinGet should continue with extraction/renaming and installation.

Updating WinGet from 1.29.280 to 1.29.360 should not cause package upgrades to fail with a temporary file sharing violation.

Actual behavior

With WinGet 1.29.360, package upgrades consistently fail immediately after installer hash verification with:

0x80070020 The process cannot access the file because it is being used by another process.

Example from GIMP:

WinINet downloading from url: https://download.gimp.org/gimp/v3.2/windows/gimp-3.2.6-setup.exe

Download hash: 9337cccbc01d4098ee7a3dab215b3afbe6ece99c5287c92441d6f12cf541ebca

Download completed. Installer hash verified

[FAIL] C:__w\1\s\external\pkg\src\AppInstallerSharedLib\Filesystem.cpp(1376)\WindowsPackageManager.dll 80070020 The process cannot access the file because it is being used by another process.

After WinGet exits, the downloaded file remains in %TEMP%\WinGet under its SHA256 hash filename.

I can manually rename that file immediately after WinGet exits without any sharing violation.

A Process Monitor trace was also captured during reproduction.

Environment

Failing version:

Windows Package Manager v1.29.360
Microsoft.DesktopAppInstaller v1.29.360.0

Working version after downgrade:

Windows Package Manager v1.29.280
Microsoft.DesktopAppInstaller v1.29.280.0

Windows:

Windows.Desktop v10.0.19045.7725

System Architecture:

X64

Downloader test:

network.downloader = wininet

The issue reproduces with WinINet and is therefore not specific to Delivery Optimization.