I know – it really does seem like I’m on a bit of a Sesame Street kick at the moment, doesn’t it?  Ah well - it is Friday and the weekend is almost upon us.  Why not have a little fun?  Today, we’re continuing on with looking at different debugger commands.  Our topic for today is the lm command and its parameters.  As with our last post, we’ll take a look at the different options we can use with this command and then show you some examples.  So without further ado, let’s get started …

The lm command is used to display information about loaded modules.  When we are examining dump files, this is a command we use quite a bit to check version information and release date of different application files.  It’s definitely one of those “must know” commands!  Let’s start by looking at the different parameters:

Parameter Explanation
o Display loaded modules only
l Display loaded modules with symbols
v Verbose mode – includes the symbol file name, the image file name, checksum information, version information, date and time stamps etc
u (Kernel mode only) shows user-mode symbol information
k (Kernel mode only) shows kernel-mode symbol information
c Shows checksum data
sm Sort the display by module name rather than start address
i Shows the image file name
f Shows the full image path
n Displays the image name
p Displays the mapped image name
t Displays file time stamps
a Specifies an address contained in the module
m Specifies a pattern that the module name must match

As you can see there are quite a few different options to choose from.  Let’s take a look at what these commands and their respective outputs look like when run in a debugger.  For this post, I created a manual full dump of a Windows Vista virtual machine.  As with our last post, I’m only using the public symbols …

First, let’s run the basic lm command to list the loaded modules:

start    end        module name
00b10000 00b18000 svchost (deferred)
55600000 55635000 FwcWsp (deferred)
6d320000 6d341000 rdpendp (deferred)
6ee60000 6eec6000 audioeng (deferred)
6f7a0000 6f829000 wuapi (deferred)
701a0000 701c1000 audioses (deferred)
70260000 70272000 wscsvc (deferred)
708a0000 708b4000 MSACM32 (deferred)
712e0000 712f0000 wbemsvc (deferred)

There are a couple of things to note here – first, the modules are sorted by their start address.  However, the end column is the first address after the end of the module.  So if we take a look at the svchost module as an example, the module extends from 0x00B10000 to 0x00B17FFFF.  The final thing to note here is the deferred status.  This means that the module has been loaded, but the debugger has not loaded the symbols (yet).  This is called deferred symbol loading.  For more on this, see the MSDN topic on deferred symbol loading in the Additional Resources section.  Getting back to our topic, if you happen to be looking at a dump from a Windows 2003 or later system, you might notice the following section when you run the lm command:

Unloaded modules:
85fe7000 85ff4000 crashdmp.sys
85ff4000 85fff000 dump_ataport.sys
82b1a000 82b22000 dump_atapi.sys
82b22000 82b33000 dump_dumpfve.sys

This the unloaded module list.  If you are debugging a user-mode process or dump file, the lm command shows these modules as well.  If you use the lmo command then the unloaded module list is not displayed.  A very common command that we run is the lmv command.  This displays verbose information.  Now, if you run this command in the debugger, you will get the output for every module.  The output looks like this:

kd> lmv
start end module name
00b10000 00b18000 svchost (deferred)
Image path: C:\Windows\System32\svchost.exe
Image name: svchost.exe
Timestamp: Fri Jan 18 23:32:57 2008 (47918B89)
CheckSum: 00012FFA
ImageSize: 00008000
File version: 6.0.6001.18000
Product version: 6.0.6001.18000
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 1.0 App
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft® Windows® Operating System
InternalName: svchost.exe
OriginalFilename: svchost.exe
ProductVersion: 6.0.6001.18000
FileVersion: 6.0.6001.18000 (longhorn_rtm.080118-1840)
FileDescription: Host Process for Windows Services
LegalCopyright: © Microsoft Corporation. All rights reserved.
55600000 55635000 FwcWsp (deferred)
Image path: c:\Program Files\Microsoft Firewall Client 2004\FwcWsp.dll
Image name: FwcWsp.dll
Timestamp: Sat Dec 09 10:40:19 2006 (457AE6F3)
CheckSum: 0003A4A3
ImageSize: 00035000
File version: 4.0.3442.654
Product version: 4.0.3442.654
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft (R) Corporation
ProductName: Microsoft Internet Security and Acceleration Server
InternalName: FwcWsp
OriginalFilename: FwcWsp.dll
ProductVersion: 4.0
FileVersion: 4.0
FileDescription: Microsoft Firewall Client Windows Sockets 2 Service Provider
LegalCopyright: Copyright (c) Microsoft Corporation. All rights reserved.
6d320000 6d341000 rdpendp (deferred)
Image path: C:\Windows\system32\rdpendp.dll
Image name: rdpendp.dll
Timestamp: Sat Jan 19 01:31:51 2008 (4791A767)
CheckSum: 0001A975
ImageSize: 00021000
File version: 6.0.6001.18000
Product version: 6.0.6001.18000
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft® Windows® Operating System
InternalName: RdpAudioEndpoint
OriginalFilename: rdpendp.dll
ProductVersion: 6.0.6001.18000
FileVersion: 6.0.6001.18000 (longhorn_rtm.080118-1840)
FileDescription: RDP Audio Endpoint
LegalCopyright: © Microsoft Corporation. All rights reserved.
6ee60000 6eec6000 audioeng (deferred)
Image path: C:\Windows\System32\audioeng.dll
Image name: audioeng.dll
Timestamp: Sat Jan 19 01:26:49 2008 (4791A639)
CheckSum: 0006AF2A
ImageSize: 00066000
File version: 6.0.6001.18000
Product version: 6.0.6001.18000
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft® Windows® Operating System
InternalName: AudioEngine
OriginalFilename: AudioEng.Dll
ProductVersion: 6.0.6001.18000
FileVersion: 6.0.6001.18000 (longhorn_rtm.080118-1840)
FileDescription: Audio Engine
LegalCopyright: © Microsoft Corporation. All rights reserved.

