Windows 10 Runtime Broker Performance Killer - SOLVED! ...?

Dan Holme

by Dan Holme on 9/15/2015

Share this:
Print

Article Details

Date Revised:
9/15/2015


After solving the problem that causes the Surface Pro 3 (perhaps other versions) running Windows 10 to drop its network connections when docked, I was feeling a bit like Superman. That problem was an evil villain that vexed me for months. 

But there remained an even eviler supervillain to battle. Windows 10 has a serious memory leak that causes Runtime Broker to eat up all available memory and to kill performance. Problem SOLVED! ...?

If you follow me on Twitter, you might have seen my regular rants over recent weeks that Microsoft has not fixed a problem that brings my computer to a grinding halt daily--sometimes multiple times daily.

The symptom is degrading performance that, eventually, is so bad that it is unbearable. Opening Task Manager, I find that Runtime Broker is consuming an extraordinary and increasing amount of memory and processor resources.  Looks and smells like a memory leak to me. 

The processor utilization of Runtime Broker itself (28% in the screenshot above) doesn't even reveal the full extent of the impact the problem. As it eats more memory, the system process has to start paging memory from RAM to disk, which takes even more processing resources and impacts disk I/O performance for 'normal' applications.

Killing Runtime Broker solves the problem, temporarily:

  1. Open Task Manager (CTRL+SHIFT+ESC or right-click the taskbar)
  2. If you don't see multiple tabs, click More Details.
  3. Click Memory to sort by the amount of memory consumed. Runtime Broker will be at or near the top.
  4. Click Runtime Broker.
  5. Click End Task.

But the problem will resurface. After a period of time, or perhaps the next day, or perhaps after a restart, Runtime Broker comes back. Like the serial killer in a bad horror movie, Runtime Broker returns to kill performance again.  It's the Freddy Kreuger of processes.

I can't even begin to tell you how painful this has been for me. So much time wasted killing processes, restarting computers, or just struggling with terrible performance that impacted Skype calls and more.  It's been gruesome.

And I've been quite angry that Microsoft hasn't really responded to the issue.  There are many, many, many complaints about it out on the internet.

Among the most useful proposed solutions was to turn off "Show me tips about Windows" in Settings:

  1. Open Settings (Press WIN+I)
  2. Click System
  3. Click Notifications and actions
  4. Turn off Show me tips about Windows

There were quite a few people who reported that it solved the problem for them.

But it didn't solve the problem for me.

The suggestion I found that really worked (and I wish I could remember where I found it, to give credit to the user who shared it) was related to mapped network resources.  

By looking at what resources my computer was connected to on the network, and disconnecting or tweaking them, I believe I've solved the problem.  After three days, no runaway Runtime Broker!

In my specific case, I use LIBRARIES in Windows with some folders added to libraries that are on remote machines.  That was, I'm pretty sure, the culprit.  

I noticed that when I went to a library, I was being informed that "Some library features are unavailable due to unsupported library locations." This happens when you add a folder from a remote machine (a server) to a library, and the server's search service is not indexing the location.

I put together the clues: Unsupported library location (a folder on a server, connected to my machine in a less-than-ideal manner) and runaway Runtime Broker tip about mapped resources and voila I solved two problems at once.

I went to the server, into Indexing Options, and added the folder (that was added to the library) to the index.  I allowed indexing to proceed.  After indexing finished, and a restart of the client computer (a signoff may have been sufficient, but better safe than sorry), and now my library no longer reports "unsupported location" and Runtime Broker is under control!

Now, some more detail. I actually tested this scientifically. Here's the full process I went through. 

  1. I made the connection between the two problems I was seeing: Library messages and Runtime Broker. 
  2. I first disconnected the folder from the library entirely, restarted the system, and worked normally to see whether Runtime Broker ran away. It did not!

    Disconnecting the network resource solved the problem!

  3. Then, I wanted to see whether it was simply a matter of having a network resource that was causing Runtime Broker to leak, or whether it was an un-indexed location. So I added the folder back to the library, after ensuring that it was completely indexed.  Sure enough, now that the location was indexed, Runtime Broker stayed under control.

Takeaways:

  1. Look at what network locations are mapped or otherwise connected to your computer.  Consider disconnecting them ALL to start with. You can always add shortcuts to a location, rather than hooking the location into Explorer with mapped drives or libraries.
  2. If you have libraries that include network locations, make sure they are indexed. This may not be possible if your folders are on NAS devices, etc. You may have to simply disconnect those.  Booo!
  3. Microsoft needs to get their engineering team on fixing this immediately.  Any process that can eat 4GB of RAM from a memory leak (which mine did, when I left my computer running overnight) is a demon that must be slain. The good news is, the Windows team under Gabe Aul is excellent and I hope this clue might help them solve the problem for all of us.

 

I'm hesitant to declare full success because we all know that at the end of the horror movie, Freddy Kreuger doesn't actually die. So I'm still scared... very scared... But for now, I can walk into that dark room alone without hearing that scary music... and at least Windows doesn't die.

