Redirecting here is good to raise awareness. But ultimately, it forces everyone to scroll through the comments to figure out why they landed here.

A better UX would be to:

• allow VSCode to update in background - this means 1) do not nag me on every instance, every time whether I want to update or not. 2) do not require admin permissions to do so.
• upgrade vscode the next time it restarts silently (maybe make it configurable)

When in doubt, follow Chrome’s auto-update behavior.

Please do not let VSCode become the next Adobe Flash. 🙏

Microsoftee brilliance at work yet again F* this

I had the same problem and disabled MalwareBytes as a user suggested earlier. This solved it for me. After some testing around I found MalwareBytes Ransomware protection to be the cause of the issue for me. Tested with 1.25.0 Insiders but maybe it could help on other versions, too. Hopefully, this is the same issue as I have not been able to delete or modify the VSCode executable itself after running the update.

Ever since I switched to the user-based installation this is now happening to me ever since. vscode is incapable of updating itself now, always claiming it cannot access Code.exe.

What I have noticed though (whenever I remember to check) is that the System process (pid 4) has a lock on Code.exe which remains locked even when vscode and the udpater exit. I can’t even delete the file by hand at this point. Occasionally new locks are added within System when the update process attempts to run again. Needless to say when that happens not even the manually downloaded installer can do anything until I restart the machine.

Guys, I’m taking a different approach to updating Code in the background especially wrt deleting the old version.

The current implementation tries to delete the old version, and if it gets stuck in a file/folder it keeps retrying until it succeeds. If it never succeeds, due to an antivirus program or any other reason, it just throws its hands up and gives up. This leaves a broken installation behind. Not great.

The new implementation will first attempt to get exclusive handles on all the files to be deleted. Once all handles are acquired, it promptly deletes the files; this should succeed since the handles are exclusive. Once that’s done, all folders get deleted. Then, the update is applied. This will not prevent the background update from not working due to antivirus, etc… but (1) it should reduce the chances of that happening and (2) it prevents broken installations, which seems crucial by now.

https://github.com/Microsoft/inno-updater/compare/45c9716c81d93f54f982fff765261b59bea072f2...01e696d2edb43b64271aea113e1d6b97a68b2467

---

I’ll keep the issue open since I don’t have a reproducible case. We’ll close it eventually if issues stop coming in and/or if people confirm that this helps their setup.

Disabling Malwarebytes while running installer worked for me

Introduction

This is also happening to me. Ever since I installed the User-specific version of Insiders starting with 1.26.0. I finally got fed up with it and uninstalled it and then fresh installed 1.27.0. I know that 1.28.0 is out, but I’m still having the same issues.

System Information

Anti-Virus Information

I am using Trend Micro Maximum Security anti-virus. I am using Folder Shield (which protects against ransomware), BUT the installation directory where VS Code Insiders resides is NOT protected by Folder Shield. (And, I’ve turned Folder Shield off to make sure that this is not causing an issue.) I also completely exited Trend Micro Maximum Security in an attempt to have the update succeed–no dice.

Video Card

I am running a laptop system with dual Nvidia GeForce 680M video cards running the latest available drivers. (I just installed the latest driver today–I was two versions behind. The same behavior of installation occurred with the old driver as it does with the new driver.) Why do I mention video card? Because I know, especially for Nvidia, how intrusive some of its programs are–adding a “filter driver” type driver entries that operate even on the level of folders and files throughout all of Windows Explorer which seeming have nothing to do with graphics… I have no idea why they register their software so deeply into the system for things which seem to have nothing to do with graphics display. (But, I’m not a video driver programmer–so what do I know?)

My Recent Findings

There seem to be two scenarios that can happen. So let’s take them one at a time.

Updating from Within Visual Studio Code - Insiders

When attempting to update from within Visual Studio Code - Insiders, I get the Error dialog many others have gotten, with the message:

C:\Users\<my_user_name>\AppData\Local\Programs\Microsoft VS Code Insiders\tools\inno_updater.exe

An error occurred while trying to replace the existing file: DeleteFailed; code 32.
The process cannot access the file because it is being used by another process.

I used ProcessExplorer and searched the open handles on my system. It turns out that the SYSTEM process (pid 4) has an open, exclusive handle to this file. Attempting to close the handle via ProcessExplorer results in another error message from ProcessExplorer: Error opening process: The handle is invalid. (Even though I opened ProcessExplorer as an elevated process, it’s likely I still wouldn’t have the rights to close a handle opened by SYSTEM, not sure, but that’s the only reason I could think of other than the obvious reason stated by the error message; but if I’ve learned anything using Windows over the last 30 years is that error messages don’t always tell you the whole story.)

