Visual Studio Code updates still failing with auto-close

[Jared]

Hi,

Just following up on this topic, which was covered in August 2020 here.  Since this thread, the app has been added to the list of recommended applications to automatically close.

We've enabled auto-close, but we're still getting reports of the error described in the original thread.  I saw it on my own system yesterday with the update to 1.58.2.  When I went to manually reinstall the app, setup continued to complain that five instances of Visual Studio Code were still running.  I tried to use the Automatically close the applications option in setup, but this failed.  I had to manually kill all five instances of code.exe before setup would continue.  Perhaps a similar force-quit needs to be coded into the VS Code update?  It doesn't seem like Microsoft is going to be fixing this any time soon.

[Adam Cook (Patch My PC)]

Could you share PatchMyPC-ScriptRunner.log from when the update tried to install and failed? I'm curious to know if we see any dialogue in there about the other code.exe processes failing to be killed off.

[Jared]

Hey Adam, sure.  Here you go.

[Adam Cook (Patch My PC)]

Hey, that's not PatchMyPC-ScriptRunner.log. Do you have PatchMyPC-ScriptRunner.log?

Also, what extensions are installed?

[Jared]

Sorry, just noticed that wasn't the file you asked for, haha.  Here you go.

The PowerShell extension, the Remote WSL extension, and then three themes.

[Adam Cook (Patch My PC)]

From the other forum post you linked, did you try the suggestion at the bottom of GitHub issue 47841?

https://github.com/microsoft/vscode/issues/47841

Thanks for all the info guys, will continue investigating this. Meanwhile, I'll lock this thread so everyone sees this:

If you're having this issue constantly, disable background updates with

"update.enableWindowsBackgroundUpdates": false

[Jared]

I did see that, but I didn't make the change because I generally like to run my apps in roughly the same configuration as a typical user.  I would consider this a workaround, and it's not something we could easily manage on the scale of thousands of endpoints.

[Adam Cook (Patch My PC)]

I agree, it is not ideal and it is a workaround. Unfortunately we're at the mercy of vendors' software and we have no control if bugs (re)surfaces in their software.

Perhaps you could use ConfigMgr or Intune to orchestrate the config on a subset of devices that experienced the issue? You could use a Configuration Item in ConfigMgr or Proactive Remediation script in Intune.

[Jared]

It nearly seems random, and the volume of issues appears to be relatively low.  But if enough people complain we may have to do that.

I'm still curious as to why the command to stop code.exe is failing with access denied when running as admin.  I was able to stop it manually.  Is there a way I can modify the update execution?  I would like to try and introduce something similar to this:

EDIT:  Code change

Code Select Expand

If (error 5) {
  Start-Sleep -Seconds 30
  Try to kill code.exe again
  If (good) {
    Try to update again
  }
}

[Adam Cook (Patch My PC)]

I would imagine it's failing to kill the process maybe for the same reason the update is failing - just guessing, largely because it's the same error code / message.

You could probably do a pre-script (configurable via right click option), more info here: https://patchmypc.com/custom-options-available-for-third-party-updates-and-applications#custom-scripts

You wouldn't be able to discern the logic like that in a post-script as you can't access that error code 5 like that as a parameter or environment variable, unless you parsed the PatchMyPC-ScriptRunner.log. Perhaps as a pre-script, something like:

Code Select Expand

if (code.exe is running) {
  Start-Sleep -Seconds 30
  Try to kill code.exe again
}

If code.exe is still running by the time it gets to the pre-script, then you know it didn't close properly by the "manage conflicting processes" workflow.

[Jared]

If code.exe is still running by the time it gets to the pre-script, then you know it didn't close properly by the "manage conflicting processes" workflow.

Great info, thanks!  I'll probably give this a try.

[Adam Cook (Patch My PC)]

Out of curiosity, do you have this option set in your Manage conflicting processes window for VSCode?

[Jared]

Yes, we do.

[Adam Cook (Patch My PC)]

OK thanks. I thought maybe that might have been interfering but I just had a discussion internally with the development team and that wouldn't interfere: while that feature could prevent code.exe from starting again during the update's install (and sometimes produce access denied errors if you try to launch the process), the blocks on the processes are applied after we attempt to force close processes.

[Andrew Jimenez (Patch My PC)]

Hi Jared,

I do wonder if this is an issue with the VSCode installer itself. There is a long-standing issue on the github that sounds exactly like this problem: https://github.com/microsoft/vscode/issues/47841