Hi,
Just following up on this topic, which was covered in August 2020 here (https://patchmypc.com/forum/index.php?topic=3940.0). Since this thread, the app has been added to the list (https://patchmypc.com/manage-conflicting-processes-when-updating-third-party-applications) 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.
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.
Hey Adam, sure. Here you go.
Hey, that's not PatchMyPC-ScriptRunner.log. Do you have PatchMyPC-ScriptRunner.log?
Also, what extensions are installed?
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.
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
QuoteThanks 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
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.
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.
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
If (error 5) {
Start-Sleep -Seconds 30
Try to kill code.exe again
If (good) {
Try to update again
}
}
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:
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.
QuoteIf 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.
Out of curiosity, do you have this option set in your Manage conflicting processes window for VSCode?
Yes, we do.
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.
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 (https://github.com/microsoft/vscode/issues/47841)
Hi Andrew,
Yes, it's definitely an issue with the VS Code installer. The question was really how or if we could work around it in an automated way. The pre-script idea is great, I just haven't had a chance to implement it yet. I'll report back when I do!
Hi, sorry to resurrect this post, but this continues to be an on-going issue for our organization. I myself just got a new laptop and I'm already facing this issue with every update to VS Code.
Something I did notice, even though we have "Auto-close conflicting application process before installation", I see a /NOCLOSEAPPLICATION switch in the installer command, which seems strange. Please find the VS Code install log and the PatchMyPC script runner log entries from Jan 13.
I've just done some testing and have not been able to reproduce this so far.
With Manage Conflicting Processes enabled, the app is closed and the update succeeds.
If MCP is set to ignore the running app and proceed, then the installer fails quickly before attempting to install.
It doesn't make sense to have /NOCLOSEAPPLICATIONS though, so we'll remove this from the default command line as it seems it could conflict with the other option on offer /FORCECLOSEAPPLICATIONS.
I also tested with /FORCECLOSEAPPLICATIONS /LOGCLOSEAPPLICATIONS though, and that did force close anything either.
Thanks, any estimate on when the parameter changes will go in?
Myself and other users again got this error with the latest update. Is there anything you want me to do for diagnostics the next time we see the error?
Can you also let me know the behavior of the "Skip installation when conflicting processes are in use" option? I couldn't find any documentation on this.
VS Code is one of those apps that is often running any time the PC is in use, so if this option only checks to see if the process is running during a software update cycle, it will likely be skipped forever. But if it somehow will wait until the moment the process is no longer running, such as after a reboot, this might be a good solution.
Sorry this change did not go in, I'll push to get it in today's release.
Skip means it will exit and not try to update. It will retry whenever WSUS / ConfigMgr / Intune (whatever is deploying it) decides to do so - we cannot indefinitely snooze updates since that would block other updates from running and also be subject to a timeout. Here is the a post on this:
https://patchmypc.com/manage-conflicting-processes-when-updating-third-party-applications
And the docs for Patch My PC Cloud:
https://docs.patchmypc.com/installation-guides/patch-my-pc-cloud/deployments/deploy-an-app/configurations#conflicting-process