Rebooting the Machine and Attempting an Upgrade via a Download of the New Installer

This, too, didn’t work. In this case, the installer showed the same error dialog, but this time for Code - Insiders.exe. And, like for inno_updater.exe, the SYSTEM process (pid 4) is holding a lock on this file (and several others if you’re patient enough to click Skip on each such occurrence of the error). In order to attempt to resolve this issue, I took the drastic steps of:

1. Navigate to the installation location of Visual Studio Code - Insiders in my user directory
2. Remove all inherited folder permissions on the installation directory and copying the inherited permissions an explicit permissions granted at this folder location. (Note, this covers the location of inno_updater.exe, too.)
3. Changed the SYSTEM account’s access to the folder from Allow, Full Control to Deny, Full Control
4. Reboot.

This did not work. (NOTE: looking in ProcessExplorer, the SYSTEM process runs under the context of NT AUTHORITY\SYSTEM, which is why I sought to deny access to the VS Code Insiders location.)

So, the only way I can get an updated copy of Visual Studio Code - Insiders to install is to:

1. Uninstall Visual Studio Code - Insiders from Apps & Features. Uninstallation “succeeds”, but I get a dialog that says that some files could not be deleted and that I would need to remove them manually. That makes sense given various files have locks on them by the SYSTEM process.
2. Reboot the computer. Since after the reboot VS Code Insiders is not technically installed anymore, the SYSTEM process does not open handles to those files after the reboot.
3. Delete the remaining installation files left behind after uninstalling.
4. Install the updated Visual Studio Code - Insiders build.

I don’t know that my log file is going to tell you anything more useful than anyone else’s. All attempts to prevent/circumvent the file handles opened by the SYSTEM process have been unsuccessful. I’ll do some Bing’ing to see if anyone else has a method of preventing SYSTEM from opening handles on certain files. One thing I haven’t tried–and maybe I’ll do that real quick after submitting this comment–is disabling my anti-virus software’s Windows Service and rebooting. I’m not sure that that would work, however, as I do have it loaded as part of the Boot process to protect my computer even before Windows is fully up and running. But I’ll try anyway and report back.

Similar problem; similar solution – in case it helps someone:

Neither in-Code updates nor exe download worked for me under normal or elevated UAC. ESET turned out to be the culprit. Installs without issue when real-time protection is fully disabled.

[ Win10x64, Dell Inspiron 7000 ]

I tried with the insider build (1.26) but the update failed. However, I too have MalwareBytes installed and, according to their forum, their ransomware protection appears to cause this kind of problems for many users with various applications. https://forums.malwarebytes.com/topic/229748-mb-3512522-prevents-some-programs-updating/ As I have recently experienced problems with updating other programs in addition to VS Code, I believe that my problems are not due to any flaw in VS Code.

@joaomoreno , I was getting the same error

Access denied os error(5)

When i was trying to update vs code insiders , but after reading the this whole thread I disabled the malwarebytes protection software on my PC completely , and Voila , the update completed super smooth. I think these protection softwares are the root cause behind this update error.

I’m also having this exact same issue. I need to download the new installer from the website, reboot, and install it first thing for it to succeed. This was the issue I posted weeks ago: https://github.com/Microsoft/vscode/issues/58743#issue-360564253

I had a bit of an epiphany on Friday. I had installed the Vivaldi browser on both my work and home computers. By default, the Vivaldi browser also gets installed into the %userprofile%\AppData\Local folder. On my work PC, I have no problems updating the browser. But on my home PC, the updates always fail due to—can you guess?—locked files! Locked by the SYSTEM process. The same exact reason that updates to the user installations of VS Code and VS Code Insiders fail.

One thing that’s worth checking out is what installer technology is being used by Vivaldi. Is the installer technology the same as that being used by VS Code? If so, then maybe it’s something specific to the installer.

Ruling out any installer issues with respect to the installation location, it would seem most likely that this issue is machine-specific, I’m sorry to report, because for the life of me I’m unable to determine why this particular machine is behaving in such a manner.

I have the same issue for the latest release.

Sep 14 06:21:27.768 ERRO Failed to create file handle: The process cannot access the file because it is being used by another process.

OK, so I disabled the Trend Micro Solution Platform service and rebooted. I opened Visual Studio Code - Insiders and checked for updates and then clicked Restart to install updates. No dice. 😞 I got the following error dialog:

