Random Crashes of ArcMap 10 (using Custom Extension)

[BarbaraSchneider1]

I use a Custom ArcMap Extension. I also use Stereo Analyst for ArcGIS Extension.

When running ArcMap 10 (with the two extensions), I get random, non-reproducible crashes. With ArcMap 9.3.1 these crashes didn't occur.

Description:
Faulting application name: ArcMap.exe, version: 10.0.2.3200, time stamp: 0x4d9bad9f
Faulting module name: MSVCR90.dll, version: 9.0.30729.6161, time stamp: 0x4dace5b9
Exception code: 0xc0000417
Fault offset: 0x0006ccd5
Faulting process id: 0xc3c
Faulting application start time: 0x01cc7771cbb9ef76
Faulting application path: C:\Program Files (x86)\ArcGIS\Desktop10.0\Bin\ArcMap.exe
Faulting module path: C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCR90.dll
Report Id: 3c6c1f96-e365-11e0-bb0f-00199991eda6

I assume the following:
- The crash happens in MSVCR90.dll, which is a Microsoft C runtime library, part of Microsoft® Visual Studio 2008
- The error must be somewhere below, i.e. in the ArcMap or Stereo Analyst Code, not in my code

Are my assuptions right?
What can I do?

Thanks,
Barbara

[RichardWatson]

Your assumptions are not necessarily correct.

The first thing that you want to look at is the call stack when the crash occurs.  Hopefully, the code which is the root cause of the problem is in the stack.  When the problem occurs you should be able to attach the Visual Studio debugger to the process and view the call stack (make sure that you attach to debug both managed and unmanged code).  I definitely recommend that you use the ESRI public symbols to assist.

If you (or ESRI) have corrupted memory then the crash can occur at some interdeterminate time later.  These type of problems are very hard to debug.

What language are you using to program? 
Are your programs multi-threaded? 
What type of extension(s) did you develop?

If you have random non-reproducible crashes then ESRI support will not file an issue for you.  Is the problem really random?  Perhaps it is data specific.

[BarbaraSchneider1]

Hi Richard,

thank you for your information! As the crashes are random, it will probably take some time until the next crash occurs and I can look at the call stack.

- I program with C# (Visual Studio 2008)
- No, my programs are not multithreaded
- I have developed an application extension with a couple of custom commands (for ArcMap)

I'll keep you posted,
Barbara

[RichardWatson]

Search your disk drive for ArcMap dump files (*.dmp).  I think that something like the last 10 are kept.  You can open them in Visual Studio and view the call stack.

If you are programming in .NET, not doing P/Invokes, and not doing any multi-threading then the problem is likely not yours.

[BarbaraSchneider1]

Hi Richard,

attached, you can see the call stack. LFI.dll is the dll containing my application extension and my custom commands.

I have no clue what the calls stacks tells... (except where the crash in my program occurs, which I already know). Do you understand more?

Thanks,
Barbara

[BarbaraSchneider1]

Better image (zipped)

[RichardWatson]

Suggest that you set up debug symbols in Visual Studio:

http://resources.esri.com/help/9.3/ArcGISDesktop/dotnet/37148c9a-1bd3-4a20-82f1-edc81f9c0347.htm

Hopefully, the resulting call stack will have more information.

It appears that code is crashing due to a null pointer dereference.  The obvious question is is what is dvodisplay?

[BarbaraSchneider1]

I had already set up the debug symbols according to http://resources.esri.com/help/9.3/A...c81f9c0347.htm !

[BarbaraSchneider1]

Ok, for me, the case is clear: dvodisplay.dll is an ERDAS Stereo Analyst dll. This is also what I suspected from the beginning: The problem is in Stereo Analyst.

Anyway, thanks a lot for your help, Richard, it was very useful!

Barbara