0

Basically I create dump file:

  1. Under debug : VC10 Debug->Save dump as...
  2. Under release: Procexp->right click -> Save dump -> Create Full Dump...

Via 1, I can open the dump file with VC10 (symbol path, Debug source file all setup properly), I can see all the stack information with source code as well as the value of all variable .

Via 2, I can open the dump file with VC10 (symbol path, Debug source file all setup properly), I can see all the stack information with source code BUT values of all variable are not there. Even if I put the local variable into Debug Watch window,it says Error: Symbol "xxx" not found. How should I fix this for 2?

How did my setup the dump debugging?

For symbol path:

Action->Set symbol paths -> add pdb path for Debug & Release folder for my project as well as using Microsoft Symbol Servers.

For Debug Source path:

Dump project solution -> Property-> Debug Source Files -> Add my project file folder

BTW: For the same dump file, I have also used WinDbg and I can see all the stack information as well(after setting symbol and source path correctly).

Thanks

RoundPi
  • 5,819
  • 7
  • 49
  • 75
  • I think you are not going to get too much sensible information from variables if the dlls were compiled with any optimisation turned on, also I am not sure if a full dump is what you want, try creating a mini dump from procexp and see if it yields better results. – EdChum Dec 13 '12 at 15:01
  • It's basically a demo program which doesn't involves with DLL ...full dump suppose to have more information than mini dump but I will give it a go... – RoundPi Dec 13 '12 at 15:55
  • mini dumps with certain flags can contain more information than full dumps: http://stackoverflow.com/questions/6903329/minidump-vs-fulldump this is why I suggest trying a mini dump – EdChum Dec 13 '12 at 16:09
  • It's strange as I seems to have variable information ins some functions but not the the one had exception ! I have put a messagebox there to stop stack unwind still why ? – RoundPi Dec 13 '12 at 16:19

2 Answers2

2

A debug build is a build that ensures you'll get the best possible debugging experience. Looking at local variables is not a problem.

A release build turns on the code optimizer. It does many things to your code, but definitely the first victim are local variables. They may get entirely removed or stored in CPU registers. If you really do need to know the value of such a local variable then you typically need to look at the machine code to figure out what cpu register stores it. This will however never work if this is in code that's buried down the stack trace, the value would have been pushed onto the stack somewhere. Finding out where is next to impossible.

Debugging optimized code is hard, no two ways about it. Get the bugs out with the debug build, Hail Mary on the release build.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
0

Thanks for all the nice inputs but I think I have found the reason myself today!

Reason: It was a build issue,some components the exe need to use have not been build properly !

Note: In my case "mini dump" 7M and "full dump" 112M does the same job, both created from procexp. And once I load them in VS I have access to:

  1. All the stack information
  2. All the variable information
  3. It pinpoints to the exactly location once I switch stack to my code from kernel32.dll!_UnhandleExceptionFiler.

So essentially as long as you set up VC10 like I did above & below, you should be fine:

For symbol path:

Action->Set symbol paths -> add pdb path for Debug & Release folder for my project as well as using Microsoft Symbol Servers.

For Debug Source path:

Dump project solution -> Property-> Debug Source Files -> Add my project file folder

RoundPi
  • 5,819
  • 7
  • 49
  • 75