Failed to install VS Code update.

Updates may fail due to anti-virus software and/or runaway processes. Please try restarting your machine before attempting to update again.

If update fails repeatedly, please attach the following log file to a new issue on GitHub[.]

Looking at the log file, even though I performed the update process starting from within VS Code Insiders, it appears that the failure was as a result of being unable to obtain a lock on Code - Insiders.exe (again, because, SYSTEM is holding open a handle on this file). So, my “two scenarios” listed above are a little incorrect in that it’s not based on where/how an update is performed, but only on which files are trying to be updated. In most cases (>90%), Code - Insiders.exe is trying to be replaced. In some smaller amount of cases, it’s inno_updater.exe which is trying to be replaced. I would venture that we should forget about inno_updater.exe for the moment and focus only on Code - Insiders.exe. Also, it’s likely that determining the reason for one would also determine the reason for the other.

I’ll post my log file (only changing my username in the logfile), but again, I don’t think it’ll be all that helpful. The most reliable method to updating VS Code User installation is the 4 step method I posted above: Uninstall, Reboot, Delete leftover files, Install new version. Ugh. What a pain.

I think for now I’ll go back to a machine-wide installation. I never had issues with that. Hopefully, you guys will be able to figure this out; it sounds like it’s been a tricky bugger to get to the bottom of. Let me know if there’s anything else I can provide to aid in your efforts, as the User install does seem to be a better installation option for this type of program.

vscode-inno-updater-1536435075.log

This is still happening to me. vscode-inno-updater-1536343392.log

I’ve been getting this too just as I switch to the user install. I used information I learned by having the same issue with the Twitch program and checked the System process (PID4) and sure enough, there it was; open file handle for Code.exe. Just have no idea WHY this happens. (Yes yes, something about system taking over the handle for another program when ‘something’ happens. Just no idea what program and why it needs to have an open file handle on the exe.)

…never managed to get past this stage with Twitch either.

but VS Code - Insiders still functions

That’s it 👍

I started with version 1.27.0-insider. VS Code prompted for an update. The update eventually failed. Screenshots and log file should be attached. vscode-inno-updater-1535724318.log

I tested the new update with a locked file and it behaved nicely and the installation was kept intact. However a locked directory makes the installation still fail. You can lock a directory easily by opening a Windows Command prompt (cmd.exe) on it.

@joaomoreno I would look into adding Handle (from the ever resourceful Mark Russinovitch) to the VSCode package and use it in the updater in case of failure to create a log that explains why the file is still locked, and who is locking it. This might give a clue and point to the real culprit.

I am happy to try this locally since I can readily reproduce the problem, however I haven’t looked into what is required to make a custom VSCode build from source.

I don’t have malwarebytes and I also have this error:

Failed to install VS Code update. Please download and reinstall VS Code. Please attach the following log file to a new issue on GitHub:

C:\Users\beabri01\AppData\Local\Temp\vscode-inno-updater.log

You might want to try the new Windows User Setup available from version 1.25. You will be redirected to a link which provides more information:

https://aka.ms/vscode-update-access-denied

vscode-inno-updater.log

vscode-inno-updater-normal.log vscode-inno-updater-insider.log

I had a problem to update to the latest version just now. Also had the same problem with the previous update. I also tried to install the insider version, still had the update problem. I have malwarebytes installed as some others said above.

Edit: https://forums.malwarebytes.com/topic/229748-mb-3512522-prevents-some-programs-updating/?page=2&tab=comments#comment-1255633

There’s a new update on MalwareBytes just today that is supposed to fix the issue with ransomware protection preventing update on programs.

@daditangs I can’t say anything for Mac OS but on Linux the internal updater is not really used. Most applications are centrally managed using a package manager and at least on ArchLinux it is used for VSCode, too.

I got something else for you to try out today. I just pushed user installable Windows setup packages to our build pipeline. This should let you install VS Code without administrator privileges, in your LOCALAPPDATA folder while keeping those nice background updates.

So, I ask you this:

1. Install the Insiders User Setup: https://vscode-update.azurewebsites.net/latest/win32-x64-user/insider
2. Make sure it runs fine.
3. Similarly to the suggestion above, open the %localappdata%\Programs\Microsoft VS Code\resources\app\product.json and change the commit field to outdated.
4. Restart Code, an update should happen

Does the update succeed in this setup? If so, please give it a few more retries just to make sure it succeeds consistently. If not, hit me up with the log file so I can take a look.

Thanks, looking forward for the experiment results 🤓

