Vscode: VSCode freezes when switching from Chrome to it

Created on 14 Jun 2017  ·  58Comments  ·  Source: microsoft/vscode

  • VSCode Version: 1.13
  • OS Version: Win10

Steps to Reproduce:

  1. open VSCode
  2. work a couple of minutes
  3. move to another app (chrome)
  4. move back to vscode = freezing for 10-15 seconds

I have tried to run with the disable-extensions command, clean installed it, closed minimap, tried the insders version - nothing helped.

Can you suggest a way to find the cause ?

Windows is operating normally in the meantime, nothing else is frozen.

*not-reproducible electron freeze-slow-crash-leak gpu needs more info upstream

Most helpful comment

It's funny but it seems that issue was on chrome, my hangs issue gone after updating the chrome, switching between chrome and vscode back and forth and editing works fine now.

update: freezes came back after few hours of coding. it seems the problem often occurs when i'm playing videos on the chrome and switch to visual studio code for programming.

Disabling the chrome hardware acceleration may potentially fix the problem(for now, problem can be more deep than it seems, something with GPU hardware acceleration, because it will reappear in when you doing graphics intensive tasks).

go to chrome settings and uncheck checkbox which says Use hardware acceleration when available

update 2: It turns out vscode is also using the hardware acceleration on GPU, another workaround is by disabling hardware acceleration on vs code by launching the IDE with --disable-gpu flag

Workaround 1
Disable the hardware acceleration on chrome if issue is while running chrome parallel with vscode

Workaround 2
If you really need to run any other Webgl or GPU task run with code with --disable-gpu flag.

All 58 comments

this is not an insiders only problem. the label is not appropriate.

Here is a checklist to find out more about the freeze/slow/crash

  • [ ] it reproduces with extensions disabled (code --disable-extensions from the command line - NOT the integrated terminal of Code)

    • if it does not reproduce with extensions disabled, you can stop testing and report this!

  • [ ] it was not happening in the previous stable release
  • [ ] it reproduces in insiders builds (get it from here)
  • [ ] there is no suspicious output when running from the command line (code --verbose)
  • [ ] there is no suspicious output in the window itself (Help | Toggle Developer Tools | Console)
  • [ ] it reproduces on Windows, Linux and Mac
  • [ ] it reproduces after deleting <appdata>/User/keybindings.json and <appdata>/User/settings.json (backup first! see below for paths)
  • [ ] it reproduces when opening empty (code -n from the command line)
  • [ ] it reproduces opening any folder
  • [ ] it reproduces opening any file
  • [ ] it reproduces when only having a single window open
  • [ ] it reproduces by just using Code without external tools running on the same folder
  • [ ] it reproduces from a workspace that is not under Git version control
  • [ ] it reproduces independently if a file is opened or not after startup
  • [ ] it reproduces when running with GPU disabled (code --disable-gpu)
  • [ ] it reproduces when being offline
  • [ ] it reproduces when disabling the file watching (set files.watcherExclude to "**/**": true)
  • [ ] it reproduces after uninstalling and reinstalling
  • [ ] it reproduces after deleting the application data directory (backup first! see below for paths)
  • [ ] I have not played around with permissions or ran Code as administrator
  • [ ] I am seeing a single CPU process spin high (please share the full command line arguments)
  • [ ] I am seeing Code consuming lots of memory in a short time

Application Data Directory for VS Code:

  • Windows: C:\Users\<user>\AppData\Roaming\Code
  • Mac: /Users/<user>/Library/Application Support/Code
  • Linux: /home/<user>/.config/Code

Application Data Directory for VS Code Insiders:

  • Windows: C:\Users\<user>\AppData\Roaming\Code - Insiders
  • Mac: /Users/<user>/Library/Application Support/Code - Insiders
  • Linux: /home/<user>/.config/Code - Insiders

thank you Benjamin I will run thru this in the next 24 hours sometime and report back

Same problem. I find when vs code is freezing, tap on the touch screen can make it unfreeze.

Same problem. It doesn't just hang. If I scroll the page and then switch to other app, then back to vscode, page is actually scrolled.

Unfortunately I have to join this club. VS code just gets idle/frozen and I gotta alt+tab several times or try to click/scroll to get it back up...

Edit:
I switched to Atom after becoming frustrated with this. However, I only ended up facing the same issue with their client.

Please refer to:
https://github.com/atom/atom/issues/9544

The problem seems to originate from a git routine. I wonder if the same problem is behind VSCode freezing. The issue was just about the same for me. This doesn't happen in VSCode projects without git.

Solution in this case was: https://github.com/atom/atom/issues/9544#issuecomment-254378382

I know this is from another product and excuse for bringing it up here, but this sort of issue can be very infuriating.

@icyJoseph thanks for sharing this. I can confirm that Atom does freeze the same way for me too. Unfortunately I don't know if the atom solution mentioned in the comment can be somehow replicated in vscode. if anybody knows, please share.

By the way, my workaround is (in Win10) to create a second desktop where only vscode is opened, and instead of ALT+TAB I use Windows+CTRL+LEFT/RIGHT to swap between desktops... Now in this case luckily vscode never looses focus, so there is no problem. But this is quite embarrassing considering the Microsoft hardware (Surface 4) running a Microsoft OS running a Microsoft software.

@bpasero I think the above information may help further investigation from your side - is this enough for checking please?

Potential Work Around:
I set git.autofetch to false in settings and have not seen a lag yet.

Details: I had exactly the same issue. Seemed to happen after a major windows 10 update. Alt-Tab was the issue exactly, when I change focus back is lagged then finally it shows up. Using MartonEstok's work around resulted in no lag. When I tested projects with no GIT repo, no lag - which points to the GIT update process being the culprit. With that, disabled autofetching and seemed to do the trick.

Does this still reproduce?

yes, it does. 1.18.0 on win 10 pro, disabled all extension.

For me it started about two weeks ago.

Seems to be something with tab swithing / tab gains focus. It freezes a few times a day when doing a Ctrl-Tab, or a Alt-Tab.

Yes, I understand you need more info to debug, but unfortuantly this is all I got, just wanted to let you know this is still a issue.

@larserikfinholt but this only reproduces if you jump to chrome and then back, right? Not with any other app?

Since the last chrome update I haven't had this issie

On Nov 17, 2017 2:05 AM, "Benjamin Pasero" notifications@github.com wrote:

@larserikfinholt https://github.com/larserikfinholt but this only
reproduces if you jump to chrome and then back, right? Not with any other
app?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/28709#issuecomment-345153736,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKNmkFSih8ybw7QrcywrymTk7f5uOgDmks5s3SIIgaJpZM4N5po3
.

I'm experiencing this issue also. Although for me the hang is generally between a few hundred miliseconds and a few seconds. The only thing that appears to fix it for me is launching with --disable-gpu. I've ran it through the profiler in the dev tools and it does indeed seem to hang on the GPU.

I don't have any GPU problems anywhere else. Running an Intel based GPU on a System76 Galago Pro laptop (KDE Neon distro).

VS Code was freezing for me every few minutes. Alt tabbing away and back unblocks it.

As @Divni suggested --disable-gpu fixed the issue.

@bpasero

reproduce:

  1. open a 3D game or WebGL app that uses GPU intensively.
  2. focus vscode window

It's funny but it seems that issue was on chrome, my hangs issue gone after updating the chrome, switching between chrome and vscode back and forth and editing works fine now.

update: freezes came back after few hours of coding. it seems the problem often occurs when i'm playing videos on the chrome and switch to visual studio code for programming.

Disabling the chrome hardware acceleration may potentially fix the problem(for now, problem can be more deep than it seems, something with GPU hardware acceleration, because it will reappear in when you doing graphics intensive tasks).

go to chrome settings and uncheck checkbox which says Use hardware acceleration when available

