[UWP] [MapControl] Memory Issue/Bug RRS feed

  • Question

  • First, i wanted to open a support ticket but there seems to be no real Department for that very special problem, so i will post this here on the forum.   Would be nice if someone from MSFT could adress that issue.

    I am utilizing the MapControl in my UWP app.  The problem with MapControl is that it is allocating memory and allocating memory and allocating memory and allocating memory and never ever frees it.  Only when the app is beeing terminated.

    Memory consumption of the UWP app with MapCtrl after startup (MapCtrl Center somewhere in Australia):

    Memory after jumping from Australia to a town in Europe:

    Memory after jumping from Europe to a town in the USA:

    Memory after jumping to many towns, multiple zoom in/out and scrolling:

    So it seems to me that the MapControl allocates memory for its used objects.  There's nothing wrong with that.  It has too, of course.  But when the map is "moved" (=the former viewpoint not any longer in view) it seems to NOT free its currently allocated resources (although they are not any longer used).

    I can understand that the memory allocation of "nearby ressources [or better: locations]" (after scrolling) is stell kept in memory because maybe the user scrolls back to the origin location.  But when the user moves around countries or even continents (!) then i see no reason in keeping these previous allocated ressources.

    Again: MapControl only (!) allocates memory and never ever frees it.   A manually GC.Collect() does not change anything on that situation.  And that is of course a problem.  I do have "memory failures" according to the health report of DevCenter (meaning the app crashes for some users because they run out of memory):


    Could you please have the Team of MapCtrl have a look into that issue please?

    • Edited by wolfSYS Sunday, January 10, 2016 2:05 PM
    Sunday, January 10, 2016 1:58 PM

All replies

  • If have an app too with even multiple MapControls in it and scrolled around the World with zooming in and out a couple of minutes, with the Task Manager visible, but I don't see increases in memory use for my app. Only a few MB's increases but also decreases so the memory use stays about the same over longer periods of time.

    Maybe you have some MapControl events active what cause the memory leaks?


    In this line of the crash report you see addItem_Engine, do you add items to the MapControl?


    Sunday, January 10, 2016 2:13 PM
  • I can understand that your map controls do not consume as much memory as mine.  I should have mentioned (sry, my fault) that I do not display the standard map (that is: MapStyle set to Road) but rather those MapStyles:

    • Aerial
    • AerialWithRoads
    • Aerial3D
    • Aerial3DWithRoads

    So yes, I assum that many items are added.   But that's none of my business: I personally do not add them (the engine behind MapCtrl adds them) and moreover I have no possibility of manually removing them.   Would be great to have this when the viewpoint changes significant.

    • Edited by wolfSYS Sunday, January 10, 2016 2:40 PM
    Sunday, January 10, 2016 2:30 PM
  • Sunday, January 10, 2016 5:01 PM
  • This is a know issue in older version of Windows 10. Please update to newer version (10.0.586)


    Tuan Tran Van

    Definitely not.

    This behaviour exists on both 10240 and 10586 builds.  Both development machine and test machine have (of course, needless to say) the latest updates installed (and are running the 10586 build although the problem existed also prior on 10240 "in the old days").  I do say "of course" because I as a one-man-show can not support all historical version possibilities of win10.  So whenever I talk about "MS Windows" I of course refer to the latest, current version    :-))

    So no, that response (at least) FOR AERIAL VIEW is wrong.

    And I also doubt that there is a connection with attached events because the values above taken from TaskManager where created only by moving around in the map without calling another XAML page (and I, again "of course", do  detach them before navigation occurs).

    • Edited by wolfSYS Monday, January 11, 2016 11:59 AM
    Monday, January 11, 2016 11:33 AM
  • The memory behavior you describe may be intentional. If the system has a lot of RAM, the control will cache visited areas rather than immediately free them to improve the user experience. If there's system memory pressure, or if the app suspends, the memory should be freed. This is pretty easy to verify - you can force a suspend from Visual Studio while debugging. Forcing a GC won't do anything - the map control is primarily creating D3D graphics objects which are native allocations, not managed.

    Just tracking memory use displayed by task manager over time doesn't really tell much. A working set of 700MB in Aerial 3D is not unusual on a high-end system if the RAM is available and not being used for anything else.

    Monday, January 11, 2016 5:50 PM
  • All right, I see.

    Start/Debug x64 in VS, moving many times around the map and suspending doesn't free up 1 single bit.  But that's maybe because my dev machine has "to much" RAM (32 GB)?  Will have to check this on my other 8GB machine.

    On the other side, memory consumption in the debug version seems to be not as aggressive as the (native .NET) release build... ?

    Tuesday, January 12, 2016 9:35 AM
  • As I mentioned, that behavior is expected. If you don't suspend the app, or if there's no system memory pressure, it will keep around quite a bit of data (should max out at around 700MB for the highest-end systems).

    As soon as you suspend the app (From the Lifecycle Events menu in VS while debugging, or just minimize the app and wait for a few minutes), the memory will free up. It will also free if there's any memory pressure on the system (like other apps running in the foreground, or if the total commit by all processes starts to approach physical RAM).

    An 8GB system will probably show the same behavior. A 1 or 2 GB system will scale back resource usage substantially.

    Tuesday, January 12, 2016 5:03 PM
  • OK, so basically I should not be worried.

    But when everything works like explained ... what are those "memory failures" in DevCenter Health report?
    I mean its not dramatically, the numbers are not that high, but is there something I could do on my side to prevent them?

    • Edited by wolfSYS Wednesday, January 13, 2016 10:39 AM
    Wednesday, January 13, 2016 10:39 AM
  • no answer till now regarding "memory failures in devcenter health report".

    therefore I assume that MapCtrl has bugs.  or win10 memory management itself.  all right.
    memo to myself:  don't use it in another project

    • Edited by wolfSYS Friday, March 4, 2016 11:37 AM
    Friday, March 4, 2016 11:32 AM
  • This happens still now on 14393, I get an out of memory exception from the MapControl on a Lumia 735 and the map goes black and the app crashes.
    Tuesday, November 22, 2016 5:11 PM