On to the next battles: 

  • Odd, intermittent drops in network connectivity and performance while using Skype.
  • Edge randomly losing the ability to copy and paste successfully.
  • Edge eating up ridiculous amounts of RAM... Does it really need 1/4 GB for each tab?

And one more note to the (truly astounding) Windows team, some of whom may read this: Don't give up on libraries. They rock. The library construct is a great way to integrate disparate sources of content... to unify our personal and professional lives (sound "aligned"?).   There may not be "telemetry" to support investment, but I think that's because there was never enough training and messaging about exactly why they rock and how to best use them. It may be that people simply didn't use what they were never told how to use. I can't imagine how great they would be to unify on-prem shared folders, folders at home on NAS devices, and OneDrive folders.  Please invest!

Anyone have tips on these?  Please share, along with any comments about Runtime Broker.  

 



Topic: Windows 10

Sign in with

Or register

  • In my case it wasn''''t a mapped drive, but a local secondary drive. Removing the secondary drive location from the library seems to have done the trick. Also used procmon.exe like a user below to view that attempts were being made to access a registry location repeatedly, followed by repeated requests to locations on the drive.
  • Pity the team got such a good rapport, these Runtime Broker problems are still happening to my Windows 10 AU PC, fully patched, last night when I hit Win+L to lock! I didn''''t know it had happened until this morning, and found the RUntime Broker has scheduled a restart message in my event viewer. OK, so I have now deleted all mapped drives, let''''s see if that helps. Great article, many thanks :)
  • "...the Windows team under Gabe Aul is excellent"

    That comment made me spit out my coffee this morning.
  • Thanks so much for posting! This was exactly the solution I have been looking for, for quite some time! In my case it wasn't related to not having the locations indexed, it was because I had included in a couple libraries on my desktop PC (running Windows 10) some shared folders where those folders were located on a tablet computer. The desktop PC is on 24/7, but the tablet is off at night ... and travels with me. So the tablet is not always available as a resource to the Desktop PC.

    This explains perfectly the strange behavior I saw. During the day, my tablet is on and connected to the network and I'm at my desktop PC. In the morning I'd see that RuntimeBroker is in runaway mode, taking 50% or more CPU and eating memory. I'd kill (end task) RuntimeBroker on the desktop PC and it would restart in the background and would be fine all day. Next morning, there's RuntimeBroker again cranking away on something, eating up gobs of CPU.

    I used Sysinternals Process Monitor (procmon.exe) while RuntimeBroker was cranking away this morning, and sure enough, I found that RuntimeBroker was repeating over and over, within a fraction of a second of it's last attempt, to open a registry key, failing with result NAME NOT FOUND, followed by a FileSystemControl operation on \\\\MyTabletPC\\pipe\\MsFteWds with result NETWORK ERROR on Control: FSCTL_PIPE_TRANSCEIVE. In just 5 minutes of time that I let ProcMon run, it collected over 5 million events from RuntimeBroker all with the same error I just described!

    So, the takeaway, RuntimeBroker isn't smart enough to recognize that a remote resource isn't available and keeps retrying and retrying. The fix ... as you've already found, is don't include external resources ... especially if those resources/file shares are not always available in Windows 10 Library locations!

    Thanks again for your post ... I found it only after I began analyzing via ProcMon which helped me come up with the right keywords to search the web and hence find your post.
  • I think this was my problem! I recently turned indexing off on my home server locations (I forgot why I had it on). Then my laptop started going crazy with runtimebroker. I ran across this post and checked runtimebroker on procmon, sure enough it was accessing files in a shared location. I've removed the networked folders from the library, so hopefully that fixes the issue.
  • Windows 10: Pop-up windows open behind other windows

    Please, please, please, please help me. PLEASE!!! I'm begging you. This problem with the windows popping up behind other inactive cells or windows is simply driving me crazy! Right about now, I'm am really hating Windows 10. I mean, how could Microsoft not know about this problem?! Really, honestly, seriously?! It is just so frustrating to deal with. I have to fumble about with the mouse moving here and there, and here and there, over and over again trying to get the active cell or window to come to the front. I can't close or minimize the other windows that I have open because I need to have them all up as I am using all of them to perform certain tasks as I go along about my business. It's just simply quite a dilemma just to try and get whatever window you need active to come to the front. Please tell me that you are the smart here in the classroom and you indeed have an answer to this problem. I will be forever grateful. Thank you in advance.
  • Wow thanks, this is actually the first intelligent write-up I have seen on this issue. I have no intention of disconnecting all my network resources long term, they are much too important, but am going to try this and then report back on whether it solves the issue for me or not. I have a powershell script scheduled every 12hrs to just kill the process so it doesn't bog my PC out.
  • Unfortunately I still have issues with Rutime Broker. I disconnected the network locations and disabled tipps for Windows. I really don't know what else I can do... But thank you for your article!
  • Thank you! I have had terrible performance issues and removing network shares from my libraries resolved the issue!