0

I'm a developer of Windows desktop software, and from time to time our app crashes. In rare cases I'd like to get a customer to run a debug version of the app to send me a stack trace so I know where it crashed. I followed the instructions in here:

Windows C++ stack trace from a running app

...but while it works on my development machine, it doesn't work on any client machine or those of my colleagues, who don't have Visual Studio installed. So I presume that there's some .dll or something they need before it'll work. They're using the same .exe I'm using, i.e. the one I compiled in VC++ in debug mode.

After some painstaking "message window" debugging, I learnt it's failing in SymGetSymFromAddr64() - this returns FALSE. But when I walk the stack, this always returns FALSE or it returns garbage that doesn't make sense (random unrelated method names), as if it's the PC values which are invalid, not the mapping process. To reiterate, it's a debug mode .exe that produces a perfect symbolic stack trace on my development machine.

I did some research and found some mentions of "dbghelp.dll" and "imagehlp.dll" but I just ended up confused. "dbghelp.dll" ships with all versions of Windows, but with reduced functionality. There's some other things I could install, but it's a little scary to be installing some Windows "WDK" or "debug kits" which might overwrite important system .dll's or do god-knows-what to your computer.

So what I need to know is: "what's the simplest set of instructions I can give to these helper customers e.g. the minimum set of .dll's and where to stick them so that we can get proper symbolic information out of the stack traces when our program crashes?"

Community
  • 1
  • 1
Tim Cooper
  • 10,023
  • 5
  • 61
  • 77
  • [It doesn't work](http://www.chiark.greenend.org.uk/~sgtatham/bugs.html#respect) is not enough information. – Bulletmagnet Feb 20 '15 at 08:12
  • @Bulletmagnet You're right, see the amended question. – Tim Cooper Feb 24 '15 at 00:45
  • Are you providing both the .pdb and the .exe together in the same folder, under the same name when you ship to your clients? If you move the location of the .exe on your dev machine, does it still work there? – niemiro Feb 24 '15 at 00:50
  • Also, for what it's worth, the WDK and the like are safe to install. They just extract some files into a directory of your choice and place a few environmental variables. They don't cause harm. However, I don't think they're necessary here. – niemiro Feb 24 '15 at 00:51
  • As an alternative, you could opt for a crash dump. Then you supply the analysis and symbols on your own computer. Here's a good guide to get you started if you opt for this: http://www.codeproject.com/Articles/207464/Exception-Handling-in-Visual-Cplusplus. The code sample provided is a good place to begin and is released under a fairly permissive license as far as I can tell (IANAL). Just be slightly careful of how you handle Ctrl-C terminations if this is a console application though. Out of box that crash dump library can cause a crash of its own! Just don't handle SIGINT. – niemiro Feb 24 '15 at 00:56
  • @niemiro The only .pdb file I can find is one called "vc90.pdb", modified about 1 day before my most recent changes. Aren't the symbols stored in my .exe file if I've selectede "debug mode"? – Tim Cooper Feb 24 '15 at 00:59
  • @TimCooper I think that that's quite likely to be your problem. I'm pretty sure external symbols are required for this function to work, and vc90.pdb isn't sufficient. What is your Properties > Linker > Debugging > "Generate Debug Info" property set at? Put it at "Yes" and see if a myapp.pdb is now generated next to myapp.exe. Also, how are you linking the VC++ library? – niemiro Feb 24 '15 at 01:03
  • @niemiro I've found the .pdb file, and renamed it to be exactly the same as the .exe i.e. Edval.exe and Edval.pdb, and in exactly the same folder on my colleague's machine. I presume I'm linking statically to the VC++ library(ies) because we don't ship any DLL's and it always works on customers' machines. And yet it still doesn't work. – Tim Cooper Feb 24 '15 at 05:37

1 Answers1

0

The most likely reason for failing to find the symbols is that the .pdb file cannot be found. Even if you generate a .exe in debug mode, the symbols are not in the .exe, they are in the .pdb file. Through a lot of empirical testing, it seems that the process has the pathname of the .pdb hardcoded in it, so if your clients don't have that file at that location, they won't necessarily find it. However, you can supply a "search path" to the SymInitialize() function - a folder or set of folders to use to search for the .pdb file.

In my configuration, I had an exe called "Edval.exe" and a .pdb called "DebugEdval.pdb". The process searches for "DebugEdval.pdb" in the search folders. This corresponds to what you've configured in "Properties > Linker > Debugging > Generate Program Database File".

Tim Cooper
  • 10,023
  • 5
  • 61
  • 77