Is the state shown in an application crash dump accurate on Windows when taken from Task Manager?

0
votes

Basically, an application froze in a VMWare image (Win764) so I created an application crash dump by using the Task Manager. It created the crash dump just fine. I then opened the crash dump using WinDbg while linking to the symbols which worked perfectly as I could now see all the threads, processes, and call stack. When I click on an item in the call stack it opens up a window within WinDbg showing the actual line of code in the source file that it was on for that part of the call stack.

Now my question is how accurate/reliable is the information shown in WinDbg while debugging in this manner? It appears that sometimes the state it shows the application was in doesn't make any sense at all ... like it shows impossible scenarios or a scenario that 100% never have happened. For example, I've seen it shows that an operation started and completed but when I check the log files which were written correctly showing that the operation never happened. It logs that it never happened and it successfully moved onwards after. Also, the end result of the operation, had it completed, absolutely didn't happen. It's pretty obvious to see if the operation actually started and happened.

Is it ever possible that the crash dumps are just flat out wrong or showing old information, in any way?

1
c++windows-7windbgcrash-dumps
You can't trust your log files when you don't have a guarantee that the process got a chance to flush the buffers and/or close the file handle. You have no such guarantee when the app is "frozen". Furthermore, you just can't make any assumptions about program state if the app misbehaves that badly. Something went pretty wonky and your minidump shows, well, wonky stuff. – Hans Passant
I'm completely agree with Hans, the only issue I'm aware of is to use the 32 bits task manager to take dumps if the process is a 32 bits running on a 64 bits platform. See google.no/… – Kjell Gunnar
Ok, so when it breaks I should get a crash dump but when it breaks the crash dump is not reliable so don't trust the dump. What is the point then? So you can maybe sometimes get some possibly relevant information? I just don't get it. – Brian T Hannan
The window is still showing on the screen and is grayed-out like all apps do when Windows decides it's not responsive. How could it possibly have hit the OnDestroy() function if the window was never closed programmatically by my code or manually by the user? Can an exception do this or some other random failure that leaves the window open and the rest of the app open? I'm just trying to wrap my head around how this could possibly happen. Some others think the dump is just not correct. – Brian T Hannan
Do you have correct .pdb ? Can you update your posting with the stack (kv) and output from the !analyze -v – Kjell Gunnar

1 Answers

0
votes

Any dump I have seen so far was correct in the way that it exactly showed the process at the time of taking the dump. But there are some things to remember:

  • make sure you look at the correc source code which really matches the version of the dump. I had that situation often: I'm looking at the wrong version of source code and my impression is that this situation would never happen.
  • if the application has corrupted something (e.g. the stack), you will only see the corrupted stuff in the dump as well, which may sometimes be misleading. You need to find out by yourself if you trust what you see.
  • if the application looks frozen, it can still have changing stacks because it is in an endless loop. Take several dumps of the frozen application to see what changes.
  • log output may not be up to date (as stated by Hans Passant already), for several reaasons: either the buffer was not flushed or the application crashed the log file by overwriting the file name, destroying the file handle etc.