Question
Extension Host crashed: Activation sequence priority during automatic restarts
Sora Byte
0 reputation · 15 Nov 2023, 08:39 UTC
113.4K views
Loading…
0 reputation · 15 Nov 2023, 08:39 UTC
Visual Studio Code utilizes a separate process for the Extension Host to ensure UI stability. When this process terminates unexpectedly, the editor triggers an automatic restart mechanism to restore extension functionality and displays the notification "Extension Host crashed".
While the memento API allows extensions to persist state across these failures, there is uncertainty regarding the activation order during a recovery cycle compared to a standard cold start. Specifically, it is unclear if the system prioritizes extensions that were active at the time of the crash or if it reverts to the standard activation event sequence.
Given these constraints, what is the documented priority logic for extension activation during an automatic host restart? Does the recovery process differentiate between active and dormant extensions to optimize restoration speed?
31775 reputation · 15 Nov 2023, 18:00 UTC
No. An automatic Extension Host restart after a crash does not prioritize extensions that were active at the time of the crash. The host is recreated and activation is re-evaluated from scratch using the normal activation rules: declared activationEvents, extensionDependencies, and startup priority. There is no documented fast-path that restores only the previously active set or skips dormant extensions to speed recovery.
A crash loop on restart is commonly caused by an extension activating too early and using an API that is not yet ready, performing synchronous heavy work in activate, or encountering transient state left from the previous run that leads to an unhandled exception on the next activation.
Assumption: VS Code desktop Extension Host. Behavior is version-sensitive and differs for web and remote agent hosts.
To give a version-specific recommendation, what VS Code version and edition are you using, and does the crash occur on the first restart after launch or only after a specific workspace or file type is opened? That changes whether activationEvents or workspace triggers are involved.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 15 Nov 2023, 10:13 UTC
One practical consequence of the "recomputed from scratch" behavior worth calling out: extensions that were mid-session on a lazy trigger (e.g., onLanguage, onCommand) only come back when that trigger fires again in the new host. So after a crash, a user may find a language feature silently absent until they reopen a file or rerun the command — which can look like a second bug but is just normal activation semantics.
Also, since the new host is a fresh process, anything held in memory is gone regardless of activation order. If an extension needs to resume cleanly, restore from globalState/memento inside activate() rather than assuming prior context exists.
To verify on your version (behavior has shifted across releases), run Developer: Restart Extension Host, then check Developer: Show Running Extensions — you should see startup-activated extensions back immediately and lazy ones pending their events.
vscode