what is runtime broker, and why does it use so much memory?

Hi Jeff,

Thanks for taking the time to explain the issue and my apologies for suggesting that you were encouraging people to write positive reviews.

I am going to write a time app myself to see if I can replicate the issue. What I don't understand right now is that after uninstalling your app, the runtime broker process is not building up a cache of memory at all but I'm assuming that other apps must be calling TileUpdater.GetScheduledTileNotifications

Whilst an app that needs to update the time every minute is going to have to make more tile updates than most, if it is a bug with the Windows Runtime I would have expected a slow build up of memory usage over time with all the other apps that use the same methods - and I am not seeing this at all. (my PC is on 24/7 by the way)

However, I would be lying if I said that I knew anything about memory management in the Windows Runtime and a quick read of the Visual Studio documentation that covers the relevant classes has not enlightened me so I will refrain from further comment until or unless I understand the topic in more detail.

Cheers

Hi folks,

There seems to be a perception that the Runtime Broker leak is inextricably tied to The Time at the moment, so I want to provide some additional information here since I imagine many people experiencing the leak will find there way to this thread via their favorite search engine.

Users:

There's a bug in the Windows Runtime, the new platform that Windows Store (aka Metro) applications are written on, that causes the "Runtime Broker" process to take on additional memory but never release it, resulting in a memory leak. If you find that the Runtime Broker process on your computer is taking an unreasonable amount of memory, consider the Windows Store applications you've installed recently that utilize Live Tiles. Try uninstalling them, one by one, until the Runtime Broker takes less memory. Note that the reduction in memory may not be immediate and you may need to log out and back in to make it reset. (You may be able to kill the Runtime Broker process safely, but I would advise against it.)

Developers:

The bug manifests itself when calling TileUpdater.GetScheduledTileNotifications. The leak may not be obvious unless you have many tiles scheduled. In my experience it happens regardless of the number of scheduled tiles, it's just more apparent when you have more.

For example, consider the following scenario:

1. Schedule 4,000 tile updates via TileUpdater.AddToSchedule. Note that the Runtime Broker's memory increases a bit. This is to be expected.
2. Call TileUpdater.GetScheduledTileNotifications. Notice that the Runtime Broker's memory increases by a good amount. This is typically 30-40 MB on my machine.
3. Now remove each notification via TileUpdater.RemoveFromSchedule. The Runtime Broker's memory stays the same.
4. Schedule another 4,000 updates.
5. Call TileUpdater.GetScheduledTileNotifications. Observe an increase in Runtime Broker memory use, similar to that in step 2.
6. Keep repeating step 5, each time with the same amount of memory increase.

It appears that every call to TileUpdater.GetScheduledTileNotificaitons is resulting in the Runtime Broker allocating memory it never frees. Considering the Windows Runtime is partially based on COM I thought that perhaps it was up to the developer to free up references to the tile notifications returned from the method. But the documentation says nothing about it and none of the classes implement IDisposable. The only option I'm aware of at this time is to avoid the method completely.

The bug has been entered into Microsoft Connect and you can follow its progress here:

http://connect.microsoft.com/VisualStudio/feedback/details/770619/memory-leak-in-runtime-broker

If you have any questions, please feel free to email me directly at jeffreykey at gmail.com.

Thanks,

Jeff

Hi Mark,

My name is Jeff Key, I wrote The Time and I apologize for your wasted time. The problem turned out to be a bug in the Windows Runtime, which you can learn about here:

http://connect.microsoft.com/VisualStudio/feedback/details/770619/memory-leak-in-runtime-broker

I can assure you I didn't encourage anyone to write positive reviews for me. I've been writing free, shareware and commercial software for over twenty years. I've had nearly a million downloads of my free software alone. If you were a .NET developer you probably used some of it.

Please bear in mind that people are spending $100/yr of their own money -- not to mention their time -- to publish free applications in the Windows Store for you to use. The Windows Runtime is a new platform with new capabilities, new constraints and yes, new bugs. Not every app is going to be great and the platform is not bug free. If you don't like what's out there go ahead and do what I've done: write you own apps.

Cheers,

Jeff

I just got rid of "the time" and now it seems to be much better.. I guess we have to be really careful about the apps we install. Microsoft need to try and catch bad apps at the submission process.. if possible.

They either have to take that app off the store, or the dev needs to fix it. Or even better, Microsoft should add a time tile themselves :)

Maybe I'm being cynical but in addition to somebody mentioning an update, I noticed that the two latest reviews just happened to award the app five stars and claimed that it was so great that it should be part of the Windows OS. One of them actually says that apart from the memory leak, the app is awesome..... A simple program to display the time that consumes all the available RAM on your machine until you reboot or kill the Runtime Broker process can in no way be considered awesome as far as I'm concerned.

Instead of encouraging his friends to post reviews to negate the bad ones that have been left, and which were well deserved in my opinion(reputation management anyone?), the author should brush up on his programming skills. He wasted many hours of my time with this little application.

As a former Windows developer, I cannot see anything very difficult about writing an app that displays the correct time without consuming several gigabytes of RAM in the process. An apology would not have gone amiss and, as somebody mentioned earlier, Microsoft's screening process for apps appears to leave a lot to be desired.