As you can see, there is lots of information here, and this list can take quite a bit of time to go through.  If there is a specific module that we are interested in, we can filter down the search by adding the m option to our command:

kd> lmvm ntdll
start end module name
772a0000 773c7000 ntdll (pdb symbols) c:\public_symbol_files\ntdll.pdb\B958B2F91A5A46B889DAFAB4D140CF252\ntdll.pdb
Loaded symbol image file: ntdll.dll
Mapped memory image file: C:\public_symbol_files\ntdll.dll\4791A7A6127000\ntdll.dll
Image path: C:\Windows\system32\ntdll.dll
Image name: ntdll.dll
Timestamp: Sat Jan 19 01:32:54 2008 (4791A7A6)
CheckSum: 00135D86
ImageSize: 00127000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

And of course, if we don’t necessarily need that much information, we can always omit the v parameter:

kd> lmm ntdll
start end module name
772a0000 773c7000 ntdll (pdb symbols) c:\public_symbol_files\ntdll.pdb\B958B2F91A5A46B889DAFAB4D140CF252\ntdll.pdb

There are three other command parameters I’d like to point out – lmc, lmsm, and lmf.  The first of these, lmc displays the checksum data for the modules.  This is useful if you are concerned that you have a different (or altered) version of a file than you thought you did:

kd> lmc
start end module name
00b10000 00b18000 svchost (deferred) 00012FFA
55600000 55635000 FwcWsp (deferred) 0003A4A3
6d320000 6d341000 rdpendp (deferred) 0001A975
6ee60000 6eec6000 audioeng (deferred) 0006AF2A
6f7a0000 6f829000 wuapi (deferred) 0008CF6F
701a0000 701c1000 audioses (deferred) 00021FE6
70260000 70272000 wscsvc (deferred) 0001B62F

The next command, lmsm, changes the sort order of the modules to sort them by name rather than their memory address.  In scenarios where you may have multiple copies of a file on the system, this will help you to identify which ones are loaded:

kd> lmsm
start end module name
80692000 806d8000 acpi (deferred)
75f60000 76026000 ADVAPI32 (deferred)
89584000 895cc000 afd (deferred)
92518000 92521000 asyncmac (deferred)
81ea8000 81eb0000 atapi (deferred)
81eb0000 81ece000 ataport (deferred)
6ee60000 6eec6000 audioeng (deferred)
701a0000 701c1000 audioses (deferred)
74500000 74551000 audiosrv (deferred)

And finally, lmf shows you the full image path for the module in question:

kd> lmf
start end module name
00b10000 00b18000 svchost C:\Windows\System32\svchost.exe
55600000 55635000 FwcWsp c:\Program Files\Microsoft Firewall Client 2004\FwcWsp.dll
6d320000 6d341000 rdpendp C:\Windows\system32\rdpendp.dll
6ee60000 6eec6000 audioeng C:\Windows\System32\audioeng.dll
6f7a0000 6f829000 wuapi C:\Windows\system32\wuapi.dll
701a0000 701c1000 audioses C:\Windows\System32\audioses.dll
70260000 70272000 wscsvc c:\windows\system32\wscsvc.dll
708a0000 708b4000 MSACM32 C:\Windows\system32\MSACM32.dll
712e0000 712f0000 wbemsvc C:\Windows\system32\wbem\wbemsvc.dll
71300000 71399000 fastprox C:\Windows\system32\wbem\fastprox.dll
71b20000 71bfc000 dbghelp c:\windows\system32\dbghelp.dll

Armed with combinations of these different parameters, you can identify whether or not modules that are loaded are the correct ones, whether they are loading from the proper path, and how many different versions are loaded.

With that, we’ve come to the end of another post.  Enjoy the rest of your Friday!  Until next time …

Additional Resources:

- CC Hameed

Share this post :