VSCode fails to launch after 1.101.0 update
Does this issue occur when all extensions are disabled?: Yes
- VS Code Version: 1.101.0
- OS Version: 26100.4349
After updating to 1.101.0 from 1.100.3 on Windows 11 Multisession, build mentioned above, VSCode no longer launches for standard users. It launches fine for users in the administrators group. VSCode is installed machine wide as these are multi-session devices.
I have confirmed after we re-install version 1.100.3 we are no longer seeing this issue.
Steps to Reproduce:
- Open VSCode via start menu shortcut, nothing happens
- Run code.exe directly from powershell using
& .\Code.exe --verbose --disable-extensionsand we see the following errors:- I have confirmed all files/folders in the errors exist and are writeable by the user running code.exe
PS C:\Program Files\Microsoft VS Code> & .\Code.exe --verbose --disable-extensions
PS C:\Program Files\Microsoft VS Code>
[main 2025-06-13T21:18:32.719Z] PolicyConfiguration#initialize
[main 2025-06-13T21:18:32.737Z] PolicyConfiguration#updatePolicyDefinitions [
'update.mode',
'update.channel',
'update.enableWindowsBackgroundUpdates',
'update.showReleaseNotes',
'http.useLocalProxyConfiguration',
'http.electronFetch',
'http.proxy',
'http.proxyStrictSSL',
'http.proxyKerberosServicePrincipal',
'http.noProxy',
'http.proxyAuthorization',
'http.proxySupport',
'http.systemCertificates',
'http.experimental.systemCertificatesV2',
'http.fetchAdditionalSupport',
'telemetry.telemetryLevel',
'telemetry.feedback.enabled',
'telemetry.enableTelemetry',
'extensions.allowed'
]
[main 2025-06-13T21:18:32.740Z] NativePolicyService#_updatePolicyDefinitions - Found 4 policy definitions
[main 2025-06-13T21:18:32.751Z] [File Watcher (node.js)] Request to start watching: c:\Users\<user>\AppData\Roaming\Code\User (excludes: <none>, includes: <all>, filter: <none>, correlationId: <none>),c:\Users\<user>\AppData\Roaming\Code\User\settings.json (excludes: <none>, includes: <all>, filter: <none>, correlationId: <none>)
[main 2025-06-13T21:18:32.754Z] [File Watcher (node.js)] ignoring a path for watching who's stat info failed to resolve: c:\Users\<user>\AppData\Roaming\Code\User (error: Error: ENOENT: no such file or directory, stat 'c:\Users\<user>\AppData\Roaming\Code\User')
[main 2025-06-13T21:18:32.755Z] [File Watcher (node.js)] starting fs.watchFile() on c:\Users\<user>\AppData\Roaming\Code\User (correlationId: undefined)
[main 2025-06-13T21:18:32.755Z] [File Watcher (node.js)] ignoring a path for watching who's stat info failed to resolve: c:\Users\<user>\AppData\Roaming\Code\User\settings.json (error: Error: ENOENT: no such file or directory, stat 'c:\Users\<user>\AppData\Roaming\Code\User\settings.json')
[main 2025-06-13T21:18:32.756Z] [File Watcher (node.js)] starting fs.watchFile() on c:\Users\<user>\AppData\Roaming\Code\User\settings.json (correlationId: undefined)
[main 2025-06-13T21:18:32.783Z] NativePolicyService#_onDidPolicyChange - Updated policy values: {"UpdateMode":"none","AllowedExtensions":"{\n \"bierner.github-markdown-preview\": true,\n \"GitHub.vscode-pull-request-github\": true,\n \"bierner.markdown-checkbox\": true,\n \"bierner.markdown-emoji\": true,\n \"bierner.markdown-footnotes\": true,\n \"bierner.markdown-preview-github-styles\": true,\n \"bierner.markdown-yaml-preamble\": true,\n \"bierner.markdown-mermaid\": true,\n \"ms-vscode.powershell\": true,\n \"ms-vscode.azurecli\": true,\n \"ms-ssdevteam.scope-vscode-ext\": true,\n \"rosshamish.kuskus-extensions-pack\": true,\n \"GitHub.copilot\": true,\n \"GitHub.copilot-chat\": true\n}"}
[main 2025-06-13T21:18:32.785Z] PolicyConfiguration#update [
'update.mode',
'telemetry.telemetryLevel',
'telemetry.feedback.enabled',
'extensions.allowed'
]
[main 2025-06-13T21:18:32.803Z] PolicyConfiguration#changed [
[ 'update.mode', 'none' ],
[
'extensions.allowed',
{
'bierner.github-markdown-preview': true,
'GitHub.vscode-pull-request-github': true,
'bierner.markdown-checkbox': true,
'bierner.markdown-emoji': true,
'bierner.markdown-footnotes': true,
'bierner.markdown-preview-github-styles': true,
'bierner.markdown-yaml-preamble': true,
'bierner.markdown-mermaid': true,
'ms-vscode.powershell': true,
'ms-vscode.azurecli': true,
'ms-ssdevteam.scope-vscode-ext': true,
'rosshamish.kuskus-extensions-pack': true,
'GitHub.copilot': true,
'GitHub.copilot-chat': true
}
]
]
[main 2025-06-13T21:18:32.807Z] PolicyConfiguration#updatePolicyDefinitions []
[main 2025-06-13T21:18:32.837Z] PolicyConfiguration#update []
[main 2025-06-13T21:18:33.021Z] Error: ENOENT: no such file or directory, mkdir 'C:\Users\<user>\AppData\Roaming\Code\CachedData\dfaf44141ea9deb3b4096f7cd6d24e00c147a4b1'
[main 2025-06-13T21:18:33.024Z] Lifecycle#kill()
[main 2025-06-13T21:18:33.039Z] Lifecycle#onWillShutdown.fire()
[main 2025-06-13T21:18:33.092Z] _t [Error]: Unable to write file 'c:\Users\<user>\AppData\Roaming\Code\User\globalStorage\storage.json' (EntryNotFound (FileSystemError): File to move/copy does not exist)
at _u.writeFile (file:///C:/Program%20Files/Microsoft%20VS%20Code/resources/app/out/main.js:147:6690)
at async jy.s (file:///C:/Program%20Files/Microsoft%20VS%20Code/resources/app/out/main.js:35:94787) {
fileOperationResult: 1,
options: { atomic: { postfix: '.vsctmp' } }
}
The same happened to me. I found that the executable file code.exe had changed its location from C:\Users{USER}\AppData\Local\Programs\Microsoft VS Code\ to C:\Users{USER}\AppData\Local\Programs\Microsoft VS Code_. Update the shortcut path, and it will open normally.
We are not seeing the same behavior. This is on a machine-wide installation of Teams, so code.exe is in C:\Program Files\Microsoft VS Code. The errors appear to be when VSCode is attempting to read/write per user configurations in %APPDATA%.
It's particularly interesting that this runs fine for Administrators, but not for standard users on the same machines.
I'm seeing the same errors as @lukar-msft on a machine-wide installation, however it still fails to launch when I run C:\Program Files\Microsoft VS Code\Code.exe as administrator.
I got this working temporarily by downgrading to 1.100.3 using the system installer at https://update.code.visualstudio.com/1.100.3/win32-x64/stable. If you need the user installer, it can be found at https://update.code.visualstudio.com/1.100.3/win32-x64-user/stable
@lramos15 Can you please triage this? We are stuck on 1.100.3 until this is resolved.
Hello,
We have the same issue on Windows 11 24H2 multisession. When you click Visual studio code it doesn't do anything, after downgrading it works.
Our situation is a bit weird, as VS Code stopped working on a hostpool where the session hosts are on Win11 24H2 Multisession, but it works fine on other hostpools that have the same OS. From the initial investigation, the issue seems to be related to FSLogix, as once we disable it, VSCode 101.0 worked fine again. When FSLogix is enabled, the only way to start VSCode is to change the path for the user directory, from the users profile folder to a local folder on the VM (code --user-data-dir="C:\Temp\vscode-test" --extensions-dir="C:\Temp\vscode-extensions"). However, once VSCode is opened, if I try to open files or folders from the users profile folder, it fails with the error: "Path does not exist". I'm not sure why this happens, as I couldn't find errors in the FSLogix logs and other applications can work with files from the user profile. As other mentioned above, the previous version of VSCode works fine, but once the update to 101.0 is completed, VSCode can no longer be launched.
I am having this issue with 1.101.1. I do have code set to launch as admin, I have noticed in the past having this setting causes issues on updates as it tries to re-launch the app and fails. This time it was in an unusable state. I was able to launch after running
winget install --id Microsoft.VisualStudioCode --scope machine --force
VS Code Version: 1.101.2 OS Version: 11.0.26100.4349 FSLogix: 3.25.401.15305
Same issue with 1.101.x failing to load. I'm also using FSLogix version 3.25.401.15305. If I use an account w/o a FSLogix profile on the same system, VSCode will launch. If I use an earlier version of VSCode, 1.100.3, it will launch until it upgrades. If I use another system w/ an older version of FSLogix, 2.9.884.27471, VSCode 1.101.2 will launch.
I have the same issue and the workaround also works for me.
same issue here.
could this issue be caused by this merge https://github.com/microsoft/vscode/commit/d59fac320f85a309e4fd59eb06fa9d4e5b3bf474#diff-26b7adb12a8dd97e82b317edb5b05f1acaafea4ad4f17f8899478f99215374bd
VS Code Version: 1.101.2 OS Version: 11.0.26100.4349 FSLogix: 3.25.401.15305
Same issue with 1.101.x failing to load. I'm also using FSLogix version 3.25.401.15305. If I use an account w/o a FSLogix profile on the same system, VSCode will launch. If I use an earlier version of VSCode, 1.100.3, it will launch until it upgrades. If I use another system w/ an older version of FSLogix, 2.9.884.27471, VSCode 1.101.2 will launch.
Same with us. All instances above 1.100.3 will not launch on our AVD env. Is there a timeline for a fix @deepak1556 ?
We are seeing the same issue on 1.102. Rolling back to 1.100 solves the issue.
Windows 11 24H2 26100.4351 FSLogix 3.25.401.15305 Azure Virtual Desktop with FSLogix
`PS C:\Windows\system32> code --verbose
[main 2025-07-16T09:20:42.120Z] PolicyConfiguration#initialize
[main 2025-07-16T09:20:42.121Z] PolicyConfiguration#updatePolicyDefinitions [
'update.mode',
'update.channel',
'update.enableWindowsBackgroundUpdates',
'update.showReleaseNotes',
'http.useLocalProxyConfiguration',
'http.electronFetch',
'http.proxy',
'http.proxyStrictSSL',
'http.proxyKerberosServicePrincipal',
'http.noProxy',
'http.proxyAuthorization',
'http.proxySupport',
'http.systemCertificates',
'http.experimental.systemCertificatesV2',
'http.fetchAdditionalSupport',
'telemetry.telemetryLevel',
'telemetry.feedback.enabled',
'telemetry.enableTelemetry',
'extensions.allowed'
]
[main 2025-07-16T09:20:42.124Z] NativePolicyService#_updatePolicyDefinitions - Found 4 policy definitions
[main 2025-07-16T09:20:42.135Z] [File Watcher (node.js)] Request to start watching: c:\Users%USERNAME%\AppData\Roaming\Code\User (excludes:
Sorry for the delay on this, @lukar-msft I am using microsoft virtual desktop to repro the issue. I see that the org policy has disabled updates and locked the version to 1.100.3. Given this only affects system install when running as non-admin user, I would like to bisect and possibly test with custom builds on the system. Can we sync to see how I can get a proper testing environment with admin privileges ?
Thanks to @lukar-msft for creating a test environment, I was able to narrow down the issue
Errors were being thrown from Node.js fs operations, specifically any file stat operations in users profile directory ended up with ENOENT: no such file or directory. Reduced it to the following test case
node -e console.log(require("fs").statSync("C:\\Users\\demohan\\AppData")
Between VSCode v1.100 and v1.101 we bumped Node.js runtime from v20.x to v22.x. Bisect narrowed down v22.12.0 as the first version that broke this behavior and this is the change https://github.com/libuv/libuv/commit/4e310d0f90af29e699e2dedad5fa0dcee181a7cc, it adopts GetFileInformationByName api for faster stat operations
https://learn.microsoft.com/en-us/answers/questions/2277994/fslogix-causes-python-3-12-and-wsl-to-incorrectly points to issues in WSL and python projects which also rely on the same api break in FSLogix managed profile. So seems like there is an underlying bug with FSLogix and its interaction with this particular syscall.
- File a bug with FSLogix
- Create a retry on the slow path in libuv if its detected to be FSLogix environment and not found error is returned as a temporary solution
Detecting FSlogix environment based on the presence of HKLM\SOFTWARE\FSLogix seems reliable, going with the following patch as a temporary workaround
diff --git a/deps/uv/src/win/fs.c b/deps/uv/src/win/fs.c
index 27248f644f..8619d729f7 100644
--- a/deps/uv/src/win/fs.c
+++ b/deps/uv/src/win/fs.c
@@ -181,6 +181,28 @@ void uv__fs_init(void) {
uv__fd_hash_init();
}
+INLINE static int fs__fslogix_environment() {
+ static int fslogix = -1;
+ int err;
+ HKEY fslogix_key;
+
+ if (fslogix != -1)
+ return fslogix;
+
+ err = RegOpenKeyExW(HKEY_LOCAL_MACHINE,
+ L"SOFTWARE\\FSLogix",
+ 0,
+ KEY_QUERY_VALUE | KEY_WOW64_64KEY,
+ &fslogix_key);
+ if (err != ERROR_SUCCESS) {
+ fslogix = 0;
+ } else {
+ fslogix = 1;
+ RegCloseKey(fslogix_key);
+ }
+ return fslogix;
+}
+
INLINE static int fs__readlink_handle(HANDLE handle,
char** target_ptr,
@@ -1713,6 +1735,9 @@ INLINE static fs__stat_path_return_t fs__stat_path(WCHAR* path,
switch(GetLastError()) {
case ERROR_FILE_NOT_FOUND:
case ERROR_PATH_NOT_FOUND:
+ if (fs__fslogix_environment()) {
+ return FS__STAT_PATH_TRY_SLOW;
+ }
case ERROR_NOT_READY:
case ERROR_BAD_NET_NAME:
/* These errors aren't worth retrying with the slow path. */
Testing a build with the above patch confirms to resolve the issue
https://github.com/user-attachments/assets/11af2fbd-9f69-4af0-8979-46c98b7668e7
Thanks @deepak1556 I have also confirmed installing the v1.103.0 build system wide resolves the issue for standard users who log into the machine
that is good news, when will this fix will be part of the main release?
It will be part of our 1.103 release https://github.com/microsoft/vscode/issues/255701 that will happen in the first week of August.
This bug has been fixed in the latest release of VS Code Insiders!
@lukar-msft, you can help us out by commenting /verified if things are now working as expected.
If things still don't seem right, please ensure you're on version 5e5fabe43505fc3510c5185c2afff35bf9923bbd of Insiders (today's or later - you can use Help: About in the command palette to check), and leave a comment letting us know what isn't working as expected.
Happy Coding!
Confirmed the latest insiders build 1.103.0 runs successfully for a standard user with a roaming profile in an environment running FSLogix 3.25.626.21064 on Windows 11 24H2 Multi-Session
/verified
FS__STAT_PATH_TRY_SLO... what are the performance or other implications of this? What is the path to undo this disablement once an updated and fixed version of FSLogix is released?
We are reverting to the stat path used up until v1.100. We are following the bug tracked by FSLogix, we will remove the patch once they roll out a fix and document it in our release notes. It is upto the users at that point to update to the version of FSLogix containing the fix.