App crash caused by RuntimeCoreNETDesktop

02-17-2021 12:53 PM
New Contributor


I am running into an issue where a client is experiencing sporadic application crashes which seem to be caused by the RuntimeCoreNETDesktop.dll or msvcr120.dll. We are using ArcGISRuntime 10.2.7.

I have not been able to reproduce this crash on my own machine.

I have a number of dump files from the client, and analyzed them in WinDbg to get the stack traces. These can be seen in the attached document.

Executing !analyze -v produces the same result on each of the dump files:

msvcr120!abort+28 [f:\dd\vctools\crt\crtw32\misc\abort.c @ 88]
67207666 cd29 int 29h

ExceptionAddress: 67207666 (msvcr120!abort+0x00000028)
ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
ExceptionFlags: 00000001
NumberParameters: 1
Parameter[0]: 00000007

ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

With the stack traces, it seems 3 of them are throwing the exception when calling:

10d7f80c 67a73105 RuntimeCoreNETDesktop!VSIVirtualHandle::Truncate+0x11125, calling msvcr120!_CxxThrowException

And 2 of them are throwing the exception when calling:

0fd4fa5c 673332a2 RuntimeCoreNETDesktop!DistanceCompositeSymbol_GetInfos+0xf42, calling msvcr120!_CxxThrowException

Does anyone have any ideas or suggestions on things I can check to determine what is causing these crashes?

0 Kudos
4 Replies
Esri Frequent Contributor


#. Has this only started happening recently?
If so, did the environment change in some way? Windows update? Graphics driver update? C++ runtime redistributable update (unless you're using app-local deployment)?

#. What is the end user doing at the time of the crash?
e.g. are they switching tabs in the UI or is something happening automatically on a timed interval?

#. What’s the memory usage at the time of the crash?
If it’s a x86 process and the memory reaches approx. 1-1.2GB it could be an out of memory issue. In that case perhaps you can try Any CPU + Prefer 32-bit which will give more room (equivalent to setting the LargeAddressAware flag I believe).

0 Kudos
New Contributor

Hi Michael, thanks for the reply.


This began occurring ~2 months ago. The client says their machines are exempt from routine OS updates and there have not been any updates for over a year. Their drivers are also not routinely updated and have been the same for more than a year.

Not all machines are affected by this issue. The client reports that all machines are configured the same way with the same patches installed. No differences in hardware or software.

I have requested the dxdiag output from the affected and unaffected machines and am waiting to receive this.

There is no pattern of user actions before the crashes occur. The users have been doing many different things at the time the crashes are experienced. This does not appear to be getting triggered by an event happening on a timed interval.


As for memory usage, DebugDiag memory analysis shows the following:

Virtual Memory Summary

Size of largest free VM block 15.62 MBytes
Free memory fragmentation 89.67%
Free Memory 151.3 MBytes (7.39% of Total Memory)
Reserved Memory 300.95 MBytes (14.7% of Total Memory)
Committed Memory 1.56 GBytes (77.92% of Total Memory)
Total Memory 2 GBytes
Largest free block at 0x00000000`7e540000


Heap Details

Heap 1 - 0x02350000 | NT Heap

Heap Name Microsoft VC Runtime Heap (private)
Heap Description This is a private CRT heap used by clrcompression
Reserved memory 624.04 MBytes
Committed memory 479.96 MBytes(76.91% of reserved)
Uncommitted memory 144.07 MBytes(23.09% of reserved)
Number of heap segments 26 segments
Number of uncommitted ranges 334 range(s)
Size of largest uncommitted range 14.54 MBytes
Calculated heap fragmentation Unavailable

0 Kudos
Esri Frequent Contributor

Assuming I'm reading memory report correctly, it appears even the available virtual memory is largely used and has a high level of fragmentation. 

When the problem occurs, have the machine and application been running for a long period of time? 

0 Kudos
New Contributor

Thanks again for the reply.

The crash dumps provided show that the application has usually been running for a few days at the time this occurs. This is not unusual for the application and we advise clients reboot their workstations every ~7 days.


System Up-Time 5 day(s) 05:43:32
Process Up-Time 2 day(s) 15:13:45


System Up-Time 3 day(s) 11:54:07
Process Up-Time 3 day(s) 11:53:34


System Up-Time 2 day(s) 07:48:50
Process Up-Time 2 day(s) 07:48:18


System Up-Time 3 day(s) 19:44:46
Process Up-Time 3 day(s) 18:24:36


0 Kudos