@marcelomgarcia, sorry if my comments confused you. What I I meant is that I had the error constantly (I could not update from 1.24.0 to 1.24.1), and in the process of investigating possible causes, the problem just stopped occurring despite no configuration changes on my part. My PC is still managed by my organization, even though we have Admin-level accounts.

It seems that if you keep retrying, eventually you will succeed. This probably means it is a subtle timing problem in the upgrade process, which occurs more often for some people than others.

@joaomoreno, I managed to reproduce the problem again while writing this comment (I think this proves the bug is indeed random!), this time adding more bits to the Process Monitor log. You can find it here.

Interestingly, I see now there are multiple attempts at deleting the file (is this new from 1.24.1?), all of them fail, but there are also several BUFFER OVERFLOW errors:

Hope this helps.

Interesting detail: as I tried to test other cases, the 1.24.1 update actually succeeded, so it seems this is a somewhat random problem. I wanted to check if another process was somehow keeping a handle on the old Code.exe (antivirus or whatever).

I tried to force another update by changing the commit field in C:\Program Files\Microsoft VS Code\resources\app\product.json but that did not help, the update succeeded again. Hopefully the information I posted before will be helpful, as it seems I cannot reproduce the issue anymore.

@joaomoreno, C:\\Program Files\\Microsoft VS Code\\Code.exe exists when the error occurs.

I ran the update with Process Monitor opened, figuring it might give another clue to the failure:

I have saved the entire log (filtered by the strings “code” and “updater” in the process names), you can get it here.

I am happy to try other things if you want.

On a related note: the dialog box for this error is shown under the progress window, but maybe that should be reported separately. It is not always apparent that the error occurred since only the progress window is topmost (the error dialog is not).

Having the same issue since 1.24.0, both on my work PC and my home PC. Getting the same Access Denied errors for Code.exe as the original poster. Manually downloading the update and applying it worked for 1.24.0, but I am reporting this now instead of ignoring it like last time, so I did not try to manually update to 1.24.1.

Jun 14 08:44:21.961 INFO Starting: C:\Program Files\Microsoft VS Code\Code.exe, false
Jun 14 08:44:21.966 INFO Checking for running Code.exe processes... (attempt 1)
Jun 14 08:44:21.972 INFO Code.exe is running, wait a bit
Jun 14 08:44:22.472 INFO Checking for running Code.exe processes... (attempt 2)
Jun 14 08:44:22.487 INFO Code.exe is running, wait a bit
Jun 14 08:44:22.987 INFO Checking for running Code.exe processes... (attempt 3)
Jun 14 08:44:23.001 INFO Code.exe is running, wait a bit
Jun 14 08:44:23.501 INFO Checking for running Code.exe processes... (attempt 4)
Jun 14 08:44:23.515 INFO Code.exe is not running
Jun 14 08:44:23.515 INFO Checking for possible conflicting running processes... (attempt 1)
Jun 14 08:44:23.529 INFO Inno Updater v0.4.3
Jun 14 08:44:23.530 INFO Starting update, silent = false
Jun 14 08:44:23.589 INFO do_update: "C:\\Program Files\\Microsoft VS Code\\Code.exe", _
Jun 14 08:44:23.589 INFO move_update: "C:\\Program Files\\Microsoft VS Code\\unins000.dat", _
Jun 14 08:44:23.590 INFO Delete: "Code.exe" (attempt 1)
Jun 14 08:44:23.641 INFO Delete: "Code.exe" (attempt 2)
Jun 14 08:44:23.842 INFO Delete: "Code.exe" (attempt 3)
Jun 14 08:44:24.292 INFO Delete: "Code.exe" (attempt 4)
Jun 14 08:44:25.093 INFO Delete: "Code.exe" (attempt 5)
Jun 14 08:44:26.344 INFO Delete: "Code.exe" (attempt 6)
Jun 14 08:44:28.145 INFO Delete: "Code.exe" (attempt 7)
Jun 14 08:44:30.595 INFO Delete: "Code.exe" (attempt 8)
Jun 14 08:44:33.796 INFO Delete: "Code.exe" (attempt 9)
Jun 14 08:44:37.848 INFO Delete: "Code.exe" (attempt 10)
Jun 14 08:44:42.848 INFO Delete: "Code.exe" (attempt 11)
Jun 14 08:44:42.849 ERRO Access is denied. (os error 5)

I can run Process Hacker however when the bug occurs, and following the procedure from this comment, I can see there are no Code.exe processes running when the error dialog is shown.

