windows dump file (hdmp) - information without pdb files

Question

I received dump files (.mdmp and .hdmp) from a crash of our software due to a memory leak (which was on a nother computer). The software consists of one exe-file and many .dll files. I do have the source code (part c++, part delphi) but I do not have the .pdb files for that exact build.

I can open the mdmp/hdmp in visual studio or in WinDbg. But I do not gain a lot of information because I do not have the .pdb files. Since the hdmp file is ~4gb big, I hoped that I have a lot of information already, even without the pdb files. But I do not get an really usefull stack trace or other information, for example when I use the command

!analyze -v

Is it somehow possible to get better results? Can I somehow find out how much memory every dll uses (or rather processes which are connected to specific dlls)? Since I have the source code, can I use newly generated pdb files (for the c++ modules)? Even if they are not 100% accurate. It would already be an great help, to know which module caused the memory leak!

See [this question and answers](https://stackoverflow.com/questions/21886338/crash-dump-windbg-force-pdb-files-to-match-doesnt-work). — Patrick Quirk, Jul 17 '17 at 14:00
"Processes"? One dump is only for one process. Also, memory is allocated per process, not per DLL. — Thomas Weller, Jul 17 '17 at 14:51
Say you built PDBs, how do you find out they are 99% accurate or only 1% accurate? Which compiler version did you use, which environment, which source? Changing any of these might change the result. — Thomas Weller, Jul 17 '17 at 14:56
@ThomasWeller I guess per Thread, would be the correct terminology?! Per DLL is (at least) one process is started. I hoped that it is possible to see the memory use per Thread, and then find out to which dll it "belongs". — deetz, Jul 17 '17 at 15:11
@ThomasWeller I gues I cannot at all! However every clue right now is apreciated. I use the same compiler version, compiling environment and source. I am not 100% sure, if I use the same configuration, though. — deetz, Jul 17 '17 at 15:12
Even if you can find a tool to create PDBs from Delphi source (and there is no such tool that works well) then it's unlikely that you could re-create the exact build of the executable anyway. What you need to do is add something like madExcept to your software so that you can debug such problems in the future. If there's a defect in your program, it will likely occur again. — David Heffernan, Jul 17 '17 at 15:17
Threads share memory, not the stack maybe, but the heap(s) at least. Otherwise you would not be able to exchange data wetween a producer thread and a consumer thread. — Thomas Weller, Jul 17 '17 at 15:17
@DavidHeffernan I forgot to say, that the effect is very likely is connected with one of the c++ modules. But thanks for the hint. — deetz, Jul 17 '17 at 15:19
@ThomasWeller okay, so it is not possible to find out this way, which thread (and therefore dll) is causing the memory leak/ respectively a high use of memory? Thats to bad. — deetz, Jul 17 '17 at 15:22

score 4 · Accepted Answer · answered Jul 22 '17 at 09:25

You can load pdb files without an exact match of the version.for that you have to use the command .symopt +40 which is load anything SYMOPT_LOAD_ANYTHING

0:000> .symopt
Symbol options are 0x30237:
  0x00000001 - SYMOPT_CASE_INSENSITIVE
  0x00000002 - SYMOPT_UNDNAME
  0x00000004 - SYMOPT_DEFERRED_LOADS
  0x00000010 - SYMOPT_LOAD_LINES
  0x00000020 - SYMOPT_OMAP_FIND_NEAREST
  0x00000200 - SYMOPT_FAIL_CRITICAL_ERRORS
  0x00010000 - SYMOPT_AUTO_PUBLICS
  0x00020000 - SYMOPT_NO_IMAGE_SEARCH

Now you have to run another command !sym noisy .This will enable noisy mode on

0:000> !sym noisy
noisy mode - symbol prompts on

Once you do this,u can run the analyze command and you will start getting all the symbol loading messages and where windbg looks for the symbol.

make sure you add the pdb files path to the symbols path which windbg looks by using .sympath

0:000> .sympath 
Symbol search path is: srv*c:\symcache*http://msdl.microsoft.com/download/symbols
Expanded Symbol search path is: srv*c:\symcache*http://msdl.microsoft.com/download/symbols

Please note that sometimes even if we add the sympath,some symbol files it will look in some folders.In that case what i do is copy the pdb files to the folder where windbg is looking.

e.g.

DBGHELP: ntdll - public symbols
c:\symcache\wntdll.pdb\B5ACAC3B4A6C4515AF416D60366399652\wntdll.pdb

I will just copy the pdb file to c:\symcache\wntdll.pdb\B5ACAC3B4A6C4515AF416D60366399652.

having said that

A native c++ memory leak is difficult to analyze without a leaktrack dump.

Please try to use DebugDiag native memory leak analysis and it should tell you what heap is taking the memory.If it is some custom library heap,you can try and update this particular component.Following articles might help you

debugging-native-memory-leaks-with-debug-diag-1-1

walkthrough-troubleshooting-a-native-memory-leak

using-debugdiags-leaktrack-with-procdumps-reflected-process-dumps

windows dump file (hdmp) - information without pdb files

1 Answers1