Code change:
<!-- Do you have a question? Please ask it on --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.23.0-insiders x64 commit OS Version: Windows 8.1 x64 After update to latest version window is empty (only main menu bar is visible). Renderer process consumes 16-20% CPU but nothing is changing. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
can you run "" from the command line and see if any output is printed?
The output is here:
adding for the (maybe unrelated) spdylog stacktrace that shows up. can you share a screenshot how VSCode looks after it started like this?
!
does it make any difference if you run with "" from the command line?
That literal looks weird. It looks like the user has a problem in one of his variables, possibly . Whats the value of your HOMEPATH variable?
Visually nothing is changed. In console also nothing. is not presented. Username is , but profile folder named as .
does it make any difference if you run "" from the command line?
Yes. Window is opening like normal new profile. My profile is broken. Nice. ! UPD: Erased my old profile. Nothing. Same situation. So, trouble is Cyrillic symbols in path to profile folder.
to verify that can you use the argument with a folder that has the Cyrillic characters and see if you get the same results?
Yes. Launch with Cyrillic characters in path give same result.
it would be easier for me to reproduce if you could post the exact Cyrillic letters that you are using in here as text so that I can copy it.
Here it is: .
I can reproduce and the reason the workbench is not coming up is due to spdylog crashing very early. To reproduce run ""
Just to confirm, you could reproduce by using cyrilic in a path provided to ?
I can. Command: Result:
yes
I can confirm I have an identical problem. My username contains the character 'ø', which now makes the insiders build fail to start. Changing the to a path which does not contain that character fixes the issue. However, the Windows context menu action does not work, as the argument is only provided on the shortcut. The stable release (1.22.2) works as expected. EDIT: I fixed the context menu issue manually in the registry, so everything is back to normal for now :)
I pushed a workaround for now to not crash so badly when we fail to instantiate the spdylog writer. Turns out we already had code in place to protect from failing loads thanks to Alex, but the output channel was failing very early on. fyi maybe you want to quickly check my changes via The real fix probably needs to go into spdylog, pushing to May since this was already happening in stable.
This will break Output channels when not writing into file. When user switches between output channels, they will become empty as there is no way to retrieve content now
I was falling back to old way of writing into channels if fails. I removed this fallback this milestone . You can get that back. But I would really want to remove this fallback because for further enhancements to output channel which depends on spdlog.
this is not a real fix, I would expect some regressions. Previously VS Code would not start at all without my workaround. Do you think the current behaviour with my fix is worse than before? I think its clear that we will work on a fix for May.
IMO The better workaround would be to bring back my fallback . I was doing the same as you except that I fallback to old way of writing into Output channels. This will not have any regressions as it was there in last milestone. When we fix it in May, we can remove the workaround.
Sorry, I am confused. May I know if this issue is due to Loading of spdlog library OR spdlog fails to create a file
I see the workaround is if spldlog fails to create logger/file. So I think it is better to use my fallback.
Pushed the previous workaround I was using. As said, this will not break output channels if there is an issue creating spdlog logger.
I don't see issues running dev with a user-data-dir containing a non-ascii character (eg ) any more. I do not understand if this is because of your workaround or if the new spdlog version actually fixed the issue. Moving it to you in order to check if the issue is fixed already, since I don't understand how to repro.
I too do not see any issues after removing the workaround I before for the crash. Hence removed the workaround. To verify: Open VS Code using an user directory that has non-ascii character (eg ø) Verify that VS Code starts normally and the output channels are properly written Verify that there is no crash
Reopening this as the crash from spdlog is not fixed.
I still see following error in the console with our log files Edit: This is seen in the console even with the workaround. Workaround just mitigates it by falling back to old output channels. Logs will not work though.
Updated node-spdlog library to support in file names. Thanks to for hinting it. With this crash no longer occurs with non ascii or special characters (tested with all reported characters). Added a smoke test to launch VS Code with special characters in user data dir.

Related discussion:
text: version "1.0.0" resolved "https://registry.yarnpkg.com/sparkles/-/sparkles-1.0.0.tgz#1acbbfb592436d10bbe8f785b7cc6f82815012c3" <del> spdlog@0.7.1: version "0.7.1" resolved "https://registry.yarnpkg.com/spdlog/-/spdlog-0.7.1.tgz#960b8cdced12e8c482d1df9fa65220789f276979" </del> <ins> spdlog@0.7.2: version "0.7.2" resolved "https://registry.yarnpkg.com/spdlog/-/spdlog-0.7.2.tgz#9298753d7694b9ee9bbfd7e01ea1e4c6ace1e64d" </ins> dependencies: bindings "^1.3.0" mkdirp "^0.5.1"