I am seeing something similar where my Windows Store App hangs on the same location within ArcGIS runtime. It only occurs with a certain clients geodatabase so far and returns no error, just hangs the app. Also, its inconsistent, the map will load fine with this gdb sometimes and work well, but will eventually fail after leaving the map page and returning again. Sometimes its on the 2nd map page visit other times it will make 10 visits fine, but it always eventually hangs. I am not positive yet if it seems to be a particular area of the data, but it doesn't seem to be.
I see it hang in worker thread at;
Flagged | > | 7728 | 3 | Worker Thread | <No Name> | Esri.ArcGISRuntime.DLL!RuntimeCoreNet.CoreDrawSurface.ShutdownDrawThread | Normal |
| | | | | | [Managed to Native Transition] | |
| | | | | | Esri.ArcGISRuntime.DLL!RuntimeCoreNet.CoreDrawSurface.ShutdownDrawThread() | |
| | | | | | Esri.ArcGISRuntime.DLL!Esri.ArcGISRuntime.Controls.DrawSurfaceWinStorePhone.StopRendering() | |
| | | | | | Esri.ArcGISRuntime.DLL!Esri.ArcGISRuntime.Controls.DrawSurfaceWinStorePhone.OnUIUnloaded() | |
| | | | | | Esri.ArcGISRuntime.DLL!Esri.ArcGISRuntime.Controls.DrawSurfaceWinStorePhone.m_swapChainPanel_Unloaded(object sender = {Windows.UI.Xaml.Controls.SwapChainPanel}, Windows.UI.Xaml.RoutedEventArgs e = {Windows.UI.Xaml.RoutedEventArgs}) | |
If I wait for a long period of time the debugger will eventually throw this message;
Additional information: The CLR has been unable to transition from COM context 0xf06db8 to COM context 0xf06e70 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.
I am guessing there is something ArcGIS runtime does not like about the particular geodatabase. Anyone have any ideas on where to go next on this issue?