0

I have a dump file collected by an user experiencing a problem while running my C++ application, and I'm trying to figure out whether the application has crashed. From what I can see in the dump file, there is no exception or error indicating a crash, nor are there any deadlocked threads competing for a mutex or other synchronisation object.

enter image description here

The program location for the main thread at which the dump was created is a call to a virtual function, but the vtable for the object is correct and points to the right function, e.g. the code is

FindIt = m_EntityList[m_ListPos]->GetChainageOffset(X,Y,Chainage,Offset);

and looking at the variables I see

enter image description here

Am I right in thinking that this doesn't seem to be a page fault / illegal dereference or am I missing something here? I've checked all the other threads in my thread pool and they are inactive. Would a dump file always have an exception code and error information in the case of a crash?

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
SmacL
  • 22,555
  • 12
  • 95
  • 149
  • Do you try to use Windbg to do an analysis on the dump file? It will tell you if the exe crashed – Matt Nov 14 '16 at 16:27
  • @Matt, I used VS2015 to debug the dump file which was the compiler used for development. Windbg has difficulty loading all the symbols. Does it offer any advantages over the VS2015 debugger, as this is giving me program locations for each thread? – SmacL Nov 14 '16 at 16:38
  • In common cases, VS will do. Windbg certainly can get more information from the dump, more info here:http://stackoverflow.com/questions/105130/why-use-windbg-vs-the-visual-studio-vs-debugger – Matt Nov 14 '16 at 16:45
  • How was that dump generated? I'd say it didn't crash. All the tools described [here](http://stackoverflow.com/questions/24874027/how-do-i-take-a-good-crash-dump-for-net) will have an exception code in case of a crash. But even if it didn't crash and is just in normal operation, those tools will inject a new thread that has a breakpoint inside. This breakpoint will "crash" the application (exception code 0x80000003) and that will be visible as exception code as well. So, what you have is very strange. How was the crash dump taken? – Thomas Weller Nov 21 '16 at 16:11
  • Crash dump was created from Task Manager by right clicking on the process and selecting Create Dump File. Further debugging showed it was a bug in the software, where the array was being updated by another thread without checking a lock first. – SmacL Nov 22 '16 at 15:08

1 Answers1

0

I would suspect dereferencing of already freed object. This could be either your class object or some object inside problematic method. Do you set every pointer to NULL after using delete/free?

//Edit: This was supposed to be a comment instead of answer, but I clicked incorrect button (phone app)

woockashek
  • 1,588
  • 10
  • 25
  • I would have also suspected dereferencing an invalid object, but I the debugger shows the memory being referenced as valid, and I would have thought that this would get listed as a page fault or similar exception in the summary. – SmacL Nov 14 '16 at 16:40
  • Have you checked the parameters as well? – woockashek Nov 14 '16 at 16:54