Update detects code.exe instances from other users with seperate install folders

[w0otness]

Two users on the same Windows machine each with their own version of VS Code installed in different folders.
Both users run VS Code, the update now button is pressed by one user and that user closes his VS Code to finish update.
Error message pops up saying that VS Code is still running, although all instances of that user's VS Code are terminated.
Confirmed that the each user's instances all originate from their own user's install folder.

Expected Results:
Users in multiple user environment with separate install folders can update normally, by checking only for running instances of code.exe that originate from the respective install location.

[runely]

Is there any progress on this? Is there an ETA for when this will be fixed?

[FSharpCSharp]

The problem still exists, and it is also still annoying. Especially in connection with terminal server installations, it makes the daily work very unpleasant, because there are a lot of updates, and that always leads to this conflict. It is a pity that Microsoft has not developed a solution for this for 2 years now.

[GeoMarkou]

Copying from my duplicate issue: (#128266)

This is quite annoying as I need to close/reopen VSCode multiple times in a day, and this happens every time I close VSCode. It also blocks me from opening VSCode until it finishes failing to update. I recommend that this either fails silently, or only try once per day. I don't think interrupting my coworkers to close their IDE is a good solution.

[GeoMarkou]

I was able to work around this issue with the setting from the following documentation, but I set it to "manual": https://code.visualstudio.com/docs/supporting/FAQ#_how-do-i-opt-out-of-vs-code-autoupdates

To modify the update mode, go to File > Preferences > Settings (macOS: Code > Preferences > Settings), search for update mode and change the setting to none.

If you use the JSON editor for your settings, add the following line:
"update.mode": "none"

[conioh]

Just got bitten by this.

Almost 4 years¹ and it just sits there in the backlog.

If fixing it is too hard for you because you don't how to differentiate between different processes with the same name², you can and should just remove the check altogether. Then it will only fail if the files are actually in use and then you can show an error message. Being so eager to fail that you fail when there's actually no error is pretty bad.

¹ How did I get to "almost 4 years" and not just 3 years? Well, that's because this was actually reported earlier in #60625 and closed with #60625 (comment):

I'd say that's a pretty good workaround for RDP environments: disable background updates.

² For example, using QueryFullProcessImageName, or whatever. The updater is not open-source so I can't see what you're doing and suggest a specific fix.

[conioh]

This issue was incredibly difficult to find, and similar issues are difficult to find too, because everyone who reports it specifies a different part of the error message. So to improve this issue's visibility:

---------------------------
Visual Studio Code
---------------------------
There was an error while attempting to kill any running Code.exe processes:

Failed to open process: Access is denied.


Please verify there are no Visual Studio Code processes still executing.
---------------------------
Retry   Cancel   
---------------------------