VS Code tried to update itself and deleted `resources/app/out`; no longer starts and broke my existing open sessions

[sandersaares]

Does this issue occur when all extensions are disabled?: Unknown

Version: 1.91.1 (system setup)
Commit: f1e16e1
Date: 2024-07-09T22:06:49.809Z
Electron: 29.4.0
ElectronBuildId: 9728852
Chromium: 122.0.6261.156
Node.js: 20.9.0
V8: 12.2.281.27-electron.0
OS: Windows_NT x64 10.0.22631

Steps to Reproduce:

1. Wait for a VS Code update to be automatically installed at 12:00 on an arbitrary day (I do not know how/why/when exactly this occurs).
2. Observe that any open VS Code window suddenly becomes nonfunctional - many button presses do nothing, tasks fail to launch.
3. Observe that VS Code logs (e.g. user settings sync log) complain about missing .js files.
4. Observe that starting new VS Code instances fails with the below error message.

Error: Cannot find module 'C:\Program Files\Microsoft VS Code\resources\app\out\main'
    at Module._resolveFilename (node:internal/modules/cjs/loader:1055:15)
    at s._resolveFilename (node:electron/js2c/browser_init:2:115690)
    at node:electron/js2c/browser_init:2:121111
    at node:electron/js2c/browser_init:2:121360
    at node:electron/js2c/browser_init:2:121364
    at BuiltinModule.compileForInternalLoader (node:internal/bootstrap/realm:392:7)
    at BuiltinModule.compileForPublicLoader (node:internal/bootstrap/realm:328:10)
    at loadBuiltinModule (node:internal/modules/helpers:68:7)
    at Module._load (node:internal/modules/cjs/loader:923:17)
    at c._load (node:electron/js2c/node_init:2:13672)

Has happened twice so far (last time about a month ago, presumably with previous update).

VS code main.log has the following on recent startup before the event:

2024-08-02 07:04:09.468 [info] update#setState idle
2024-08-02 07:04:39.476 [info] update#setState checking for updates
2024-08-02 07:04:39.480 [info] update#setState downloading
2024-08-02 07:04:39.481 [info] update#setState downloaded 

The Application event log has some RestartManager entries at the time when the problem started:

1. Starting session 0 - ‎2024‎-‎08‎-‎02T09:00:39.339256800Z.
2. Application 'C:\Program Files\Microsoft VS Code\Code.exe' (pid 8852) cannot be restarted - Application SID does not match Conductor SID.. (repeated with different PIDs)
3. Machine restart is required.
4. Ending session 0 started ‎2024‎-‎08‎-‎02T09:00:39.339256800Z.

Next to the vanished resources/app/out directory is a directory resources/app/node_modules.asar.unpacked whose timestamp matches the event in the Application event log.

I surmise that VS Code tried to update itself but somehow messed up and left me with a broken installation. I will reinstall since I need to continue my work but I have made copies of relevant folders in case there may be something valuable in there (I was not able to find any other relevant logs, though).

[sandersaares]

Happened again just 2 minutes ago, again at local noon 12:00 exactly.

[jepio]

Same here - but I only experience this in Dev Box.

[Abe27342]

I encounter this relatively regularly on my machine. I have VS Code installed at the system level to leverage it on multiple profiles (personal, work).

Perhaps some hits of this issue are related to system-level installations requiring elevation to update, which is documented here? I have never seen the elevation prompt mentioned:

The in-product update flow will also require elevation, making it less streamlined than the user setup. On the other hand, installing VS Code using the system setup means that it will be available to all users in the system.

before encountering this issue.

If there's any diagnostics/settings I can enable to help improve the experience here, please let me know.

[mikekistler]

Just happened to me too:

[raych1]

It happens to me every day on Microsoft dev box. I have to back up the Microsoft VS Code\resources\app\out folder for recovering to avoid re-installing VSCODE to resolve this issue.

Seems I have to disable the automatic update for VSCODE.

[Francis-Liu]

This happens to me in my Dev Box. Every time when I closed VS Code and open again, this error popped out. I have to reinstall VS Code to fix it. I have changed the C:\Program Files\Microsoft VS Code\resources\app\out folder to read-only. I haven't verified if this would prevent it from being deleted.

[mrek-msft]

Happens on my (physical) machine as well. I run ProcMon for two days and captured deletion of main.js file. It looks like deletion is done by some autoupdate tool downloaded to temp folder, but later deleted itself, so I do not have access to it.

Operations done to delete file:

Stack trace of deletion event:

All four events (open, query attribuges, delete, close) go through the same DeleteFileW call from VSCodeSetup-x64-1.95.3.tmp + 0x1f77f0 but I do not have symbols.

Two seconds before deletion I have Application SID does not match Conductor SID.. warning events in Applications event log as described in opening post.

I suspect that it relates to using system installer instead of user installer.

[sandersaares]

I have managed to identify the root cause: the VS Code installer fails to detect that a system-installed VS Code is open in another session and corrupts the installation because some open files (such as Code.exe) are locked. The rollback procedure in the installer does not appear to be correctly implemented, so while the log claims that it performs a rollback after hitting the locked file, the installation is left in a corrupted state.

For me these conditions are triggered because VS Code is installed via WinGet as a system-scoped package.

WinGet has automatic update logic that operates independently of VS Code's own automatic update logic. Once per day, it attempts to upgrade all installed WinGet packages. This update process runs under both each user's session and in a SYSTEM session, to update both user-scoped and system-scoped packages, presumably.

When VS Code is open in a user session and the user-scoped WinGet updater starts the VS Code installer, the installer correctly detects that VS Code is open and refuses to upgrade. This is fine - the upgrade will be retried the next day by WinGet or performed by VS Code itself.

When VS Code is open in a user session and the SYSTEM session attempts an upgrade, the VS Code installer fails to detect that VS Code is open in a different session (presumably, whatever mechanism it uses can only inspect the current session). It starts an upgrade install, which fails part way through because some files (e.g. Code.exe) are locked and in use. This results in a corrupted installation.

Attaching log file of a failed install that led to the problem described herein: WinGet-Microsoft.VisualStudioCode.1.95.3-2024-11-15-09-25-40.649.log