Change:
Issue Type: <bBug</bI have 45 extensions installed and applications start to crash after leaving VS Code running for 2-3 days, if I have more than one instance it is sooner. I assumed it was an extension as I have 45 installed. My initial reaction was to disable GitHub CoPilot thinking this might be the problem, and no change in memory loss. I am using VS Code Process Explorer to monitor memory usage. So my next step was to disable all extensions and enable them one by one to see if I can catch the one giving me a problem. While waiting a few seconds for a baseline with no extensions, I noticed I was still losing about 5MB/minute or just over 300Mb/hour. I am using latest version on Windows 10 Pro x64 with latest system updates. I have tried a fresh reboot and running without extensions on a fresh restart and I am continously losing ram at the same rate. With all extensions enabled, I am losing roughly the same amount of ram per minute. I've been having this issue for a few months and doubled my system ram to 64G to give me more buffer until things start crashing as at the time I haven't narrowed down the problem. UPDATE: I installed the insider build and seeing similar results, in fact memory loss is closer to 5.9MB/minute. This is without extensions and with default settings file. Just sitting idle without a project loaded. VS Code version: Code 1.69.2 (, 2022-07-18T16:12:52.460Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (43)</summaryExtensionVersion ------ markdown-mermaid1.14.2 vscode-tailwindcss0.8.6 npm-intellisense1.4.2 postcss1.0.9 transformer1.12.1 vscode-eslint2.2.6 githistory0.6.19 vscode-babel-coloring0.0.4 gitlens12.1.2 vscode-html-css1.13.1 EditorConfig0.16.4 vscode-npm-script0.3.28 prettier-vscode9.5.0 text-transform0.1.0 auto-rename-tag0.1.10 copilot1.36.6340 todo-tree0.0.215 dotenv1.0.1 inline-fold0.1.6 python2022.10.1 vscode-pylance2022.7.40 jupyter2022.6. jupyter-keymap1.0.0 jupyter-renderers1.0.9 remote-ssh0.84.0 remote-ssh-edit0.80.0 remote-wsl0.66.3 color-highlight2.5.0 indent-rainbow8.3.1 hivecoin-statusbar0.0.5 quicktype12.0.46 vscode-thunder-client1.16.7 ansible0.11.10 vscode-yaml1.9.1 wordcount0.1.33 vue-vscode-snippets3.1.1 autoimport1.5.4 es6-string-html2.12.0 highlight-matching-tag0.10.1 vscode-icons11.13.0 volar0.39.3 vue1.0.26 markdown-all-in-one3.4.3 (2 theme extensions excluded) </details<!-- generated by issue reporter --
thanks for the report. From the process explorer, do you see which process is consuming more and more memory? A screenshot would probably help and we can check if it's a UI process or an extension process.
I disabled all extensions, and even ran insider with default config and no extensions. It shows all the memory on the code parent process, but doesn't seem to show which one. Here is a blank project (nothing loaded, just started code and left it idle) in Code Insiders with default settings and no extensions before and after a couple of hours (~3 or so) ! !
the screenshots are very helpful, thanks!
I still see it with latest update, also I see it in the insiders build. Has something been identified that is causing this?
I found a probable memory leak in some code for the process explorer itself. I hope to submit a PR for that later this week. Meanwhile some questions: the issue occur for you when you close the process explorer and reopen it after a long while? the Windows task manager process explorer report ever increasing numbers for VS Code's memory consumption?
check (5-10 mins) it seems the memory leak slows down/pauses when process explorer isn't running. , but slows down with process explorer is closed I am really confused, because I never used process explorer until I had this problem. In fact, I had to buy another 32G of ram (64G total just to run VS Code) as my computer would keep crashing every two days due to this issue. I got about 2 days before my 32G would wipe out and apps would start crashing. Took me a while to narrow it down to VS Code. I keep my computer running and I usually keep one or two VS Code sessions open. I was seeing same behavior in both VS Code and VS Code Insiders. I did some testing, and here is what I see. If I start VS Code, and start Process Explorer, the ram for the main process goes up about 5MB/minute. I see a similar gain in Task Manager (Windows 10). If I stop Process Explorer while taking note of the memory in both Process Explorer and Task Manager I notice that Process Manager's memory no longer increments, the next time I open it it is where it was when I closed it, but nothing is freed. Task Manager though shows some memory releasing, slowly, but not a lot. For example after a few minutes I am at 340MB in Task Manager and 190 MB as the top process in Process Explorer. After 10 minutes I may drop 10-20MB in Task Manager but will be at the exact same ram in Process Manager (at least for the first process which is what I am monitoring and what is growing 5MB/minute). Process Manager will immediately start gaining memory the moment I open it. This feels like different behavior than before, because in the past my committed memory would constantly grow no matter how much ram I had. I went from 32G ram to 64G with 35G swap file and I would still exhaust it. I have since started closing VS Code as soon as I am done with anything as I can't afford to have applications crashing and losing data. So I don't really know the current state of things outside of this test. I was losing important information and processes as they would just randomly lock up once I filled committed memory despite having way more than ram that I can possibly need.
Verification steps: the process explorer and record down the memory consumption of the main process. the process explorer open for 15 minutes. that the memory consumption of the main process hasn't noticeably increased.

Discussion:
"@vscode/windows-registry": "1.0.6", "windows-foreground-love": "0.4.0", "windows-mutex": "0.4.1", <del> "windows-process-tree": "0.3.3" </del> <ins> "windows-process-tree": "0.3.4" </ins> }, "resolutions": { "elliptic": "^6.5.3",

}, "optionalDependencies": { "@vscode/windows-registry": "1.0.6", <del> "windows-process-tree": "0.3.3" </del> <ins> "windows-process-tree": "0.3.4" </ins> } }

