while upgrading vscode, Error: Cannot find module 'C:\Program Files\Microsoft VS Code\resources\app\out\cli.js'

[tamusjroyce]

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

• VS Code Version: 1.66.0 -> 1.66.2
• OS Version: Windows 10
  System-wide install

Steps to Reproduce:

1. Have a bunch of vscode's running
2. Maybe I installed a plugin while the upgrade is in progress?

Solution: Re-install vscode

note: Help: Start Extension Bisect results in a blank window as well

3rd or 4th time over a few years this has happened. Always during an upgrade.

This comes up a lot. And the work-around of reinstalled vscode is an easy fix. Most upgrades this works flawlessly. I will be sure to have just 1 vscode open when I upgrade next time.

[tamusjroyce]

Issue Type: Bug

I ran bisect while vscode failed installing. After reinstalling vscode, bicect opened & this is the output.
It said something about chis arcadia was the issue? mb an extension?

Reported here - #147763

Extension version: 1.3.8
VS Code version: Code 1.66.2 (dfd34e8, 2022-04-11T07:46:01.075Z)
OS version: Windows_NT x64 10.0.19042
Restricted Mode: No

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz (8 x 2112)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	15.86GB (2.76GB free)
Process Argv	--crash-reporter-id f198f09b-d0bf-4c3b-832a-d61863b2b492
Screen Reader	no
VM	0%

A/B Experiments

vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyl392:30443607
pythontb:30283811
pythonvspyt551cf:30345471
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30445986
pythondataviewer:30285071
vscod805cf:30301675
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
vsc1dst:30438360
pythonvs932:30410667
wslgetstarted:30449410
pythonvsnew555:30457759
vscscmwlcmt:30465135
cppdebugcf:30475217

Again. Feel free to close with no changes.

[joaomoreno]

Can you uninstall and reinstall VS Code?

[RussKie]

I get the same issue - VS Code fails to upgrade and essentially corrupts the existing install, leaving no option but to completely reinstall. This is the second time in the past 3 months alone.

My workstation is running for weeks without restarts. I also have multiple instances of VS and Code running for days (if not weeks). I am almost convinced that Code tries to sneakily and forcefully update itself in a background, and because I have running instances it fails and leaves me with a completely broken app.

[joaomoreno]

I also have multiple instances of VS and Code running for days

Do they share the same user data dir?

[RussKie]

Do they share the same user data dir?

No. I mentioned VS, because it often gets upset while updating itself and finding running Code instances (likely because of OmniSharp and dotnet). And that's when I sometimes find that Code install is corrupted (like happened yesterday).

[joaomoreno]

I meant: do the multiple instances of VS Code (not VS) share the same user data dir?

[RussKie]

I have a single installation of Code, installed via Chocolatey.

When I say "multiple instances" I mean multiple buttons on the task bar - because for me as a user these are different instances:

As far as the "process instances" - looks like the Code is run in a single process:

I do, however, occasionally run Code as "admin", and that often coincides with running the non-elevated instance. Whether both of these processes use the same user data dir - I have no idea.
Though now thinking about it, it may be that the elevated process instance tries to update itself on exit, and that screws the running non-elevated instance up.

[joaomoreno]

Though now thinking about it, it may be that the elevated process instance tries to update itself on exit, and that screws the running non-elevated instance up.

It's definitely possible. 🤔 We might want to disable update in sessions started as Admin, when in the user setup. What do you think?

[RussKie]

Sounds like a good plan 👍

[joaomoreno]

Created #148428

[tamusjroyce]

Admin mode wasn't in play for me. I think my situation was purely installing extensions while vscode was updating. Could disabling extensions while the update happens be a solution?

Oh. Well. System level access is required for the update, isn't it? maybe it was. And the other windows wouldn't have been elevated. Hm. Good callout @RussKie!

And yes, re-install did fix it. I installed it again via system-level installer.

[joaomoreno]

@tamusjroyce I'd still be interested in whether re-installing the user install would also fix it for you. System level access isn't required for that one.

[benallred]

We might want to disable update in sessions started as Admin, when in the user setup. What do you think?

@joaomoreno: Just thought I should mention that running VS Code as admin is what enabled my VS Code to actually update in a user setup. #147408 (comment)