Change:
return this.userDataProfileStorageService.withProfileScopedStorageService(profile, async storageService => { const disposables = new DisposableStore(); <del> const instantiationService = this.instantiationService.createChild(new ServiceCollection([IStorageService, storageService])); </del> <ins> const instantiationService = disposables.add(this.instantiationService.createChild(new ServiceCollection([IStorageService, storageService]))); </ins> const extensionEnablementService = disposables.add(instantiationService.createInstance(GlobalExtensionEnablementService)); const extensionStorageService = disposables.add(instantiationService.createInstance(ExtensionStorageService)); try {

Discussion:
From It's happened to me at least 4 times in the last 2 weeks, I open up a previously running Code Insiders and the extension view loads forever. The process explorer shows that the shared process is gone. There are no crashes in .
Ah! Shared process does crash, this is in the main log: <img width="1067" alt="image" src=""
Anything in around the timestamp of the crash ?
Found out why I had no crash reports:
Here it is! <details<summaryCrash report</summary</details
I'm getting different crash reasons actually. Just happened again last night. Out of memory? Weird. <details<summaryCrash report</summary</details
We might actually have a memory leak here. I'll be recording the total memory allocated for the shared process along the day and plotting it. Here's the first 20 minutes, not looking great: !
Mostly related: I discovered a bug yesterday that caused the extension to download itself repeatedly until it succeeded - - This could also crash the shared process, but only when the download fails. I fixed it . Lets check the memory chart today with today's insider.
Thanks for showing me how to attach devtools to the shared process. Details: Launch vscode like In chrome browser visit chrome://inspect/ or in edge browser visit edge://inspect/ You should see an entry under Remote Target that starts with /Applications/Visual Studio Code/.... If you don't see the above entry, then Under Devices, click open dedicated devtools for node Under Connection tab, add localhost:9229 You should now see the target Click inspect Indeed an allocation timeline quickly shows bursts of memory allocation every time I focus VS Code back from another app. In the following recording, I focused it three times. Each of these are ~60MB of memory that won't ever be garbage collected. <img width="1582" alt="image" src=""
This is related to settings embeddings: <img width="1504" alt="image" src=""
I could only find the string in copilot chat. this appears to be your land. Any thoughts on why (1) this huge string makes it into the shared process and (2) hangs around forever to the point of crashing the shared process?
Alright, root cause found!

TL;DR , which surfaces a memory leak in a part of the Settings Sync area which runs in the shared process. I am the only one who seems to repro this due to the following snowflake conditions: I have a profile which I no longer open since a long time. That profile once had Copilot nightly installed with . This has since been fixed. One of the mementos is a 60MB JSON string. I have Settings Sync enabled. In essence: time I focus VS Code, Settings Sync code runs. syncing Settings Sync will send all storage data from across all profiles over to the shared process for potential uploading. handling that data, the shared process would create a child instantiation service to process it and would forget to dispose the service. This has now been fixed by , that instantiation service (and all it pointed to, including those 60MB of string) would get garbage collected. But since now parent instantiation services hold on to their undisposed children, all of that would be prevented from being garbage collected. Thanks for creating a follow up item to review all calls and make sure is eventually called: Throughout a normal day, in which I focus in and out of VS Code multiple times, these incremental 60MB allocations would eventually result in a OOM crash. A couple more follow up items: should we clear the , when it's disposed? let's reevaluate how profiles storage is handled when Settings Sync runs, se we stop sending it from the main to the shared process on every sync request. Fixed by