100.1.0 application crashes occasionally

1522
3
03-23-2018 11:26 AM
AlexZlotin1
New Contributor III

I am investigating a problem with an ArcGIS Runtime application periodically crashing in client’s environment during testing.

 

The application is a WPF control we built with ArcGIS Runtime 100.1.1744. It is embedded in a .NET application built by the client. The client is running a simple automated test using scripts. They launch their application (which in turn initializes the embedded map in our control), wait for a minute or two and then shut it down. During this test their application crashes on initialization, once or twice in an hour, which makes it one failure in 20-30 successful attempts. The last entry in the log their application writes is successful initialization of our map control. We have a method called InitializeMap which has proper error handling. This method executes successfully every time, but something in the map control appears to fail after that. The client is using Windows 10 Pro Version 1511 for their testing. The GIS data for the map is stored in a local map package (MMPK), which includes layers, locator (for geocoding) and a network (for routing). The basemap is loaded from ArcGIS Online. The WPF control is compiled with the "Any CPU" option.

 

The Windows event logs from the crashes point to one of two specific DLLs and also the “unknown” module:

 

Faulting application name: LibertyShield.exe, version: 17.3.1731.0, time stamp: 0x5ab29957

Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000

Exception code: 0xc0000005

Fault offset: 0x12ef2c98

Faulting process id: 0x690

Faulting application start time: 0x01d3c2a9e14fd713

Faulting application path: C:\EdgeIQ\LibertyShield\LibertyShield.exe

Faulting module path: unknown

Report Id: 5dc3f507-e0a1-45c2-981f-1bbcc2416124

 

Faulting application name: LibertyShield.exe, version: 17.3.1716.0, time stamp: 0x5aaa8c87

Faulting module name: RuntimeCoreNet.dll, version: 100.1.0.1744, time stamp: 0x594c5efd

Exception code: 0xc0000005

Fault offset: 0x004c00c1

Faulting process id: 0x2e50

Faulting application start time: 0x01d3c13e991056ac

Faulting application path: C:\EdgeIQ\LibertySHIELD\LibertyShield.exe

Faulting module path: c:\edgeiq\guardianmap\arcgisruntime100.1\client32\RuntimeCoreNet.dll

Report Id: 07d90b83-d23c-4bef-8fa1-06ff7035c16b

 

Faulting application name: LibertyShield.exe, version: 17.3.1731.0, time stamp: 0x5ab29957

Faulting module name: ucrtbase.dll, version: 10.0.10586.1176, time stamp: 0x59ba0a90

Exception code: 0xc0000409

Fault offset: 0x000834b2

Faulting process id: 0x15f4

Faulting application start time: 0x01d3c2a453ac0540

Faulting application path: C:\EdgeIQ\LibertyShield\LibertyShield.exe

Faulting module path: C:\WINDOWS\SYSTEM32\ucrtbase.dll

Report Id: 0e5a9948-ef8a-42da-a4e2-20f6a85bbd75

Faulting package full name:

Faulting package-relative application ID:

 

The client also mentioned that they have seen a similar error in the past in unrelated tests, with the faulting module being kernelbase.dll.

What should we do to try and isolate this issue? Thanks for any ideas.

Alex

3 Replies
MichaelBranscomb
Esri Frequent Contributor

Hi,

The first thing I would try is upgrading to v100.2.1. There were a number of performance and stability improvements from 100.1 to 100.2.1. 

If it still not resolved, then we'll need the standalone repro case - a small app that shows how you load the mmpk/map/layers and any other initialization logic that touches Esri.ArcGISRuntime.WPF API. And we'll need the mmpk. If you're not able to attach/upload here then please email mbranscomb@esri.com.

Cheers

Mike

0 Kudos
BjørnarSundsbø1
Occasional Contributor II

This seems similar to the issue we are having, reported in [Application Crash] Frequent win32 exceptions in 100.2 . I can not be sure it's the same issue, the exception code from this post is the same as one of the errors I get.

While we do not use mmpk, one of the exceptions seem to be related to startup when adding features to the map using epsg:25833, and features are added with epsg:4326. From the few attempts I made using using the default basemap getting data from ArcGIS Online using epsg:4326, I was unsuccessful to recreate. The same issue is also present  in 10.2.7.

A bug report with a repro sample for my issue has been submitted a while ago and confirmed, however I am not aware of the current status. I still suggest you post your own sample if possible, in case they are not related. And try not be too influenced by my scenario for recreation in case they are indeed different issues 

0 Kudos
AaronMurphy3
New Contributor III
0 Kudos