Runtime Broker - Consuming lots of memory

Liam Alford 0

Hello All,

I have developed a UWP app years ago to download and store files and sync data from a service of mine.

This application has been stable and working without issues for long time, however a recent change in the behaviour of the solution has meant it's almost continually streaming data from the service and a side effect of that means the runtime broker is consuming so much memory the system grinding to a halt, even stopping the traffic doesn't free the memory.

thumbnail image 1 of blog post titled Runtime Broker - Consuming lots of memory.

Is there any way I can debug what is happening with this RuntimeBroker or understand why this is happening?

Junjie Zhu - MSFT 18,486 Reputation points Microsoft Vendor

2024-08-05T06:09:38.5866667+00:00

Hi @Liam Alford ,

Welcome to Microsoft Q&A!

The reason for this behavior is probably that the file function causes RuntimeBroker to take up too many resources. I will discuss this behavior with the Team.

Thank you.
Liam Alford 0 Reputation points

2024-08-05T08:42:16.8033333+00:00

Thank you. This is quite a critical application, so it would be really helpful if we could resolve the issue.

Would migrating the app to Windows SDK Win-UI3 remove the reliance on the RuntimeBroker?
Junjie Zhu - MSFT 18,486 Reputation points Microsoft Vendor

2024-08-06T02:48:09.0766667+00:00

Hi @Liam Alford ,
To further analyze this problem, I would appreciate your help to collect the following information.

1."it's almost continually streaming data from the service and a side effect of.." What is the app streaming and how?

2.What does "stopping the traffic" mean? If the app still referencing the memory, then the broker can't release it.

Thank you.
Liam Alford 0 Reputation points

2024-08-06T08:12:03.02+00:00

Hello,

1 - It's essentially a backup service that sync's files and a data stream (Similar to One drive, Google Drive, Dropbox etc...). It was previously just synching files periodically, once every 5 minutes it would sync changes to a set of files (2-300 every 5 minutes 100KB each). We also use a "long poll" to pick up changes to data set's. So it will POST a HTTP request to the service, the service will hold the connection open until there is data to return or the 120s timeout is reached. Until recently the "long poll" would only be "watching" a small data set, so the traffic was minimal (couple of MB an hour). The memory usage for the app and broker were stable. Now we've increased the data set that the long poll watches, the long poll returns almost immediately with 1-10MB of data on each request. It's since this change that we've noticed the Runtime Broker memory usage increasing.

2 - By stopping the traffic, I'm referring to decreasing the data set's being watched and synced. If we start the app while watching the small set of data with the long poll, the runtime broker remains stable, memory increases at times, but then subsides. However when we start synching the large data set again, the memory appears to "leak" and reducing data set's being watched to zero, effectively reducing the traffic to zero on the long poll, doesn't appear to have any impact on the memory usage of the Runtime Broker the "leaked" memory does not appear to be freed.

Hopefully that helps, let me know if need any more info.

Thanks.
Junjie Zhu - MSFT 18,486 Reputation points Microsoft Vendor

2024-08-12T07:10:54.9933333+00:00

Hi @Liam Alford ,

Could you please provide more details to further analyze this problem.

How is the broker called? Is it just opening and maintaining a permanent stream, or is it opening and closing the stream?

What language is used? Where are the files stored? Is this running on a background thread or the UI thread? The file usage seems to be in the background, you can use a lower-level file API instead of going through the broker.

Thank you.
Liam Alford 0 Reputation points

2024-08-13T08:53:42.1233333+00:00

Hello,

My code does not call the Broker, it appears to be launched by default due the app being a UWP app. If there is a way to prevent the broker being process running and the app still work that would sufficient.

The App is written in C# and the files are being store either in the App's "localstate" directory or in some cases it is store on other areas of the C:\ that the user hass write permissions for.

It is being used on background threads. Can you provide a reference to these "lower-level" API's you're referring to?

Thanks
Liam Alford 0 Reputation points

2024-08-13T08:55:18.37+00:00

Hello,

My code does not call the Broker, it appears to be launched by default due the app being a UWP app. If there is a way to prevent the broker being process running and the app still work that would sufficient.

The App is written in C# and the files are being store either in the App's "localstate" directory or in some cases it is store on other areas of the C:\ that the user hass write permissions for.

It is being used on background threads. Can you provide a reference to these "lower-level" API's you're referring to?

Thanks

0 commentsNo commentsReport a concern
Junjie Zhu - MSFT 18,486 Reputation points Microsoft Vendor

2024-08-16T03:07:24.3466667+00:00

Hi @Liam Alford ,
Are you using the Windows.Storage class? If so, then when using StorageFile, it will work through the Runtime Broker.

It is recommended that you use lower-level APIs to read and write file, such as System.IO.File class or win32 API WriteFile(fileapi.h) ReadFile (fileapi.h).
Please note that UWP only have default permissions only for its application data folder. To write elsewhere they'll need permissions (via manifest, picker, etc), you can get CreateFile2FromApp (or related *FromApp) methods to get a HANDLE with the app's granted UWP permissions.

Thank you.
Roy Li - MSFT 33,371 Reputation points Microsoft Vendor

2024-08-27T09:21:24.0766667+00:00

Any updates about this issue?
Liam Alford 0 Reputation points

2024-09-02T14:36:37.11+00:00

We are still investigating the issue, though I can confirm we are using the Windows.Storage API's and see if using a lower level API improves things.

Share via

Runtime Broker - Consuming lots of memory

Your answer