In case the command lines are important, here they are, in order:

C:\Users\bmiller\AppData\Local\Temp\vscode-update-x64\CodeSetup-stable-24f62626b222e9a8313213fb64b10d741a326288.exe /verysilent /update="C:\Users\bmiller\AppData\Local\Temp\vscode-update-x64\CodeSetup-stable-24f62626b222e9a8313213fb64b10d741a326288.flag" /nocloseapplications /mergetasks=runcode,!desktopicon,!quicklaunchicon

"C:\Users\bmiller\AppData\Local\Temp\is-UDDQA.tmp\CodeSetup-stable-24f62626b222e9a8313213fb64b10d741a326288.tmp" /SL5="$7322B2,45792428,159232,C:\Users\bmiller\AppData\Local\Temp\vscode-update-x64\CodeSetup-stable-24f62626b222e9a8313213fb64b10d741a326288.exe" /verysilent /update="C:\Users\bmiller\AppData\Local\Temp\vscode-update-x64\CodeSetup-stable-24f62626b222e9a8313213fb64b10d741a326288.flag" /nocloseapplications /mergetasks=runcode,!desktopicon,!quicklaunchicon

"C:\Users\bmiller\AppData\Local\Temp\vscode-update-x64\CodeSetup-stable-24f62626b222e9a8313213fb64b10d741a326288.exe" /SPAWNWND=$1221CC /NOTIFYWND=$7322B2 /verysilent /update="C:\Users\bmiller\AppData\Local\Temp\vscode-update-x64\CodeSetup-stable-24f62626b222e9a8313213fb64b10d741a326288.flag" /nocloseapplications /mergetasks=runcode,!desktopicon,!quicklaunchicon

"C:\Users\bmiller\AppData\Local\Temp\is-CVUNE.tmp\CodeSetup-stable-24f62626b222e9a8313213fb64b10d741a326288.tmp" /SL5="$480A92,45792428,159232,C:\Users\bmiller\AppData\Local\Temp\vscode-update-x64\CodeSetup-stable-24f62626b222e9a8313213fb64b10d741a326288.exe" /SPAWNWND=$1221CC /NOTIFYWND=$7322B2 /verysilent /update="C:\Users\bmiller\AppData\Local\Temp\vscode-update-x64\CodeSetup-stable-24f62626b222e9a8313213fb64b10d741a326288.flag" /nocloseapplications /mergetasks=runcode,!desktopicon,!quicklaunchicon

"C:\Program Files\Microsoft VS Code\tools\inno_updater.exe" "C:\Program Files\Microsoft VS Code\Code.exe" false

Let me know if you need anything else, I can reproduce this at will.

I’ve had this problem since 1.22.2 (trying to upgrade to 1.23). I’m in a corporate environment with a bunch of security stuff installed and have had the same issues with:

...
10:21:48.097 INFO Delete: "Code.exe" (attempt 11)
Jun 14 10:21:48.097 ERRO Access is denied. (os error 5)

As an additional data point, I tried setting update.enableWindowsBackgroundUpdates to false, which launched the installer when updating from within the client. However this also failed to update Code.exe with an access denied error. Manually downloading the installer (1.24.1) and launching it worked.

You can still use the old update mechanism with the following setting:

"update.enableWindowsBackgroundUpdates": false

Though it would be pretty cool if we could make the background updates work on your machines… I would need some more feedback, like what I mentioned above in https://github.com/Microsoft/vscode/issues/47841#issuecomment-393101777

Oh man, sorry about that. It’s in resources\app. I’ve updated the original post.

Though I have no idea what changed, I’m actually no longer able to reproduce this. If it shows back up I’ll let you know, but I’m not using Insiders on my work machine anymore - mostly because of this bug (I didn’t want to get as many update notifications that I couldn’t do anything about).

I installed Insiders 1.23.0 and successfully updated to 1.24.0.

Same issue that was originally reported here with the most recent update as well. So, had this issue on 1.22 and again now on 1.23. Be kind of annoying if I have to uninstall and download to get the latest features. Definitely a work related only issue though, can update on my personal easily. Probably good old McAfee locking everything down in the registries with some unique rule.

This is a puzzle to me, because we know Code isn’t running… so why can’t the updater remove Code… unless it is really running?

---

@ryanolsonx @gitDylanHub @OfficerHalf @SwingCoder911

Can you run this little app I’ve created, while Code is running? rust-playground.zip

It will output all running process numbers and names. Something like this:

Does Code appear in that list, for you? Can you show me the output of the app in your system?