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

[jefferson3813]

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.

[jefferson3813]

Additional investigation:

I captured the failure with Sysinternals Process Monitor.

The SHARING VIOLATION occurs during file operations performed by winget.exe
inside %TEMP%\WinGet.

The downloaded installer remains under its SHA256 filename after WinGet exits.
Immediately after WinGet exits, I can manually rename the exact same file
without any sharing violation.

This may also be related to #6232, which describes a similar post-download /
post-hash failure where the downloaded file remains under its SHA256 filename
and rolling back WinGet resolves the issue.

The main differences in my case are:

• this happens with the standard public winget source;
• multiple unrelated packages are affected;
• WinGet reports 0x80070020 / ERROR_SHARING_VIOLATION;
• the failure occurs in Filesystem.cpp(1376);
• downgrading from 1.29.360 to 1.29.280 fixes the issue immediately on the same machine.

I am keeping WinGet 1.29.280 installed for now as a workaround.

[jefferson3813]

Additional A/B test:

After the manual rollback to 1.29.280, Microsoft.DesktopAppInstaller / WinGet
was automatically restored to version 1.29.290.

I then repeated an upgrade test on the same machine.

Result:

winget --version
v1.29.290

Installer hash successfully verified
Starting package install...
Successfully installed

So the regression window can be narrowed further:
WinGet 1.29.280: works
WinGet 1.29.290: works
WinGet 1.29.360: fails with 0x80070020 after hash verification

This suggests the regression was introduced between 1.29.290 and 1.29.360.