This content has been marked as final. Show 8 replies
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.
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,
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.
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?
CallStack.jpg 87.4 K
Suggest that you set up debug symbols in Visual Studio:
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?
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!