What causes UMDH to fail to give stack traces

Question

I've used UMDH a dozen times before, never with any problem.

Suddenly I don't get a function names in the stack traces in my dump files - just a series of addresses.

I've got ust enabled:

gflags exe_name +ust

I start exe_name, then I do

umdh -p:pid one.txt umdh -p:pid two.txt

I look at one.txt and two.txt and they have no indications of where these are coming from. When I do the diff

umdh one.txt two.txt > diff.txt

the result is not useful.

Help, I love this tool.

Answer 1

UMDH switches syntax changed slightly somewhere in the last releases of debugging-tools-for-windows. Perhaps that's the issue. Try the following -

umdh -p:pid **-f:**one.txt

umdh -p:pid **-f:**two.txt

umdh -v -l one.txt two.txt > diff.txt

(-l is a new switch, extracting file and line numbers from the PDBs). And again, make sure the _NT_SYMBOL_PATH environment variable includes the path to your PDB.

Docs are now available also online.

(EDIT:) the critical switch in the comparison, -v, is now present...

(EDIT:) You did not specify your operating environment. It is well known that on VC8, CRT's malloc was compiled with FPO - which UMDH cannot overcome. It is also known (see Pavel Lebedinsky's comment) that UMDH cannot handle certain allocator types, e.g. SysAllocString. If you are indeed using some exotic allocators, you might want to give LeakDiag a try - it handles much more of them.

Answer 2

UMDH does the PDB association when you do the command:

umdh -d one.txt two.txt -f:outputfile.txt

Not when you originally take the snapshots. You have to let it do the diff for you!

And, yeah...you need to have your symbol path set properly.

Answer 3

The mapping between executable addresses and function names are defined in PDBs.

Make sure your symbol path is set correctly,
especially if you a running UMDH on a different machine than the one that compiled the code.