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

Yes, I don't think The Time app can be blamed for this effect, it just so happened that a few of us had it installed and it utilises the class and methods that Jeff outlined above, which are causing the memory leak.

There are clearly a few teething problems with the Windows Runtime and how it deals with object instances / references that are created using managed code. Unfortunately, the developers are getting it in the neck via the review section of the Windows App Store, which is not fair but understandable as the average user does not know the underlying reasons for the problems they are experiencing. Really, I just wanted to point this out as I used to write applications myself and I know how it must feel to have your programs rubbished on a public platform. (Mine were only ever rubbished in the relative privacy of the IT director's office!)

in my case the problem is the app "multimedia 8" 

memory usage incrementally expands in time especially when i force the application to search in a multimedia folder and win8 suggests to shut down runtime broker process after minutes.

and i discovered that, issue happens much quickly when im browsing in media servers in my home group eventhough there are less multimedia files than local multimedia folders.

hope ms would find a solution for this soon

Hi Jeff,

Thanks for the link to the whitepaper.

I'd really appreciate a look at the project that demonstrates the leak. Maybe best to email you regarding that if you don't mind?

Cheers

Mark

Hi Mark,

Believe it or not, my Runtime Broker is at 379 MB right now -- and I don't have The Time installed on this computer. I have five different computers I test the app on before I submit it to the Store and it's the only one exhibiting the problem right now, so something I've installed on here is causing it to leak. Unfortunately The Time has taken considerably more of my free time than I anticipated so I haven't taken the time to figure out which app is causing it.

The thing with TileUpdater.GetScheduledTileNotifications is that it only needs to be called when scheduled tiles are going to be removed. I really did write The Time on a whim because I didn't like the other time apps and took a simple brute-force approach: When one of my background tasks was triggered, I'd call GetScheduledTileNotifications, remove each from the schedule and then re-populate the queue with n scheduled tile notifications. So in a scenario where triggers were firing as fast as possible (every fifteen minutes), Runtime Broker memory could go up as quickly as 160 MB/hour.

Again, GetScheduledTileNotifications only needs to be called to remove items. The overwhelming majority of apps that schedule tile updates don't need to remove previously scheduled updates so you won't see the leak on most computers.

Once I found the bug I re-wrote The Time to only make the call when it was absolutely necessary: When the user changes the content of the tiles. For example, if they choose to change the date format or exclude the day of the week. Also, I'm scheduling far fewer tiles now, so even if GetScheduledTileNotifications gets called the impact on memory is nearly insignificant, it's one-time-only and it will eventually get cleaned up when the user logs off or the app is serviced.

I have VS C# VS project that demonstrates the leak as simply as possible. I'd be happy to share it with you if you'd like. Otherwise, if you're going to write a time app you'll want to become intimately familiar with the background task infrastructure. This whitepaper is a great place to start.

Please let me know if you have any questions.

Thanks,

Jeff

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