Code change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No unable to start container without extensions enabled <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Version: 1.60.0-insider (user setup) Commit: Date: 2021-08-16T05:21:19.431Z Electron: 13.1.8 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: WindowsNT x64 10.0. OS Version: Steps to Reproduce: VSCode Insiders Edition on Windows Insider gives error every time when logging in to GitHub and other sites 'writing login information to the keychain failed with error 'not enough memory resources are available to process this command'. Also, have set up ssh, but still requires web authentication for extensions every time I open VSCode. It gives the error, but then continues to login after the error and does not save login information. after opening VSCode insiders login to github error and does not save login information tested on current VSCode and doesn't require login every time and no issues with memory (working) Version: 1.59.0 (system setup) Commit: Date: 2021-08-04T23:13:12.822Z Electron: 13.1.7 Chrome: 91.0.4472.124 14.16.0 V8: 9.1.269.36-electron.0 OS: WindowsNT x64 10.0. Regular Edition does not give the error and I do not have to login to github everytime the app starts.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.528 --- <!-- score: 0.528 --- <!-- score: 0.452 --<!-- potentialduplicatescomment --
! did not fix the issue Snapshot of the error message: !
!
there was an issue with the last insiders build. Can you update to the latest one and let us know if you're still seeing this?
Thank you. I installed the update, but unfortunately, it is still doing it. I did a full memory diagnostic and it did not find any issues with memory, and there is plenty of it available. Version: 1.60.0-insider (user setup) Commit: Date: 2021-08-19T05:15:46.693Z Electron: 13.1.8 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. ! !
!
Just updated again. Issue remains. Thank you. Version: 1.60.0-insider (user setup) Commit: Date: 2021-08-20T17:51:50.560Z Electron: 13.1.8 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. !
This is likely an issue with the library we use for storing secrets called but it's impossible for me to reproduce... so it'll be hard for me to make progress here.
+1 I am now getting this issue on my laptop Where can I find logs or what information do you need that would assist in resolving the issue?
Hey did you manage to fix this? Same problem..
Third that Same issue also...
I am also getting the same issue as well, both trying to sign in with my Microsoft Account for Settings Sync and with GitHub for Settings Sync, GitLens, or LiveShare. Visual Studio 2022 is also having problems connecting to GitHub, and since the new connection successful screen doesn't display the token information, I cannot even connect it manually.
do you see this only when using a Remote SSH/Remote Container connection? Your original video that it was a Remote connection. To the others in the thread, do you also experience this when using Remote?
I see it when using the Accounts -Sign In commands in the bottom left. Whether I use it to sign in to use Settings Sync or LiveShare (with either Microsoft Account or GitHub), or using GitHub for GitLens. I now get the token information with the instructions: Copy the token. Switch back to VS code. Click Signing in to in the status bar. Paste the token and hit enter.5. But, there is no "Signing in to " in the status bar, just the error message noted.
Are you using a Remote? Like Remote SSH, Remote WSL, Remote Containers?
no, just launching VS Code and attempting to sign in. Seems to be a problem with saving the token on the redirect.
I solved this by changing my pagefile settings by doing: System Properties -Advanced -Performance -Advanced -Virtual Memory -Change -uncheck 'Automatically manage paging file size for all drives' -check 'System managed size' -OK -Reboot edit: I'm not sure why the pagefile would affect it though. I have 128GB of RAM.
Thank you , that seems to have fixed it for me as well.
Thanks a lot it worked for me
Sadly, this did not work for me and I share the doubt about how a page file setting can affect this. I even tried it with the paging file completely disabled. Any other ideas?
if you have nodejs installed, you can run this simple one-liner to see if the problem is how your keychain is setup: or if you're on Insiders: This is using the following open source package: What you should get is something like this: If that succeeds, then the problem is possibly in vscode. If that does complain, then we'll need a fix in keytar itself.
I can try this tomorrow.
Hi Tyler, I understand that you can't reproduce the problem, making it hard for you to investigate. I'm happy to try to help. I am on Windows 11 if that makes a difference. Also, on a completely separate Windows 10 desktop right next to me I do not have the problem. I ran the test you suggested and I got back the expected response for github authentication. However, my difficulties are with microsoft authentication. So I changed the command to look for . I got back 100 account/password pairs. 98 of them had in the account field, for example: (Some digits changed in case they are sensitive) The account fields for the other two were and The password fields look quite different from the one retrurned by github. Something like: Probably the most important thing is that only the password returned with the account looks exactly like the one returned by github, sort of like SSH keys. The formats are the same, the digits are just different. So, if I had to guess it looks like the caller of this function is getting back a lot more data than expected and/or needs to filter it to get only the account.
thanks for giving that a try. The content of is different than GitHub. It has a different secret storage schema (that I could get into ... but lets call it as it is "legacy reasons") Anyway, the fact that the script I suggested worked fine, but VS Code fails leads me to believe that this might have something to do with Electron and how is loaded into that. Let me chat with on this to see if he has anything thoughts
I have a different problem. When I dumped my keychain, I have 123 entries in it so "not enough resources is probably not surprising. I wonder whether these accumulate over time and then the problem arises. Usually, I am asked to re-authenticate once a couple of weeks so it would take a while before they accumulate. I will remove them now so I can use my shit.
For my normal VSCode (which I stopped using since we last tacked this problem), i have the following targets: So probably this is how it looks "in the making". Should I clean that up as well or leave it for testing?
FWIW, I've worked around the problem by deleting all the credentials of the form: where "xxx" at the end is some random-looking decimal number. After restarting and reauthenticating, several subsequent restarts of VSCode did not require re-authentication and the number of credentials of the above form holds steady.
Yes, me too. I am guessing it will slowly grow as tokens expire. The library that gave does not have functionality to delete, so that is probably what is causing this.
I found the same thing; in my case it was a whole bunch of credentials placed there by Adobe Creative Cloud that were taking up all the space. Once I completely cleared out the Windows Credential Store, I was able to get both VS Code and Visual Studio to correctly connect to GitHub again. Get Outlook for iOS From: Vladislav Kosev Tuesday, July 12, 2022 10:37:40 AM To: microsoft/vscode Pierre Plourde Comment Re: [microsoft/vscode] error logging in 'writing login information to the keychain failed with error 'not enough memory resources are available to process this command' () Yes, me too. I am guessing it will slowly grow as tokens expire. The library that does not have functionality to delete, so that is probably what is causing this. — Reply to this email directly, view it on GitHub, or unsubscribe You are receiving this because you commented.Message ID:
That process for keychain setup worked for me, I got the result expected. So what does that mean for vscode? A bug? Every time I restart VSCode or even reload the window, I have to login again for CoPilot and Settings Sync - I use the Github login. Using MacOS Monterrey.
I had the same issue - too many credentials (Windows 11: Start Credential Manager Windows Credentials). Mine included an obscene number of vscode entries, as noted above, so I deleted them all with a powershell line I cobbled together through Google: . It still threw the error so I hand-pruned most of the remaining entries and it took. Good luck! (FWIW, Win 11, 8GB RAM + 24GB Page File) !
I think this one is more likely the cause. Because after I deleted all the credentials in the credential manager, it still automatically logs me out. There is no out of resource error for me. It may be the syncing issue leads to duplicated credential creation.
For the folks that have cleared the large list of credentials in their credential manager... can you please check to see if that number is increasing again? My suspicion is that some of you got into a bad state around the time that I was making heavy changes in this space... but now that that has settled, vscode's code isn't polluting the cred store anymore... This is coming from my lack of reproduction of the issue even though I've tried numerous ways to do it. With that said, users could still get into this bad state though, if they use other applications that use the keychain (like someone mentioned with Adobe products). For this case, we should at the very least include docs in the troubleshooting keychain issues here:
Hi Tyler, I have not had any failures along the lines of the original problem (needing to login each time vscode is started) since I cleared the credentials back in July. Today, I see only about 5 hits from the command you posted. And I think I saw about the same number when I checked at some point between July and now. I tend to agree with your suspicion.
"Target" is localized. Need to chcp 437 first. I now clear my credentials and will try to reproduce.
Thanks I'll update my regex
updated mine and I'm updating your quote so that no one gets confused
Based on confirmation, I will optimistically close this issue once the doc PR goes in... however, if you still see the problem of VS Code's credentials growing an unreasonable amount, please don't hesitate to reach out.
One other thing I tried is a minimal Electron repro where I created 1000 secrets to see if I could reproduce it... I could not. For those that wanna assist in getting to the true root of the problem, I've documented a potential repro here: If you can reproduce the error mentioned in this issue using my Gist, please let me know so we can let the Electron team know. In any case, I'll still close this once goes in.
I have confirmed that once there are too many credentials, the Windows call fails with . This issue doesn't have to do with Electron or Node.
Given this, the best we can do is document that workaround which is done now. Thanks for the investigation
Hi , may I ask how to list the credential? And what's the upper limit? I don't think my box have "too many credentials". But it still hit this issue. Thanks
, isn't it possible to remove the expired credentials automatically? It doesn't seem normal that you must delete credentials by yourself. There is not even a command that does it, you need excel/PowerShell to do it.
We're still blocked by the issue. May anyone please suggest a workaround? Thanks.
see to get the list of credentials.
Thanks, . This is my observation: ! I notice tons of credential created by VS code. To me, the bug seems: vs code incorrectly wrote tons of credentials to Windows, which causes the "not enough memory resources" issue. This is not a Windows issue but a vscode issue. Any thoughts? Thanks CC (, who seems the PM to me)
I think that the working assumption is that there was a temporary problem in VS code that generated the entries in the Credential Manager. See the explanation in this in this same issue thread. You might try deleting those entries in your Credential Manager and make sure you have the latest revision of VS Code. I did exactly that back in July and it worked. I see that at least some of your entries are in or before that timeframe.
Thanks. . I ran Then the issue is gone. I disagree with this statement: I have confirmed that once there are too many credentials, the Windows call CredWrite fails with ERRORNOTENOUGHMEMORY. This issue doesn't have to do with Electron or Node. Again, to me, the bug seems: vs code incorrectly wrote tons of credentials to Windows, which causes the "not enough memory resources" issue. This is not a Windows issue but a vscode issue.
It's a Windows issue because it could be caused by other programs too. See Adding a command to clear credentials sounds like a separate feature request to me. Edit: Actually, if a bunch of credentials are still being incorrectly written even with VS Code version 1.71, that's a VS Code bug.
Hi , are you saying it's by design that VS code creates tons of the credentials? IMO, once vscode creates ton of credentials, it's by design that Windows OS prompts OOM. I read, in different way: both adobe/vscode should not create tons of credentials. It's their bugs to create tons of credentials.
I cleared my credentials back in July and haven't seen any evidence that "VS code creates tons of credentials". Right now, I have 5 that refer to "" user IDs and I suspect that has to do with my Microsoft account history. Tyler said that was a long story and has to do with legacy/older systems. I think I tried to explain before that Tyler suspected that there was some bad code in one of the releases of VS Code that caused the creation of these credentials. This would have probably been in the timeframe of the first half of this year. But apparently, that problem is no longer in current builds of VS Code. So you may be right that it is a VS Code bug, but it appears to be one that is fixed, at least according to my observations.
Thanks, . I think the issue still exists. 2 days ago, I have deleted all extra vscode credential using, cmdkey /list ForEach-Object { /delete $_.Matches.Groups[1].Value } But today, login failed again. Then I observed that vscode creates a bunch of credential again, which does not sounds expected to me. ! , do you have any idea? Thanks
This is why I asked if anyone was seeing the large quantities of vscode secrets after clearing out their secrets. And why I used the phrase "optimistically close" . You've provided new information with that last message and you've confirmed that there's some scenario where this still happens. With that said can you please supply: if you're using a Microsoft account or work or school account (if multiple, tell me about all of them) how many windows of vscode you typically have open give me the full text of one of these keys (don't worry it's only public data)
Thanks if you're using a Microsoft account or work or school account (if multiple, tell me about all of them) -Only hotmail account. etc, how many windows of vscode you typically have open -3 instance. But I use a python script to open them give me the full text of one of these keys (don't worry it's only public data) -Where to find these text?
Hey just jumping on this as per the comment in . I have just performed the credential manager clean out as per the command line in and my multiple VSCode windows are now all signed in, and persist across Exit's and re-open. There were 178 entries for the specific pattern on my machine. Edit: With things now working, there are 22 entries. I will keep an eye on things, and will post back here later on. For initial context: Windows Account 5 windows open at all times; 4 are folders/workspaces, and 1 is general files and unsaved instances
I've started experiencing the issue that appears to be mentioned in (but has now been merged into this ticket), but it appears that VSCode is correctly(?) reading my credentials from Seahorse (on Ubuntu) but still asks me to sign in every time I want to start or join a Live Share session. I've tried clearing out all the relevant credentials from Seahorse, and that (as expected) asks me to reauthenticate with my Microsoft account, but then continues to ask me to sign in whenever I start a new session. From Output Microsoft Authentication, everything seems to look fine to me - it finds two(?) stored sessions and seems to refresh the token fine... :shrug: Details about VS Code and my OS: In addition: It's a Microsoft work account () Usually only one or two, depending on the project. However, Live Share appears to open one window initially (that I have to click 'sign in' on) then opens a separate window (which I also have to sign in on) From Seahorse, I assume it's this bit you need? If you need to know anything else, don't hesitate to ask :+1:
Just chiming in here. I just used the hint with deleting all the credentials for vscode. I had like 100+ of them. After that I signed in to settings sync using my Microsoft account. No more memory error on save. And after restarting vscode it signed me in automatically again.
I have the hardest time reproducing this issue... for those of you that do see it, can you do me a favor and: the Credential Manager open on the side what you normally do (open multiple windows, just use VS Code) to see if you can notice when the number of credentials increases and let me know if there's a particular action that causes it I'll continue to try reproducing this...
Thank for continuing to try. Current it seems to not happen anymore or it happens very infrequently. In credential manager I have: 1 github token 8 tokens - 4 from yesterday and 4 from 30.08.2022. Not sure why 4. 5 numbered from 0 to 3 + one keylist.
those "8 tokens" are in the form right? Can you share them here? And if you don't want to can you at least tell me what's different about them? My guess is just a guid at the end...
Yes, there they are. Interestingly enough They were 4 pairs Two of the pairs are modified today (so they are somehow active, because the date changed from yesterday). There they are (dates are in front)
Just a little context on the pairs... Cred Man on windows has a limit to the number of characters you can store so we chunk them. The are the 2nd part of the other one. can you tell me how many things you've logged into with your Microsoft account? Based on 2 items being updated on Nov 4, I am going to guess...2... LiveShare & Settings Sync maybe? The ones from Aug 30 are odd... around that time, I was not working heavily in credentials land so that leads me to believe that you saw the bug that other folks in this thread are mentioning... the slow slow climb in the number of secrets. It's unclear to me why that happened... I ask myself questions: Were these credentials being used before that date and one day they weren't read properly so new credentials were created? This is possible. The library we use can be a bit dicey... and Windows certainly isn't perfect. before the "sign in every time behavior". Do you recall having to randomly sign in to Microsoft every once in a while? If this is the case, I need a better clean up mechanism... if possible. Were these credentials created accidentally as a duplicate... like could a 2nd window of VS Code think it was responsible for storing the credential and thus it stored a duplicate secret which was then overwritten by the updating of the keylist. Worth double checking... I thought only one window handles the creation of secrets, but maybe I'm missing something. If this is the case, the keylist might be getting mangled with 2 instances of vscode writing to the same place Btw, all of the non-keylist ones can probably be deleted (I'm assuming the date modified on those are a while ago). Those are from the old structure of secrets where all secrets were stored in one (chunked) credential.
Yes, these two. It's not that this doesn't happen, but it is diffucult to remember so far back.
Hi folks it has been a bit... I wanted to let you all know that I made a change that I think will be helpful here. It's available in the VS Code Insiders Build: What I'm hoping you see is no more gradually increasing number of credentials in CredMan. Please give it a try and let me know how it goes. I know it may take days/weeks/months to fully verify that this change made a difference... but it'll be worth it!
Wish I found this issue earlier. I just counted 188 entries in my Credential Manager for . I've been seeing this problem for the last few weeks (months?), where vscode constantly signs me out of my settings sync. Finally looked into it this morning and found the, "Not enough memory resources" output message, which led me to this issue. I deleted all the authenticator tokens from CredMan, and it seems to have resolved the issue (for the last 24 hours, at least). I use VSCode Insiders full-time and update it on a near-daily basis. Some sort of toast message, triggered by the the "not enough memory" error, might be nice to alert the user to the issue and instruct them to clear out their ms-auth tokens.
Spoke too soon. After a few days of daily Insiders updates and whatnot, I've continually been prompted to sign into Microsoft to sync settings, and each time, I end up with a dozen or so new tokens into CredMan. They appear to just grow unbounded. Is that expected? Am I going to have to periodically run the command to clean these up? I assume I'll eventually hit the, "Not enough memory" error at some point if I just let the list continue to grow?
Thanks for the update. We'll be doing more drastic work in this space this month and next and my hope is that this will be resolved then.
I don't know if this is useful or not, but I've only seen a Microsoft Authentication problem when running multiple instances of VS Code. By this I mean: Start VS Code normally, do work... Open another instance with the "Workspaces: Duplicate As Workspace in New Window" command Do more work Shut down VS Code for the day with File-Exit, and not by closing each window individually with X in the upper right. Next day, start VS Code just by clicking the icon in my taskbar. Both instance windows show up in the same state I left them in the day before Work some more I haven't seen a problem for months because I WAS NOT doing the above workflow. When I opened another instance, I closed them separately, which means I only get one window on the next startup of VS Code. But I did do the above workflow last night and today and about 4-5 hours after starting it this morning the Microsoft authentication failed with messages: I have no idea what's causing this, but it seems that problems related to this happen more often with multiple instances running. There were a few people commenting on this issue that they were running multiple instances. I also don't know if this is happening because VS Code was started with 2 instances, like I did this morning, or if it is just sufficient to have more than one instance where the additional instances were started with that Duplicate command after the first instance was created. I tend to suspect the former because I never saw the problem when starting a VS Code session with just one initial instance. I saw it today after starting a session with 2 initial instances/windows. Again, I have no idea, but it feels like the two instances of VS Code are banging on the authenticator at the same time or are running some non-reentrant code at the same time on the way to the authenticator. HTH
I cleared out the credentials, but in less than a day I was back to more than 100 entries. The problem also started showing up on two machines that didn't have it, immediately after the latest update. (As in, 100+ credentials created starting in the minutes after VS Code restarted for the upgrade.) Notably, in light of the above comment, my setup does involve multiple restored windows - and the upgrade restart does restore them.
Thanks all. Sorry to hear this issue has not been fixed yet and sad that I've not been able to repro this. I will say that we have some plans in the works for dealing with secret storage in light of 's archival. More on that later.
I'm also running into this, my Windows Credential manager is full of lines like this: ! See and since yesterday it is full again, so I'd be happy to help debug this if you can point me to the right logging commands.
Not sure related or not, but the latest version would cause consuming high CPU, especially when VS Code thinks I need to re-log in my account.
Even after log-in, CPU usage would not restore. Need to close vscode all over
I think I have finally found the issue and have a PR out for this. Thank you all for your patience and providing good information. To help me, you can get the insider build here: My change will be in the insider build that will go out either Thursday or Friday.
So far so good, I installed the insider build, played with some different git repo folders, and I have only 2 entries in the Credential Manager: ! The second one seems to be fore github copilot.
My change hasn't gone in yet
I haven't seen this problem for about a week on Insiders build, after several attempts to remove all credentials manually or with script. Problem re-emerged few times, but works as expected after another run of the script. Hope update would fix it for everyone and it won't re-emerge again. P.S. I haven't use a lot of workspaces lately (as mentioned in PR), will try to get into bad state before update once again.
Looking at your fix, I might be more aggressive about deleting all the chunks even if one of those deletes fails, for example, could 2 vscode instances be trying to delete the same chunks at the same time? Do you know what the user scenario is that results in very large passwords that need chunking? That might help me test it better...
This isn't possible because deletes are now handled sequentially thanks to that PR. Microsoft Auth via Settings Sync. The limit in CredMan is a measly 2500 characters. A refresh token that gets stored in Cred Man is usually way larger than that. That refresh token also gets updated every reload of a window (every time Microsoft Auth extension is activated) hence the issue with multiple windows writing at the same time when a VS Code update happens.
Your suspected behavior written up in the PR definitely tracks with my usage patterns and observations. I'm looking forward to the fix! Should we clear out the hundreds of tokens inside CredMan ahead of your fix going live? Or will they get cleared/handled as part of your revised operations? Thanks!
you'll want to clear out CredMan.
I just updated to 1.76.1. Now multiple vscode windows cannot sign in sync. A sign-in of one window will kick off others'.
It's likely the same problem since this issue was addressed in 1.77 which is only in insiders and will be released in a few weeks.
I was able to reproduce on my PC with then before update and it "spammed" credentials. After cleaning up credentials, updating, cleaning up again - 12+ days without issues. I think I was asked once (it might been for GHPR extension), but there is definitely no "spam" in credentials so far. However, it took noticeable time to repro it in so hard to tell for sure
Thanks for your report This one...... will be hard to verify.... and I think what you did is as close to a proper verification as we will get. I will mark this as verified and we will see what the 1.77 stable release gives us in a couple weeks. If anyone sees this issue in 1.77-insiders until then, please don't hesitate to reach out.
This issue doesn't look the same as , but I'll wait for 1.77 and reopen my bug report if the issue is not fixed.
I have the exact same issue as and I agree that it doesn't appear the same as . I will also wait for the new fix and see if it fixes my problem.
Now I am asked regularly to choose account so sync my settings from and when the list appears the Microsoft account appears as "(signed in)". I cleared the stored authentications a week ago (before the 1.77 update).
Looks like folks still see this in 1.77 at least partially. I need a new issue because this one is just way to busy... so we'll keep going in
this is useful
Just want to report that on Windows, the keychain could get into a bad state due to this issue, after which even upgrading to the newer version of vscode doesn't help'. One would need to take the actions suggested in , as mentioned above, which solved the issue for me.
it is actually worse now. I am being asked to select the account to sync settings from repeatedly upon launching VS Code. The Microsoft accont I am using appears as "(Signed in)", so the token does not appear to be lost, just disacossiated. I can't see anything within the logs.
Is it worse or did your Windows credentials just get full? That happens to me from time-to-time and it's annoying. posted above provided a recipe for deleting all of the Windows credentials. This fixes it for a while, then I have to do it again.
folks, re-posting what I'm saying above:

Related discussion:
text: throw e; } <del> if (isWindows && password.length > BaseCredentialsMainService.MAX_PASSWORD_LENGTH) { let index = 0; let chunk = 0; let hasNextChunk = true; while (hasNextChunk) { const passwordChunk = password.substring(index, index + BaseCredentialsMainService.PASSWORD_CHUNK_SIZE); index += BaseCredentialsMainService.PASSWORD_CHUNK_SIZE; hasNextChunk = password.length - index > 0; const content: ChunkedPassword = { content: passwordChunk, hasNextChunk: hasNextChunk }; await retry(() => keytar.setPassword(service, chunk ? `${account}-${chunk}` : account, JSON.stringify(content)), 50, 3); chunk++; } </del> <ins> await this._sequencer.queue(service + account, () => this.doSetPassword(keytar, service, account, password)); } </ins> <del> this.logService.trace(`Got${chunk ? ` ${chunk}-chunked` : ''} password from keytar for account:`, account); } else { </del> <ins> private async doSetPassword(keytar: KeytarModule, service: string, account: string, password: string): Promise<void> { if (!isWindows) { </ins> await retry(() => keytar.setPassword(service, account, password), 50, 3); <del> this.logService.trace('Got password from keytar for account:', account); </del> <ins> this.logService.trace('Set password from keytar for account:', account); this._onDidChangePassword.fire({ service, account }); return; </ins> } <ins> // On Windows, we have to chunk the password because the Windows Credential Manager only allows passwords of a max length. // So to make sure we can store passwords of any length, we chunk the password and store it as multiple passwords. // To ensure we store an password correctly, we first delete any existing password chunks and then store the new ones. await this.doDeletePassword(keytar, service, account); let index = 0; let chunk = 0; let hasNextChunk = true; const promises = []; while (hasNextChunk) { const passwordChunk = password.substring(index, index + BaseCredentialsMainService.PASSWORD_CHUNK_SIZE); index += BaseCredentialsMainService.PASSWORD_CHUNK_SIZE; hasNextChunk = password.length - index > 0; const content: ChunkedPassword = { content: passwordChunk, hasNextChunk: hasNextChunk }; promises.push(retry(() => keytar.setPassword(service, chunk ? `${account}-${chunk}` : account, JSON.stringify(content)), 50, 3)); chunk++; } await Promise.all(promises); this.logService.trace(`Set${chunk ? ` ${chunk}-chunked` : ''} password from keytar for account:`, account); </ins> this._onDidChangePassword.fire({ service, account }); }