Reproduction: The title is a bit mysterious, so to see what my issue looks like, run "Furmark", or "BOINC" (gpu accelerated) and then start opening Windows. Everything becomes slower, windows parts get drawn slowly, and so on.

  • Opening a new Explorer takes a lot longer.
  • You almost see the window get drawn slowly.

The question is: What can cause slow window/elements draw speed, and how can one track and solve this issue?

When does it happen: When I heavily multitask. When I boot the PC, it's snappy. Even if I put load on it, it does not slow. Only if I start to work on a project with 3-4 kind of loads open.

  • RAM usage is normal, around ~15GB used out of 24GB.
  • CPU is mostly idle / ramping up and down; i7 4770HQ with HT enabled.
  • Temperatures are fine, no throttling.
  • GPU1 and GPU2 are both idle, both receive very low load.
  • The integrated GPU has 128MB dedicated VRAM, 2GB shared, but it's ~10% filled.


  • Storage: 2x240GB SSD; 1x1TB 7200rpm 2,5 in bay; 1x2TB 7200rpm external USB3 dock; 1x1TB 7200rpm 2,5 in enclosure; (take that, mac users)
  • CPU: i7-4770HQ - stock values - HT enabled.
  • RAM: 2x4GB + 2x8GB DDR3.
  • Motherboard/model: ASUS G750JZ
  • GPUs: Intel HD 4600 (512MB ASUS TurboMaster) + Nvidia GTX880M (4GB vram)

OS: Windows 10 - 10.0.16299 Build 16299

Thought maybe it's Chrome and Vivaldi (and the other Chrome/Blink engine apps) that fill up the VRAM and then cause slowdown, but as I said Task Manager comes back without any proof. Games also run just fine while this happens, so there is no noticeable 3D performance loss coming out of the situation.

  • @JMY1000 It's possible that it's the GPU, but what's a good way to test it? I tried GPU-Z and the new "Fall Creators Update Task Manager", but I cannot find anything in these programs. Like vram, load, everything looks normal.
    – Apache
    Dec 5, 2017 at 9:26
  • Try using CAM or Open Hardware Monitor, they've done well in reporting GPU usage, and it's a good check to make sure it's not one funky app. GPU-Z should work though, if you're not seeing anything there, I'm not really sure. Perhaps it has something to do with your odd memory config? Are the sticks identical except for size?
    – JMY1000
    Dec 5, 2017 at 9:31
  • 2
    Though this question was posted years ago, I, too, am seeing exactly the same kind of behavior on a laptop with an NVIDIA GeForce GTX 1650. If I launch, use, and close programs that use the GPU, after a while GDI/UI painting gets extremely slow even with nothing using the CPU, 50% memory available, low CPU usage, etc. Very odd.
    – GuyPaddock
    Apr 2, 2021 at 17:07

3 Answers 3


Windows 10 Fall Creators updates enabled by default Control Flow Guard (CFG) to all applications. Disabling this CFG force can also improve performance. To do this open the Windows Defender Security Center, now select App and browser control and click on Exploit Protection settings

enter image description here

and now set the value for CFG to Off by Default

enter image description here.

Now reboot and Windows 10 should be faster.



I had the same problem on my laptop. I always heavily multitask, and I have a somewhat powerfull laptop. The latest benchmark that I did put this machine on in front of most cheap laptops that are sell at 300-400 euros, with far less RAM.

  • Core i7 3940XM - Benchmark is OK (CPU-Z, etc).
  • 16 Gb RAM DDR3 in dual channel
  • SSD SATA Samsung 870 EVO - Benchmark is OK, 500 Mb/s.

In fact, the thing that was susprising me is that on a "cold boot" the computer would be somewhat snappy. But the more I multitask (usualy 6-7 programs open at the same time, because I have monitoring programs and automatisation programs) the more it would become insanely slow and jerky.


When you multitask, opening a window is very slow. Opening a new tab in Chrome is slow, swaping between windows is slow and jerky. If feels like the CPU is underclocked at 800 Mhz, on battery with all but one core turned off.

But, the funny part is that benchmarks are more than OK, and benchmarks don't show any sign of underclocked CPU, or GPU. Task Manager don't show no high CPU usage, or disk usage, memory consumption can be high but even after closing most of programs the PC will still be slow.


I feel like there is a bug in Windows (or a very bad programmation algorithm), as if the more GUI objects are displayed on the screen, the Windows algorithm is so bad/unoptimised that it lags with an insane high GUI object count.

