Change:
return; } <del> let NODE_MODULES_PATH = appRoot ? path.join(appRoot, 'node_modules') : undefined; if (!NODE_MODULES_PATH) { NODE_MODULES_PATH = path.join(__dirname, '../node_modules'); } else { // use the drive letter casing of __dirname // if it matches the drive letter of `appRoot` // (https://github.com/microsoft/vscode/issues/128725) if (process.platform === 'win32') { const nodejsDriveLetter = __dirname.substr(0, 1); const vscodeDriveLetter = appRoot.substr(0, 1); if (nodejsDriveLetter.toLowerCase() === vscodeDriveLetter.toLowerCase()) { NODE_MODULES_PATH = nodejsDriveLetter + NODE_MODULES_PATH.substr(1); } </del> <ins> const NODE_MODULES_PATH = appRoot ? path.join(appRoot, 'node_modules') : path.join(__dirname, '../node_modules'); // Windows only: // use both lowercase and uppercase drive letter // as a way to ensure we do the right check on // the node modules path: node.js might internally // use a different case compared to what we have let NODE_MODULES_ALTERNATIVE_PATH; if (appRoot /* only used from renderer until `sandbox` enabled */ && process.platform === 'win32') { const driveLetter = appRoot.substr(0, 1); let alternativeDriveLetter; if (driveLetter.toLowerCase() !== driveLetter) { alternativeDriveLetter = driveLetter.toLowerCase(); } else { alternativeDriveLetter = driveLetter.toUpperCase(); </ins> } <ins> NODE_MODULES_ALTERNATIVE_PATH = alternativeDriveLetter + NODE_MODULES_PATH.substr(1); } else { NODE_MODULES_ALTERNATIVE_PATH = undefined; </ins> } const NODE_MODULES_ASAR_PATH = `${NODE_MODULES_PATH}.asar`; <ins> const NODE_MODULES_ASAR_ALTERNATIVE_PATH = NODE_MODULES_ALTERNATIVE_PATH ? `${NODE_MODULES_ALTERNATIVE_PATH}.asar` : undefined; </ins> // @ts-ignore const originalResolveLookupPaths = Module._resolveLookupPaths;

Discussion:
<!-- 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 <!-- 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: 1.58.1 OS Version: Windows 10.0..1083 Steps to Reproduce: Windows, prepare folders with the following structure (or similar) To make a junction link, use this command , or change to to create symlink And VSCode is installed/unpacked at D:RootVSCode VSCode with image path , and it stuck on the blank page forever. And if start with image path , it runs normally By using , I noticed the following activities ! It seems that it has trouble dealing with symlink paths that producing a wrong one Also, this symlink environment works on 1.57.1 and before but not on 1.58.0/1
Same issue here with this environment: Version: 1.59.0-insider (user setup) Commit: Date: 2021-07-15T05:13:58.348Z Electron: 13.1.6 Chrome: 91.0.4472.124 14.16.0 V8: 9.1.269.36-electron.0 OS: Windows_NT x64 10.0. Additionally If first start VSCode from the target of the junction/symlink VSCode start as expected and if keeping that instance opened, try to open another instance of VSCode but starting from the junction folder this time VSCode opens correctly even if started from the junction
Thanks for the repro steps, this is a variation of but only when the symlinks are on different drives. Will look into it.

The problem here is that nodemodules path are messed up because of The above condition should normally work fine even for symlinks from different drives but if is incorrect then things could go wrong horribly. That exactly what happened, electron does not set the correct value of if the renderer protocol is not in the renderer process is based on the command line of the program so it will not resolve the symlink directory.
As temporary workaround affected users can do the following steps, 1) Open or depending on the insiders or stable version. 2) Add in the json structure 3) Restart vscode.
I wonder if a pragmatic fix here could be to put both the lowercase and uppercase variant of the drive letter into the array and not rely on at all.
Hm, so the code using came in from via but unfortunately it lacks a description as to why this change was made. I can only speculate that the intent is to ensure the drive letter casing matches the one uses internally (as obtained from ). But if that is true, my suggestion of simply pushing both case variants into the paths array seems dangerous because we end up potentially using the "wrong" casing in the paths array as we did before. As for loading files from disk I would assume that it really doesn't matter for whether the drive letter casing is uppercase or lowercase, both should work. I conclude that we should wait for Alex to come back and comment on this before making changes. Users that are suffering from this issue will have to remain on the stable version until we figured this out properly.
As a mitigation I will push a change such as this: To ensure we are not accidentally picking the wrong drive letter.
I believe generated in the renderer by contained drive letters with mixed cases because of this very old bug and I think wanted to fix the drive casing based on so that we are able to match here Lets wait on for confirmation and I think we might be able to remove that condition all together as we always add asar path for and also I am no longer able to repro the mixed cases from that very old nodejs bug. So it might be a completely different issue that was addressed in
/verified