update 2: It turns out vscode is also using the hardware acceleration on GPU, another workaround is by disabling hardware acceleration on vs code by launching the IDE with --disable-gpu flag

Workaround 1
Disable the hardware acceleration on chrome if issue is while running chrome parallel with vscode

Workaround 2
If you really need to run any other Webgl or GPU task run with code with --disable-gpu flag.

Had a similar issue, Visual Studio Code would freeze the system if left open, and almost immediately if minimized and then pulled back into focus. Leaving it frozen for hours showed no changes. The mouse would move, audio would continue playing, and I was sometimes able to regain control with ctrl/alt/delete (no visible change), followed by unplugging my HDMI monitor so everything shifted to my second monitor, which would display the ctrl/alt/delete screen.

After disabling hardware acceleration in Chrome and in Visual Studio Code, I haven't seen this again.

Thanks for the suggestion @Divni

I am encountering this issue specifically with background WebGL canvases being actively updated in other browsers in the background on a Surface Book, whether that other browser is Chrome or Edge. VS Code is responsive until I attempt to drag any amount of selection. This also happens whether or not I force Chrome to open using the Surface Book 2's GTX 1050.

Since WebGL is specifically at play here and my work involves it, disabling hardware acceleration is not a workable solution for me.

I ran a Performance profile on Chrome, which is also freezing during window switching between VS Code and http://regl.party:

image

You can see the very long GPU steps on the timeline when I switch between VS Code and Chrome. These are oddly categorized as "Other" in the summary donut chart.

I would wager a guess that this is a bug in Chromium/Electron reacting poorly with the Intel graphics driver. This problem doesn't occur on my desktop, which is only using a dedicated GTX 1080 with NVIDIA's driver on Windows 10. If the problem exists on Linux, though, I'd lean further on this being solvable on Chromium upstream; ANGLE is used on Windows in both Chrome and Electron, so it's likely _not_ Intel OpenGL related.

I tested Edge with the same site, http://regl.party, and found that while Edge doesn't necessarily _freeze_, it does experience some hitching. Bravo Edge devs, but we can't just tell Electron to use Edge for the browser part of course.

The problem does not happen on macOS with Intel graphics and the same testing scenario with Chrome.

Sigh. This is disappointing considering how much money I spent on this laptop...

Possible related Chromium bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=787217

I have created another Chromium bug to track this in case it's different: https://bugs.chromium.org/p/chromium/issues/detail?id=823192

I'm from Intel Web Team and trying to investigate this issue as it's reported in Chrome: crbug.com/823192. Can anyone help to add option "--disable-features=GpuScheduler" instead of "--disable-gpu" to vs code to see if the issue can still be reproduced? Thanks!

@gyagp I've been wrestling with this issue recently, and confirm that for me, "--disable-gpu" does resolve the issue, while adding "--disable-features=GpuScheduler" does not. While I have no hard data to back this up, it seems that it might be less frequent with "--disable-features=GpuScheduler" than without, but that's entirely a subjective observation.

@Quantumplation Thank you so much for checking this! So my guess might be irrelevant. I tried both my desktop and laptop, and none of them can repro this issue, which hinders me from further investigation.

Had this issue on my surface pro. Alt-Tabbing between Incognito Chrome and a VSCode workspace (to the text editor to try and type things) caused freezing and delay.

Turning off Hardware Acceleration on Chrome made the transition currently cleaner.

I'm experiencing this issue as well. From what I'm reading it might be a Surface issue and my laptop is a Surface Book. I don't experience this issue on my Desktop or on a Mac. Few other facts, it seems you don't need to alt-tab away. Just selecting a VSCode menu is enough. Also it doesn't matter what you alt-tab to, as I'm typically doing that to a command window. I also don't have Chrome running.

Using the --disable-gpu does however seem to resolve my issue. So thanks guys!! :)

Hi everyone! I faced the same issue (on a Asus laptop, so that is not Surface-related) switching with both Chrome and Firefox. Using --disable-gpu did the trick as well.

