0

We're in a situation where we are using MiniDumpWriteDump to generate a dumpfile. However we have noticed that if the code takes the path our code->MFC->our code the callstack ends at MFC and we lose the source of the problem.

This is a 64bit app.

Update due to original comments: An example from the other day was the following. We received a dump file from a customer. Loaded it into VS2017. The stacktrace stopped at MFC being (Our understanding) due to the mismatch between dumpfile and our development machine and no binaries on MS's symbol store. We eventually located a matching version of the MFC Dll on another machine on our network and the callstack was then fully completed and we could see it go back from our code -> MFC -> back to our code and locate the problem.

Is there a way to get the full callstack anyway, even if we don't get symbols/binaries for the MFC DLL's?

AKB
  • 31
  • 5
  • Generation of a stack trace usually does not rely on symbol information. Can you provide a [mcve] where this happens? Also, what debugger are you using to open the dump file? – IInspectable Mar 28 '18 at 00:42
  • Also make sure to include the stack trace you get in your question. – IInspectable Mar 29 '18 at 09:34
  • Could you be doing asynch calls or other threading type "calls" where you need to change to the proper thread to get the desired stack dump? Maybe provide a copy of the stack dump in question? – franji1 Mar 30 '18 at 19:10
  • @franji1 Checked that, nothing async. – AKB Apr 03 '18 at 02:16

1 Answers1

0

You have the MFC symbol files always in the folders of the current Visual Studio. So you should copy them or store them in your own symbol store.

In my VS 2017 (Version 15.6.3) I have the files in the folder

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.13.26128\atlmfc\lib\x64
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.13.26128\atlmfc\lib\x86

Using the correct PDB files will also help you to get the correct stack trace accross MFC boundaries.

xMRi
  • 14,982
  • 3
  • 26
  • 59
  • This does not address the issue, the OP is claiming to have. Apparently, they do not get a full stack trace, even before symbols come into play. `MiniDumpWriteDump` does not use symbol information. Although I'm still waiting for an MCVE. – IInspectable Mar 28 '18 at 09:24
  • Hmmm... I understand your comment. But I have seen such situations were the stack trace is complete (or better fixed) after the correct symbol files come in to play. This was the reason why I added this answer. – xMRi Mar 28 '18 at 09:27
  • 1
    Reconstructing stack frames using symbol information does indeed help resolving ambiguities. That option, however, is only available, if you already have a (full) stack trace. Having used `MiniDumpWriteDump` in MFC applications without any issues before, I'm not entirely convinced, that what the OP describe is actually what the OP have. – IInspectable Mar 28 '18 at 09:33
  • The MFC Dlls supplied by Visual Studio are not necessarily the same ones that are running on a user's machine. We are contemplating asking users permission to ship their DLL's with their crashdump but I was hoping to be able to get a full stack trace without having to have those. NOTE: This is 64 bit app. I have updated my post with this information and some further info. – AKB Apr 02 '18 at 21:32