Is there a Windbg command for retrieving the module_name of a dump?

Question

I'm working with windbg, using a script that I found somewhere on the internet, for investigating dump files of a C++ application.

That script launches two commands: one to determine all symbols, present in the dump (at least that's what I think), and one for showing the memory addresses and types of all variables.

The first command: x /2 *!*

The result contains entries like:

0042da68          <application>!CMap<int,int,CStringArray *,CStringArray *>
...
74c06448          mfc110u!CStringArray

The second command is more complicated and gives following results:

006cabe0    <application>!CMap<int,int,CStringArray *,CStringArray *>
...
006f0280    mfc110u!CStringArray

I'm interested in the size of the CMap and CStringArray objects, so I'm launching following commands:

dt <application>!CMap<int,int,CStringArray *,CStringArray *> m_nCount 006cabe0
dt <application>!CStringArray m_nSize 006f0280    

This is working fine, I get the information I need.
Also this seems to be working fine:

dt CStringArray m_nSize 006f0280    

But this one is failing:

dt CMap<int,int,CStringArray *,CStringArray *> m_nCount 006cabe0

This means that I need to get the name of the application of the dumpfile (it seems to be gone during some formatting).

I can retrieve this using the !analyze -v command (do a grep on MODULE_NAME), but this looks a terrible burden just to get the name of the application.

Does anybody know the windbg command I need to run in order to know the application of the dump I'm investigating?

Answer 1

The executable being debugged can be found with |:

0:000> |
.  0    id: 13ac    create  name: C:\Program Files (x86)\Notepad++\notepad++.exe

However, that executable name may significantly differ from its module name:

0:000> lm m note*
Browse full module list
start    end        module name
01150000 013bf000   notepad__   (no symbols)  

From the output of lm, we can see that there are addresses associated with the module. If we would be able to map the entry point to a particular module, we would have a solution.

Luckily, there is $exentry which gives us the entry point and lm accepts an address with lm a <address>, so we have:

0:000> lm a $exentry
Browse full module list
start    end        module name
01150000 013bf000   notepad__   (no symbols)  

This would still require a lot of parsing, but you can use the lm 1m approach as well:

0:000> lm 1ma $exentry
notepad__