I did some research, and the best way to know the load concerning the number of objects on the screen, is to go in Task Manager and to display a special column called "GDI Objects". On one user account where I don't have this problem, there are 3200 GDI objects in total. On another user account where I have this problem, there are 8400 GDI objects in total. This isn't unfortunately linked in the Task Manager to either CPU either GPU load. The CPU can be totally idle, but the computer will lag.

Update This post was originaly written in ~2017. In 2023, I was still having the same issues, so I did some more reasearch. My conclusion is that, this is due to a mix of GDI objects leak and GDI object excess. Each user session in Windows gets a maximum number of GDI objects. The sessions are like virtualized, or if not they are limited. Whatever the real reason behind, when a user space reaches 10000 GDI objects (by default), it starts to throttle, a sort of "rate limit" of graphic objects, hence giving slowness and graphic glitches altought the CPU/GPU/Ram loads are fine. 3D games (i. e. speficically, so not 2D games) are special, so 3D games will run at full speed even if reaching this limit. This will mostly affect desktop performance. There are some regedit key to increase this value : GDIProcessHandleQuota is an example. But note that those keys sometimes changes at every major OS version. As of Windows 10 (confirmed) and probably Windows 11, those keys are valid.


  1. Change registry keys. This is the first solution and the working one for people having the same issue. The problem could simply be that the maximum number of GDI objects per session is limited. When the user is at the limit, Windows would simply slow down the rendering of desktop objects, a sort of rate limit, in other words while CPU/GPU/Ram loads (and benchmarks) are fine. There are some keys to increase the limits (further testing required, I didn't test them for the moment), for example GDIProcessHandleQuota. This hypothesis explains why creating a new user session, or rebooting, or monitoring the number of GDI objects works. Removing CFG (and siblings) works also because it could reduce in some way the system load in heavy usage, making the system feel still snapy even with the "rate limit". The keys are :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows USERProcessHandleQuota GDIProcessHandleQuota USERNestedWindowLimit

Same keys in :

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\Windows

Then change keys in :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management SessionPoolSize SessionViewSize

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems Windows, increase the middle value of "SharedSection"

  1. Monitor with GDIView. By using Nirsoft GDIView, there is a way to monitor this behaviour but there are some behaviors that I don't understand with GDIView (what Task Manager shows is not strictly equal to what GDIView shows). Here is a simple Windows command line example to calculate the total amount of GDI objects with GDIView :
GDIView.exe /scomma %temp%\data.txt
set a=0
for /f "tokens=17 delims=," %i in ('type %temp%\data.txt') do set /a a+=%i
echo %a%
  1. Disable CFG. Obviously, I disabled CFG. This give me a small performance boost, but the problem persisted.

  2. Create a new user account. This is by far what works very good. It seems that the Windows GUI display code part is seriously overwhelmed when there are a lot of objects to display, but this works per user session. If you create a new user session, and use one session for the heavy tasks (heavy automation, multiple Firefox/Edge/Vivaldi/Chrome tabs) and one for light tasks, the problem is totally solved.

PS : old OS like Windows XP doesn't seem to have this problem at the extent of Windows 10/11. This seems to be linked to the way Microsoft implemented GDI/DirectDraw in Windows 10/11. It could be also Windows XP have far less graphic intense desktop, thus the performance is better when doing intensive desktop tasks.

  • 1
    > "If you create a new user session, and use one session for the heavy tasks [...] and one for light tasks, the problem is totally solved." Can you please elaborate on this? How is the problem better when the "session for the heavy tasks" is active -- this session would then suffer from the same lagging again, wouldn't it?
    – David.P
    Mar 2, 2022 at 10:56
  • 1
    I don't know if my post was later edited by someone but the answer is in the post, and at todays date, I confirm that having multiple user sessions (or to do a logoff then login cycle) solves the problem. My understanding is due to user virtualisation, I don't exactly know the correct technology name in Windows, but here is a link : techcommunity.microsoft.com/t5/ask-the-performance-team/… In other words, each user session is sufficiently "isolated", at least GUI level, to prevent the GDI object overhead to affect other sessions. Feb 22, 2023 at 12:11
  • After further research, the reason could be the maximum number of GDI objects per user session. So this could be considered as a sort of isolation of the user space, but not really. So when a user space reaches 10000 GDI objects, it starts to throttle at a 100% software level the speed of rendering of graphic objects, hence giving slowness and graphic glitches altought the CPU/GPU/Ram loads are fine. There are some regedit key (I didn't tested them yet) to increase this value : "GDIProcessHandleQuota" is an example. But those keys sometimes changes at every major OS version. Feb 23, 2023 at 10:29

I don't have enough reputation to comment under the accepted answer, but shall notice that one can't simply "enable CFG for all applications".

Binary must be compiled with /guard:cf to actually take advantage of it.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .