Terminate COM surrogate process before update/gc

[dmitrivMS]

Fixes #294546
Fixes #295844
Fixes #312098
Fixes #290467
Fixes #313585

The fix for the mutex race is necessary since under locking conditions uninstall of AppX package may take some time and we are restarting the app by that time, but setup is still running.

I was able to repro this on 1.118.1 with FreeCommander XE 32-bit.
Verified the fix with both user and system setup/update.

Co-authored-by: Copilot copilot@github.com

[dmitrivMS]

Insiders pipeline: https://dev.azure.com/monacotools/Monaco/_build/results?buildId=435635&view=results

[Copilot]

Pull request overview

Addresses Windows update runs that never complete by proactively terminating the File Explorer context-menu COM surrogate (dllhost.exe /Processid:<CLSID>) that can hold file handles and block inno_updater --gc cleanup (issue #294546).

Changes:

• Add a Win32 update-service step to stop the context-menu COM surrogate before invoking inno_updater --gc.
• Add an Inno Setup helper to stop the same COM surrogate before AppX removal and before --gc cleanup.
• Introduce win32ContextMenu product configuration and wire its CLSID into the Win32 setup build definitions.

Show a summary per file

File	Description
src/vs/platform/update/electron-main/updateService.win32.ts	Runs a PowerShell-based kill step for the context-menu COM surrogate before background-update GC.
src/vs/base/common/product.ts	Adds win32ContextMenu to product configuration typing.
build/win32/code.iss	Adds KillContextMenuComSurrogate() and invokes it prior to AppX removal and GC.
build/gulpfile.vscode.win32.ts	Passes FileExplorerContextMenuCLSID define to Inno Setup when available from product metadata.

Copilot's findings

Comments suppressed due to low confidence (1)

src/vs/platform/update/electron-main/updateService.win32.ts:206

• The exit handler logs at info level regardless of whether PowerShell succeeded. If code is non-zero, this should be treated as a failure (warn/error) so we don’t silently miss the cleanup step; conversely a 0 exit could be logged at trace to reduce log noise.

				}).once('exit', code => {
					this.logService.info(`update#killContextMenuComSurrogate: powershell exited with code ${code}`);
					resolve();

• Files reviewed: 4/4 changed files
• Comments generated: 2

[Copilot]

Copilot's findings

• Files reviewed: 5/5 changed files
• Comments generated: 2

[dmitrivMS]

Pipeline with latest builds: https://dev.azure.com/monacotools/Monaco/_build/results?buildId=435734&view=results

[github-actions]

Screenshot Changes

Base: 88fa3d91 Current: 2ee3ea4c

Changed (26)

chat/input/chatInput/Default/Dark

Before	After

chat/input/chatInput/Default/Light

Before	After

chat/input/chatInput/WithFileChanges/Dark

Before	After

chat/input/chatInput/WithFileChanges/Light

Before	After

chat/input/chatInput/WithTodos/Dark

Before	After

chat/input/chatInput/WithTodos/Light

Before	After

chat/input/chatInput/WithTodosAndFileChanges/Light

Before	After

chat/input/chatInput/WithArtifactsAndFileChanges/Dark

Before	After

chat/input/chatInput/WithArtifactsAndFileChanges/Light

Before	After

chat/input/chatInput/Full/Dark

Before	After

chat/input/chatInput/Full/Light

Before	After

chat/widget/chatWidget/PendingToolApproval/Dark

Before	After

chat/widget/chatWidget/PendingToolApproval/Light

Before	After

chat/widget/chatWidget/MultiTurn/Light

Before	After

agentSessionsViewer/CompletedRead/Dark

Before	After

agentSessionsViewer/CompletedRead/Light

Before	After

agentSessionsViewer/FailedWithoutDuration/Dark

Before	After

agentSessionsViewer/FailedWithoutDuration/Light

Before	After

agentSessionsViewer/WithFileChangesList/Dark

Before	After

agentSessionsViewer/WithFileChangesList/Light

Before	After

agentSessionsViewer/WithBadgeAndDiff/Dark

Before	After

agentSessionsViewer/WithBadgeAndDiff/Light

Before	After

agentSessionsViewer/BackgroundProvider/Dark

Before	After

agentSessionsViewer/BackgroundProvider/Light

Before	After

agentSessionsViewer/ClaudeProvider/Dark

Before	After

agentSessionsViewer/ClaudeProvider/Light

Before	After

[deepak1556]

Could we just run this at RemoveAppxPackage which is more definitive point in time where we want the old appx package to be removed, this step always runs during update flow. I don't see why we also need to call it before gc.

[dmitrivMS]

Could we just run this at RemoveAppxPackage which is more definitive point in time where we want the old appx package to be removed, this step always runs during update flow. I don't see why we also need to call it before gc.

For background update for a user setup we run --gc from from UpdateService - by that time the file can be locked again. There are other scenarios and even when we do and there is a wait, the file can be locked again - so we would be blocked.

[deepak1556]

by that time the file can be locked again.

Why would that be, we have unregistered the appx corresponding to the old version if anything is running at the time of gc it should be from the new version which gc will not even touch in the first place. Could you share steps that demonstrate the issue of old dll holding up process after removing the appx package ?