dependencies: string-width "^1.0.2 || 2 || 3 || 4" <del> windows-process-tree@0.3.3: version "0.3.3" resolved "https://registry.yarnpkg.com/windows-process-tree/-/windows-process-tree-0.3.3.tgz#7c178815f02bf4cfbcac1f93b2f3a3cc10bc9245" integrity sha512-rkiAMP0AS27xikFyn7i4gPbOK16UdjY8X/C6eo37CnfNLqTvK2eEaT+Dh0e5xnvmlsi0lEKd60O+4ajzfDkq7A== </del> <ins> windows-process-tree@0.3.4: version "0.3.4" resolved "https://registry.yarnpkg.com/windows-process-tree/-/windows-process-tree-0.3.4.tgz#6bc4b8010129c30ff95bcd333b9f94744dd3c4fb" integrity sha512-rtSX73i9OnkDxSdBP9c1YBunEwheZdO/hjRwNk9uSoWqO92x0zDRGfIIK0MtUn8gZZD+2kPEVpj5MmfNl7JpJA== </ins> dependencies: nan "^2.13.2"

bindings "^1.2.1" nan "^2.14.0" <del> windows-process-tree@0.3.3: version "0.3.3" resolved "https://registry.yarnpkg.com/windows-process-tree/-/windows-process-tree-0.3.3.tgz#7c178815f02bf4cfbcac1f93b2f3a3cc10bc9245" integrity sha512-rkiAMP0AS27xikFyn7i4gPbOK16UdjY8X/C6eo37CnfNLqTvK2eEaT+Dh0e5xnvmlsi0lEKd60O+4ajzfDkq7A== </del> <ins> windows-process-tree@0.3.4: version "0.3.4" resolved "https://registry.yarnpkg.com/windows-process-tree/-/windows-process-tree-0.3.4.tgz#6bc4b8010129c30ff95bcd333b9f94744dd3c4fb" integrity sha512-rtSX73i9OnkDxSdBP9c1YBunEwheZdO/hjRwNk9uSoWqO92x0zDRGfIIK0MtUn8gZZD+2kPEVpj5MmfNl7JpJA== </ins> dependencies: nan "^2.13.2"