9879: GDI Objects resource leak in explorer.exe (directly affects Taskbar) RRS feed

  • Question

  • Update 1 (Nov 18): The leak seems to be exacerbated by the use of a progress bar within a given program's taskbar icon. For example, downloads with a browser show such status. In particular, media players often do this too, and since people tend to use media players for an hour or two at a time, the problem can worsen quickly when in use.

    ===========(Original message below)

    Twice in one day I've seen GDI Objects (as shown in Task Manager--if you add the column on the Details tab--and Process Explorer) hit 10K for Explorer.exe. The first time was after about 15 hours, the second time about 4.

    What caused me to look was a misbehaving taskbar: icons for some running programs were suddenly either blank or changed, some would do nothing when clicked, the Start menu was barely functional, my quicklaunch shortcut menu didn't work, etc.

    Killing explorer.exe and restarting it allows you to proceed as usual.

    This definitely didn't happen in the preceding builds.

    Further details provided if this turns out to be something that others see.

    • Edited by rseiler Tuesday, November 18, 2014 5:44 PM Update
    Friday, November 14, 2014 6:03 AM

All replies

  • try turning off all live tiles, if your resource went to normal you can turn on live tile one by one to find which app is eating your resource.
    Friday, November 14, 2014 6:13 AM
  • I only  had a couple, but I turned them off. I'll report back tomorrow.
    Friday, November 14, 2014 6:21 AM
  • Happened to me too.

    Icons become blank and/or not responsive to clicks. Restarting Windows Explorer fixes the problem.

    I had hidden the Task Bar Search button when I first saw the problem. I changed it back to shown to see if it makes any difference.

    Friday, November 14, 2014 1:57 PM
  • Thanks for confirming. I suspect more reports of this will trickle in over time.

    MakeMeLaugh, it was a nice guess, but live tiles aren't it.

    Update: I left the PC on overnight with GDI already well on its way (~5000), and interestingly, by morning it had barely moved, so this depends upon activity.

    Once I continued using the PC, it was on the rise again. I think this makes sense since GDI objects are resources such as windows, menus, graphics, etc., and they're dormant when no one's around.

    Friday, November 14, 2014 4:15 PM
  • The average rate of increase with system use tends to be about 1K/hr, though it can transpire more slowly or much faster.

    It would be nice to find a workaround for the problem (I'd even settle for a way to monitor GDI Objects so that a warning could be triggered at 9K), but in researching past leaks it seems to always involve a patch. It's unfortunate that in this case it relates to a central, vital process, as opposed to something that one can avoid using.

    There's a program called GDIView that gives a little more detail about exactly what kind of GDI Objects are involved, and as you can see below, it's primarily Bitmaps.

    Sunday, November 16, 2014 5:33 PM
  • I created a directory called batch in c:. There I put the files for GDIView

    Then I created a bat file called findLeak.bat, there is the code

    GDIView.exe /scomma gdiview.txt
    for /f "tokens=2,15 delims=," %%G in (gdiview.txt) do @if "%%G"=="explorer.exe" set totalExplorer=%%H
    if %totalExplorer% gtr 1000 (
    taskkill -im explorer.exe -f

    This section

    %totalExplorer% gtr 9000

    Will force the closing of the explorer.exe process if it has more than 9000 GDI objects (set this number as you please, don't forget the space after it)

    After this, you can make a scheduled task that runs this little guy. The bad part is that It will close any explorer window you have oppened, but at least it will keep windows usable if you leave it opened overnight.

    • Edited by danmarce Tuesday, November 18, 2014 7:20 AM code editing
    Tuesday, November 18, 2014 7:12 AM
  • I edited the code a little...

    set GDIViewPath=C:\Other Program Files\GDIView\
    set GDIDumpPath=c:\batch\
    set GDIProcess=explorer.exe
    set GDILimit=10

    "%GDIViewPath%GDIView.exe" /scomma "%GDIDumpPath%gdiview.txt"
    for /f "tokens=2,15 delims=," %%G in (%GDIDumpPath%gdiview.txt) do @if "%%G"=="%GDIProcess%" set totalGDI=%%H

    if %totalGDI% gtr %GDILimit% (
    Echo WARTING!! at %date% %time% %GDIProcess% was closed at %totalGDI% and the limit was %GDILimit% >>%GDIDumpPath%Leak.Log
    taskkill -im %GDIProcess% -f
    start %GDIProcess%
    ) else (
    Echo %date% %time% It is safe at %totalGDI% and the limit is %GDILimit% >>%GDIDumpPath%Leak.Log
    This way a log file will be generated and you can check what the process did.

    Also note that now I use:

    start %GDIProcess%

    That was because if the bat is called by a scheduled task this will allow the script to continue and close the command window after starting explorer.exe

    Tuesday, November 18, 2014 7:37 AM
  • Nice idea, thanks.

    It would be easy to have it do any number of things aside from killing the task abruptly (like popup a message), but here's one problem: there are usually multiple explorer.exe's in memory.

    As it stands, it's apt to get the wrong one, so it needs to weigh all of them and set the highest figure to totalGDI.

    Update: edited for clarity given that we were editing concurrently.

    • Edited by rseiler Tuesday, November 18, 2014 8:04 AM
    Tuesday, November 18, 2014 7:42 AM
  • I think I can edit the bat to identify the process ID of processes with over certain number of GDI objects and then close that process.

    Tuesday, November 18, 2014 7:27 PM
  • This one is a simpler version, this just identifies the process with certain number of GDI Objects, try to restart it and saves a log.

    set GDIViewPath=C:\Other Program Files\GDIView\
    set GDIDumpPath=c:\batch\
    set GDILimit=9000
    "%GDIViewPath%GDIView.exe" /scomma "%GDIDumpPath%gdiview.txt"
    for /f "tokens=1,2,15 delims=," %%G in (%GDIDumpPath%gdiview.txt) do ( 
    if %%I gtr %GDILimit% (
    echo %date% %time% The process %%H had %%I GDI Objects, so it is closed for sanity  >>%GDIDumpPath%Leak.Log
    taskkill /PID %%G /F
    start %%H

    I guess that any process with over 9000 GDI objects would be dangerous. This one now closes the adequate PID.

    Now, for me the problem is that Microsoft uses the same process, explorer.exe both for the "Taskbar/desktop" and the, now called, "File Explorer". Have been that way for ages (I think even was like that in Windows95, and a lot of users requested that to be changed, because those are separated tasks)

    Anyway explorer.exe is prone to GDI Leaks, even in Windows 7, the thing was that this particular version seems to be completely out of control.

    It is sad because it is a silly error even for a tech preview. It makes, sometimes, the whole thing almost unusable, defeating the purpose of the tech preview.

    Tuesday, November 18, 2014 8:31 PM
  • Yes, that should do nicely until a patch or a new build next year, whichever comes first.

    There is a way to slow down the train though: to the extent possible, avoid using programs that show progress in their taskbar icons. A particular video player I used was by far the worst offender, with browser downloads (they're much shorter in duration than playing, say, a TV show) coming in a distant second.

    Tuesday, November 18, 2014 11:32 PM
  • Do you have a good/easy way to reproduce the problem (e.g., "run program ABC and do DEF to cause a progress bar to appear")?

    At the moment I've had Win 10 up about an hour and a half, mostly using IE, and I've not seen too big a rise in GDI objects.

    Nice tip on GDIView.  I'm using the Task Manager from the Win Recovery Environment (basically it's the old Win 7 Task Manager but capable of running on Win 8 and 10) and see only 728 GDI objects at the moment.

    Had Windows 10 pop up a couple of "Activate Windows" prompts out of the blue on me earlier today, after it had been running for some hours, though it IS activated.

    This is not the most stable build they've put out.



    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options

    Wednesday, November 19, 2014 12:22 AM
  • Okay, I'm reproducing the problem.   As mentioned in the OP, the handles leak with a passion if something with a progress bar continually updates the Taskbar.



    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options

    Wednesday, November 19, 2014 12:38 AM
  • Yes.

    I did a simple test using Media Player Classic and GDIView.

    I set GDI to autoupdate every 5 seconds and put a video. When the video is playing the taskbar is updated with a progress bar (just like when you copy files). After a few minutes of playing I quickly reached over 5000k GDI objects.

    If I paused the video, the leak stoped (because the taskbar was not updated)

    I guess If I copy a lot of files, just the taskbar updating will replicate the problem. So, it basically seems that the previous objects are not being purged properly.

    I would love to see the code, it might be as simple as somebody commented something in test and forgot to correct it.

    As for MPC, I'll see if it have an option to don't show the progress in the taskbar.

    Wednesday, November 19, 2014 1:29 AM
  • I see y'all are making progress here.  I noticed it for the first time tonight.  I was using uTorrent for the first time with Windows 10.

    I noticed that each 'tick' where uTorrent would update the transfer stats the number of GDI objects in explorer.exe would increase by two.  Closing uTorrent stopped the increase immediately.

    uTorrent doesn't update the task bar like file transfers or a video.  However it does update it if you hover the mouse cursor over it so I'm guessing it's related to the same issue.

    Ezzy Black

    Wednesday, November 19, 2014 1:32 PM
  • For uTorrent, maybe use the option that minimizes it to the tray instead?
    Wednesday, November 19, 2014 5:25 PM
  • For uTorrent, maybe use the option that minimizes it to the tray instead?

    Very interesting.  You are absolutely correct.  Minimizing to the tray stopped the increase in GDI objects.

    A little more proof you have found the correct issue as one program will have different behaviors depending on how it's used.

    Ezzy Black

    Wednesday, November 19, 2014 9:48 PM
  • here are some pictures of the bug...

    the first time I saw this bug was in Windows 98SE!, and is funny that now after several years the bug is back in Windows 10 Technical Preview!.

    now I'm wondering if somebody have introduced legacy code from Windows 98SE to Windows 10 Technical Preview ?

    my report: http://answers.microsoft.com/en-us/windows/forum/windows_tp-performance/explorerexe-is-causing-some-graphic-glitches-in/d3a4e07b-82fd-4dd3-b42e-a67563eee6b4

    and more: http://answers.microsoft.com/en-us/windows/forum/windows_tp-performance/applications-in-task-bar-disappearing-the-computer/6433264a-52e6-478a-a0b2-5fb4acb73ac2
    • Edited by MELERIX Thursday, November 20, 2014 9:02 AM
    Thursday, November 20, 2014 9:01 AM
  • I'm getting this same thing in Win 8.1 U 1, but it only came up after it synced with my Win 10 PC. Strangely enough, this doesn't happen to either of my devices when my gf is logged in. We both use steam, which shows download progress in the taskbar. So might be related to some new setting getting synced, or maybe I just have horrible luck and it's just a big coincidence that it showed up after the sync.
    Thursday, November 20, 2014 8:28 PM
  • I also noticed that new OneDrive tray icon also causes relatively big GDI objects count increase (but in its own process, not explorer.exe) when clicking the icon (when it shows status). Upon reaching ~10k of that objects, the process of OneDrive (I believe it's called SkyDrive.exe or something) crashes and starts over again.
    Friday, November 21, 2014 3:27 PM
  • Same for PS


    $path = Split-Path -parent $MyInvocation.MyCommand.Definition
    $searchfor = "explorer"
    $maxGDI = 6000
    $sig = @'
    public static extern int GetGuiResources(IntPtr hProcess, int uiFlags);
    Add-Type -MemberDefinition $sig -name NativeMethods -namespace Win32
    $processes = [System.Diagnostics.Process]::GetProcesses()
    ForEach ($p in $processes)
        # Check for process
        if ($p.Name -ne $searchfor) { continue }
            $gdiHandles = [Win32.NativeMethods]::GetGuiResources($p.Handle, 0)
            # Check for maxGDI
            if ($gdiHandles -lt $maxGDI) { continue }
                # Log
                "$(Get-Date) The process $searchfor ($($p.id)) had $gdiHandles GDI Objects, so it is closed for sanity" | Out-File $path\Leak.log -Append
                #Write-Output "kill $($p.Id)"
                kill $p.Id -Force
                #Write-Output "start $searchfor"
                Start-Process $searchfor
            catch {
        catch {
            #"Error accessing " + $p.Name

    And to start it hidden


    Const HIDDEN_WINDOW = 0
    strComputer = "."
    Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
    Set objStartup = objWMIService.Get("Win32_ProcessStartup")
    Set objConfig = objStartup.SpawnInstance_
    objConfig.ShowWindow = HIDDEN_WINDOW
    Set objProcess = GetObject("winmgmts:\\" & strComputer & "\root\cimv2:Win32_Process")
    objProcess.Create "powershell -file GDIView.ps1", null, objConfig, intProcessID

    Tuesday, November 25, 2014 7:57 AM
  • Just thought I'd add to the thread that I've noticed an oddball exception to this GDI leak: Firefox 33.1.1.

    For whatever reason, even lengthy downloads with this browser don't budge GDI, and the taskbar progress bar is there throughout. I would have thought that the app wouldn't matter, but it clearly does, at least here.

    This is the only exception that I've found.

    Saturday, November 29, 2014 7:55 PM
  • Same issue here. Everytime I play a movie in MPC, what my n00by self calls GUI kills itself to get ressurected by explorer.exe restart. It was so extremely annoying that I installed 9841 from scratch and didn't update. I'm waiting for new build.
    Tuesday, December 23, 2014 5:28 AM
  • Gabriel Aul confirmed that this problem will be fixed with next build
    Tuesday, December 30, 2014 12:35 PM
  • Also fixed in the leaked build.
    Tuesday, December 30, 2014 4:02 PM