I have the exact same issue when working on WebGL on Edge/Chrome. Disabling hardware acceleration on browser (not possible in Edge, as far as I know) and/or on Visual Studio Code fixes the issue. However, disabling hardware acceleration on vscode seems to stress a little bit the CPU, hence the CPU fan starts working which is quite frustrating when working on silent environments.

What I am trying now, because my laptop has a d-GPU in addition to i-GPU, is to use the d-GPU on the browser and i-GPU for vscode and everything else, or just use the d-GPU for vscode. The Nvidia control panel allows these per-application settings. So far seems to work well.

Edit: I don't own a surface

Edit 2: Another observation, which I think wasn't mentioned. The problem seems to be caused when switching between applications using hardware acceleration. If I am working on chrome with hardware acceleration and then switch to Windows Explorer before going to vscode, the issue goes away, from my experience.

Same here. The issue very annoing will try to use --disable-gpu maybe will help. Totally the same symptoms what others have here. Looks like chrome app (inside electron or any other) not designed to work well with any 2+ tabs which utilize GPU. They have some kind of conflict in competition for GPU resources, and as result - window and whole operation system totally freeze. I can move the only mouse. Reboot or logout via power button helps, but the most annoying part, that this is freezing the whole response from operation system too (1804, 17133, Win10, antiviruses not related to the issue), which make mostly impossible to debug the issue and trace real cause of the problem.

Same issue.
Steps to reproduce:

  • Use chrome to open the index.html with a canvas and stay here for a few seconds. index.zip
  • Switch from chrome to vscode
    VS Code freezes for a few seconds. Using --disable-gpu can fix it.

VS Code version: Code 1.23.0 (7c7da59c2333a1306c41e6e7b68d7f0caa7b3d45, 2018-05-03T16:44:55.614Z)
OS version: Windows_NT x64 10.0.16299


System Info

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz (4 x 2304)|
|GPU Status|2d_canvas: enabled
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
native_gpu_memory_buffers: disabled_software
rasterization: disabled_software
video_decode: enabled
video_encode: enabled
vpx_decode: unavailable_software
webgl: enabled
webgl2: enabled|
|Memory (System)|7.89GB (4.33GB free)|
|Process Argv|C:Program FilesMicrosoft VS CodeCode.exe|
|Screen Reader|no|
|VM|0%|

Same issue.
I can add that it only happens when CSS files have been opened in a session.
Does not occur for me when using .cs, .fs, .ts, .js, .html (without inline styles)

Temporary Fix: Run this command in the terminal, not the integrated terminal. code --disable-gpu.

I am also experiencing this very issue when switching screens from VS Code to Chrome. I have two monitors. I'm on Windows 10 using a Razer Blade Laptop.

I would suspect this is a Chrome update causing the problem because when switching from Chrome to any other Electron type app, I get the lag / freeze within that app.

I also encountered this problem.
version: 1.23.0
os: win10 1803 x64

开启硬件加速的情况下,关闭 chrome 时 intel GPU 占用瞬间达到 100% 后立马下降。如果不开启硬件加速,就没有这个问题。这是我了解的情况,不知道是否和这个有关。

我遇到这个问题,是在升级 win10(1803) 之后。似乎是 win10 或者是 Intel 显卡驱动的问题,在降级驱动程序之后发现问题缓解(目前都没出现卡死情况)。

Intel 最新的驱动程序,就会有这个问题。

@gyagp

Not sure if this update helps: I experienced this issue and posted here Feb 19. Two weeks after that I reformatted my computer and have yet to come across the issue again using all of the same VSCode extensions/settings. It's a work computer and I follow environment setup steps I wrote to get my dev devices to the same state. The only differences I can think of this time around is I'm no longer in the Windows 10 insider program, I haven't been following all of the intel hardware updates, and fresh install of Chrome versus updated.

encountered same problem after upgrading to Windows 1803

I ran into the same problem after I upgraded to 1803.
on a thinkpad

Okay, this is Windows issue.
https://answers.microsoft.com/en-us/windows/forum/windows_10-win_cortana/some-devices-may-hang-or-freeze-when-using-certain/612a341b-340a-4ac0-8866-df5346327a52?auth=1

If someone experiences the issue, and their PC freeze, just press:

Win + CTRL + SHIFT + B

the combination, it will refresh display and reconnect display and your PC will unfreeze

https://www.reddit.com/r/Windows10/comments/8gf68w/chrome_freezes_windows_after_april_update/

@anacondaqq Sorry, I don't think that's the same issue as this. This problem started occurring long before the April update and does not involve a total freeze.

Could this be related to Intel driver version? I cannot remember having this issue before upgrading to the latest Intel drivers on my SB2 dGPU. This fits with the experience @TENsaga has, as far as I can tell

@HybridEidolon personally me is can confirm that this happened only to me since insider builds (I'm insider tester) and I reported about that earlier, but nobody listened to me since maybe January to Microsoft. Right now I cannot even find my reports what I sent (WTF), because forgot account from what I have sent them. I have full setup at my PC which helps me to switch windows versions on real hardware in 5 minutes, so testing Insider Builds was not a problem to me, and I always switch back to 1709 when start to receive a lot of pain. One of the reasons for such pain was this issue. So I can totally confirm personally again for my own situation, that the issue happened since January, and never reproduced on 1709. But always can reproduce it on Windows 1803 (or 1804 how it's called).

I can confirm that the issue exists on next builds:
All builds starting from 17115 up to 17134.48
Before 17115 I did not test, but on all of these builds I can confirm and guarantee that the issue exists. At the same time with the same software version on Win10 1709, I can not confirm the issue.

@anacondaqq sounds promising, as I mentioned above I had this issue around Feb 19, followed by a full reimage. Since then I have not signed up for the insider builds, and the issue has not returned.

Do you have onboard Intel graphics with the latest Intel drivers?

chrome_2018-05-09_14-14-30

I haven't installed that last graphics driver since reformatting.

@geirsagberg what version are you currently on?

Hi Guys,
thanks for this post, I had the same issue, " --disable-gpu" worked for me.

For me the problem is fixed after upgrading to Windows 17134.48

Windows 17134.1, Chrome 67.0.3396.99, VSCode 1.24.1. CPU - i7 7700. Same problem.

I also have this issue. Constantly freezing with file types such as: .cs, .ts, .rb, .json, .md.
Disabling all extensions does not solve the problem.
"--disable-features=GpuScheduler" does not work.
"--disable-gpu" works.

Version: 1.25.0
Electron: 1.7.12
Chrome: 58.0.3029.110
Node.js: 7.9.0
V8: 5.8.283.38
Architecture: x64

LENOVO ThinkPad T570
Microsoft Windows 10 Pro 10.0.16299 Build 16299
i7-7600U CPU
16.0 GB RAM

Frozen for me too. Closing and Re-opening does nothing. But after doing this 3 times started working again. I think the culprit might be Ctrl+K - I noticed that it waits for another key to be pressed (contra to it being listed as a shortcut in the File Menu) so I think this might be making the console hang.

Can report that this issue is happening for me aswell when PixiJS is running in an open tab with OpenGL mode. Disabling GPU acceleration in Chrome fixes the problem.

The same keep happening to me as well, i keep reopening, can this be fixed, please

Same issue today (OSX), with a first encounter being yesterday. Acts like a memory leak. I haven't installed any new software on the machine, or any new plugins into VS Code. I had no files open in Code, just an empty/new editor. Tabbed to Chrome for a minute then VS Code froze when I tabbed back. I can tab over to other apps and no issues. Eventually, I get a pop-up dialog stating VS Code isn't responding. I click restart and things are back to normal.

I think this is the same issue here, I've noticed that killing the chrome.exe process seems to immediately stop the freezing of VS Code, so the two are definitely linked.

And the inverse seems to also be true, as I've had VS Code cause Chrome to freeze.

I've yet to see VS Code freeze when Chrome is not open, and vice-versa.

Have yet to check this with another browser to see if it's only caused by chrome, but will check soon.

not only chrome, but doesn't freeze up firefox, so it might not be inherently linked to it, but whatever it is causes the issue on switching focus between windows and between internal frames of vs code.

When VS code freezes up whilst running Firefox, instead it causes any new pages attempted to open to take a long time to load, but there's no crashing or stalling in firefox.

And it seems VS code stalls far less often. I've still seen it happen, but it's like 1 in 20 times rather than 4 in 10.

I'm pretty sure it's an OpenGL thing. Not necessarily with OpenGL itself, but perhaps with the implementation. Try disabling it in your browser.

not an opengl thing as far as I can tell, disabled it on VS code and in-browser flags, still causing issue.

in vscode by adding --disable-gpu --disable-gpu-compositing as params to the shortcut. in browser via the flags option.

@GeorgeWL Hmmm, interesting... I was able to get it working by disabling OpenGL.

same issue with the latest VS Code build on plain X11

Version: 1.31.1
Commit: 1b8e8302e405050205e69b59abb3559592bb9e60
Date: 2019-02-12T02:19:29.629Z
Electron: 3.1.2
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Linux x64 4.18.16-300.fc29.x86_64

and both Chromium 71.0.3578.98 and Chrome 74.0.3710.0

but the --disable-gpu workaround works fine here: I'm then able to debug without the application freezing on me.

I don't know whether it might be relevant in any way but when I don't disable the GPU acceleration, Chromium outputs that on start:

/usr/lib64/dri/hybrid_drv_video.so init failed
Not using hybrid_drv_video.so
[12993:12993:0220/231135.360408:ERROR:vaapi_wrapper.cc(343)] This build of Chromium requires VA-API version 1.3, system version: 1.4
[12993:12993:0220/231135.516673:ERROR:sandbox_linux.cc(364)] InitializeSandbox() called with multiple threads in process gpu-process.
[12993:12993:0220/231135.823072:ERROR:gl_surface_presentation_helper.cc(237)] GetVSyncParametersIfAvailable() failed!
...

P.S. Here's the output of vainfo:

libva info: VA-API version 1.4.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_3
/usr/lib64/dri/hybrid_drv_video.so init failed
Not using hybrid_drv_video.so
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.4 (libva 2.4.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Sandybridge Mobile - 2.2.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264StereoHigh         : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

This happens to me multiple times daily, on macOS Mojave, latest official build. It's beginning to really drive me nuts. I guess I'll disable GPU if it keeps happening but this should be a higher priority fix

I haven’t had the issue since upgrading VS Code.. but I believe there have been several updates since my initial report. Also, I am still on OSX 10.13.6 [Sierra].

We hope you found this email of interest; however, click here if you wish to unsubscribehttp://www2.smartbear.com/SubscriptionCenter.html?utm_source=outlook&utm_medium=email&utm_content=emailsig or manage your email preferences. Privacy Policy.https://smartbear.com/privacy/

We are building exploration builds that use a much newer version of our UI framework (Electron version 6.0.x). I wonder if this issue reproduces with one of these builds, could you try? Download:

I haven't been able to reproduce this in neither 1.38.1, insiders (1.19.0) or the exploration build you linked, all on Ubuntu 18.04.2. This issue haven't happened for me for almost a year as well.

We closed this issue because we are unable to reproduce the problem with the steps you describe. Chances are we've already fixed your problem in a recent version of VS Code. If not, please ask us to reopen the issue and provide us with more detail. Our issue reporting guidelines might help you with that.

Happy Coding!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sijad picture sijad  ·  3Comments

lukehoban picture lukehoban  ·  3Comments

borekb picture borekb  ·  3Comments

trstringer picture trstringer  ·  3Comments

chrisdias picture chrisdias  ·  3Comments