Obscure Runtime Exception When Panning Map (100.6-100.8)

731
16
Jump to solution
04-07-2020 04:09 AM
KyleGruber
Occasional Contributor II

Hi everyone,

So I know companies/developers/support loves when someone posts a stacktrace without a repro app or any good details as to what's causing it, but that's what I'm about to do here.  This error is randomly getting thrown when the map is being panned in our .NET WPF application (runtime 100.6, .NET 4.6.2).  As you can see, it doesn't appear anything in the stacktrace is related to anything we're doing, but of course, the thread execution makes it a bit difficult to tell.

Application: ourapp.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: Esri.ArcGISRuntime.ArcGISRuntimeException
at Esri.ArcGISRuntime.ArcGISException.HandleCoreError(RuntimeCoreNet.GeneratedWrappers.CoreError, Boolean)
at RuntimeCoreNet.GeneratedWrappers.Interop.CheckError(IntPtr, Boolean, System.Runtime.InteropServices.GCHandle)
at RuntimeCoreNet.GeneratedWrappers.CoreGeoView.Pulse()
at Esri.ArcGISRuntime.UI.Controls.GeoView.Esri.ArcGISRuntime.Internal.IDxSurfaceSource.Pulse()
at Esri.ArcGISRuntime.Internal.HostedSurfaceElement.CompositionTarget_Rendering(System.Object, System.EventArgs)
at Esri.ArcGISRuntime.Internal.HostedSurfaceElement.<AttachRenderingEvent>b__29_0(Esri.ArcGISRuntime.Internal.HostedSurfaceElement, System.Object, System.EventArgs)
at Esri.ArcGISRuntime.Internal.WeakEventListener`3[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089],[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089],[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].OnEvent(System.__Canon, System.__Canon)
at System.Windows.Media.MediaContext.RenderMessageHandlerCore(System.Object)
at System.Windows.Media.MediaContext.AnimatedRenderMessageHandler(System.Object)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
at System.Windows.Threading.DispatcherOperation.InvokeImpl()
at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(System.Object)
at MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
at MS.Internal.CulturePreservingExecutionContext.Run(MS.Internal.CulturePreservingExecutionContext, System.Threading.ContextCallback, System.Object)
at System.Windows.Threading.DispatcherOperation.Invoke()
at System.Windows.Threading.Dispatcher.ProcessQueue()
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
at MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)
at MS.Win32.UnsafeNativeMethods.DispatchMessage(System.Windows.Interop.MSG ByRef)
at System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame)
at System.Windows.Threading.Dispatcher.PushFrame(System.Windows.Threading.DispatcherFrame)
at Esri.ArcGISRuntime.Internal.HostedSurfaceElement.SurfaceBackgroundUiWorker(System.Object)
at System.Threading.ThreadHelper.ThreadStart_Context(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
at System.Threading.ThreadHelper.ThreadStart(System.Object)

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Any assistance that can be provided would be greatly appreciated.

0 Kudos
1 Solution

Accepted Solutions
MichaelBranscomb
Esri Frequent Contributor

Kyle,

It's good news that you have isolated the repro. Downloading now.

Please email me the password: MBranscomb@esri.com

Thanks

Mike

View solution in original post

16 Replies
dotMorten_esri
Esri Frequent Contributor

The pulse call is when it renders the map, so most likely a graphics driver/rendering issue in the native code. Can you get the message from that exception that's thrown? Also enable "native debugging" in the project settings (debug tab), and it might give a slightly better error.

Also does the issue reproduce with v100.7 ?

MichaelBranscomb
Esri Frequent Contributor

Kyle,

You can find more info on referencing the ArcGIS Runtime symbol files (pdbs) here: https://community.esri.com/community/developers/native-app-developers/arcgis-runtime-sdk-for-net/blo....

Thanks

Mike

KyleGruber
Occasional Contributor II

Michael BranscombMorten Nielsen

Thank you for the quick response, I think I may have this fixed actually.  In case anyone runs into this in the future, the issue was how I was changing basemaps dynamically at runtime.  I was using a hacky method that involved creating the basemap, extracting the base layer service, and adding it to OperationalLayers.  I can't recall why I was doing this in the first place, but changing to using plain Map.Basemap = Basemap.CreateSomeBasemap() seems to have fixed it.

0 Kudos
KyleGruber
Occasional Contributor II

Michael BranscombMorten Nielsen

I apologize for the delayed response and different answer.  While that change seemed to clean up most issues, we were finally able to find an environment where we could consistently reproduce the crash.  The interesting thing in this environment is the lack of a stacktrace we get (just a generic access denied (0x000005) code).  Here is the raw stacktrace.

runtimecore.dll!SkBaseDevice::SkBaseDevice(struct SkImageInfo const &,class SkSurfaceProps const &)
runtimecore.dll!SkCanvas::SkCanvas(class SkBitmap const &,class std::unique_ptr<class SkRasterHandleAllocator,struct std::default_delete<class SkRasterHandleAllocator> >,void *)
runtimecore.dll!Esri_runtimecore::Map_renderer::Canvas_layer::Render_properties::Display_list_collection::draw_container_(class SkCanvas &,class Esri_runtimecore::Map_renderer::Canvas_layer::Render_properties::Display_list_collection::Container const &,class Esri_runtimecore::Map_renderer::Cancelable const &,enum Esri_runtimecore::Map_renderer::Chunk_set)
runtimecore.dll!Esri_runtimecore::Map_renderer::Canvas_layer::Render_properties::Display_list_collection::set_display_list(unsigned int,class std::shared_ptr<class Esri_runtimecore::Map_renderer::Display_list> const &,class Esri_runtimecore::Map_renderer::Cancelable const &)
runtimecore.dll!Esri_runtimecore::Map_renderer::Canvas_drawable::draw_layer_(class std::shared_ptr<class Esri_runtimecore::Map_renderer::Canvas_renderer::Draw_request> const &)
runtimecore.dll!<lambda>(void)()
runtimecore.dll!std::_Func_impl_no_alloc<<lambda_fbfe540b7589c2b09cbd9ad0d74b0839>,unsigned char>::_Do_call()
runtimecore.dll!pplx::details::_PPLTaskHandle<unsigned char,pplx::task<unsigned char>::_InitialTaskHandle<void,<lambda>(void),pplx::details::_TypeSelectorNoAsync>,pplx::details::_TaskProcHandle>::invoke()
runtimecore.dll!pplx::details::_TaskProcHandle::_RunChoreBridge(void *)
runtimecore.dll!Esri_runtimecore::Common::Core_scheduler::bridge_proc_(void *)
runtimecore.dll!Esri_runtimecore::Common::Windows_Threadpool_scheduler::Scheduler_param::work_callback(struct _TP_CALLBACK_INSTANCE *,void *,struct _TP_WORK *)
ntdll.dll!77da187a()
ntdll.dll![Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!77da0920()
kernel32.dll!77790419()
ntdll.dll!77db66dd()
ntdll.dll!77db66ad()

Unfortunately I am unable to test in 100.7 due to the gap in functionality with local locators (new style) running on 32-bit.  I have been told that this functionality is returning in 100.8.

0 Kudos
MichaelBranscomb
Esri Frequent Contributor

Kyle,

Well the good news at least is that you can consistently reproduce the issue... I've enabled your access to a preview of ArcGIS Runtime SDK for .NET 100.8 Build 2760. Next time you sign into the ArcGIS Runtime Preview program you should see this under the available downloads. This also includes support for the new locator format when compiling for x86/32-bit.

Can you retest?

Thanks

Mike

KyleGruber
Occasional Contributor II

Michael,

Thank you, it appears only the ESRI.ArcGISRuntime.WPF package is available in this, and I'm prevented from upgrading because ESRI.ArcGISRuntime is on 100.6/100.7.  Am I missing something?

Sorry, nevermind, I figured it out, thanks.

0 Kudos
KyleGruber
Occasional Contributor II

Michael Branscomb

Unfortunately I am still able to reproduce this in 100.8, and furthermore it doesn't seem Visual Studio can detect the needed symbol files for the version I have (runtimecore 100.08.0.2760).  This is the stacktrace I get now:

runtimecore.dll!5a0638a7()
runtimecore.dll![Frames below may be incorrect and/or missing, no symbols loaded for runtimecore.dll]
runtimecore.dll!5a062498()
runtimecore.dll!5a0491ba()
runtimecore.dll!5a04b34a()
runtimecore.dll!5a04c6d8()
runtimecore.dll!593d2242()
runtimecore.dll!5a04c6f3()
runtimecore.dll!593d0c67()
runtimecore.dll!5a9e9f3e()
runtimecore.dll!5a9eb06d()
ntdll.dll!TppWorkpExecuteCallback()
ntdll.dll!_TppWorkerThread@4 ()
kernel32.dll!@BaseThreadInitThunk@12 ()
ntdll.dll!__RtlUserThreadStart()
ntdll.dll!__RtlUserThreadStart@8 ()

Any ideas or will I need to update to the official 100.8 release and get another dump file?

0 Kudos
MichaelBranscomb
Esri Frequent Contributor

Kyle,

Thanks for retesting. We are currently in the process of publishing the 100.8 symbols. But yes, you should remove the preview NuGet package(s) and update to the now available official 100.8 release (build 2768).

Thanks

Mike   

0 Kudos
KyleGruber
Occasional Contributor II

Michael Branscomb

Thanks, I went ahead and updated to the official nuget release and confirmed the crash is still occurring.  Any idea when the 100.8 symbols are planned to be available?  I'm 90% sure this has something to do with the GraphicOverlays I'm using (as just loading the MMPK and base layer in a repro app will not allow this to reproduce), but I can't say what it is if anything I'm doing wrong with the GraphicOverlays/Graphics, and can't say with complete certainty that this is the problem (the app crash doesn't seem to be linked with panning the map to an area where there's a graphic, but I don't know if that even matters).

I have a GraphicOverlay with static rendering that generally has 70-100 graphics on it that are getting updated on intervals between 1-30 seconds.  Is it possible this is posing an issue?  When I set the rendermode to dynamic, strange things start happening with labels (they don't move along with the graphic), but I'm about to try it to see if it makes any difference with the crashes. Edit:  Did not make a difference with the crashes and makes the experience way worse (all graphics on a GraphicsOverlay flicker when you update one, label drift as previously mentioned).

0 Kudos