While working in WinDBG, lm is the standard command for viewing the loaded module list of the target. Amongst other things, this command takes a v flag to increase the verbosity as well as an m flag to match a particular module. Thus, if you want to see verbose information for a module named foo you can execute the following command:
That’s all fine and good, but you might notice that some modules provide more information than others. For example, check out the detailed information provided for the NTFS module:
1: kd> lmv mntfs start end module name fffff880`01250000 fffff880`013f3000 Ntfs (deferred) Image path: \SystemRoot\System32\Drivers\Ntfs.sys Image name: Ntfs.sys Timestamp: Mon Jul 13 19:20:47 2009 (4A5BC14F) CheckSum: 00195F88 ImageSize: 001A3000 File version: 6.1.7600.16385 Product version: 6.1.7600.16385 File flags: 0 (Mask 3F) File OS: 40004 NT Win32 File type: 3.7 Driver File date: 00000000.00000000 Translations: 0409.04b0 CompanyName: Microsoft Corporation ProductName: Microsoft® Windows® Operating System InternalName: ntfs.sys OriginalFilename: ntfs.sys ProductVersion: 6.1.7600.16385 FileVersion: 6.1.7600.16385 (win7_rtm.090713-1255) FileDescription: NT File System Driver LegalCopyright: © Microsoft Corporation. All rights reserved.
Versus the limited information we get for the FltMgr module:
1: kd> lmv mfltmgr start end module name fffff880`010fa000 fffff880`01146000 fltmgr (deferred) Image path: \SystemRoot\system32\drivers\fltmgr.sys Image name: fltmgr.sys Timestamp: Mon Jul 13 19:19:59 2009 (4A5BC11F) CheckSum: 00056413 ImageSize: 0004C000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
What’s up with that?
The answer is the availability of resource information. The PE file format allows for a .rsrc section, which contains developer provided information about the binary (company, version, description, etc.). The information placed here comes from a .rc file supplied when the image is compiled and is usually accessed via the Details tab of the file properties:
If an image contains a resident and valid .rsrc section, lmv will provide the details from it as part of its output. If we dump the PE header for the NTFS module, we can see that it does indeed have a .rsrc section:
1: kd> !dh ntfs
File Type: EXECUTABLE IMAGE FILE HEADER VALUES 8664 machine (X64) 8 number of sections 4A5BC14F time date stamp Mon Jul 13 19:20:47 2009
SECTION HEADER #7 .rsrc name 1CFF0 virtual size 185000 virtual address 1D000 size of raw data 176600 file pointer to raw data 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 40000040 flags Initialized Data (no align specified) Read Only
Which explains why we saw all of that detailed info for NTFS. But why didn’t we see it for FltMgr? In fact, if we check out the file properties for FltMgr.sys we see that it does indeed have a valid resource section:
But lmv was unable to parse it for some reason. Let’s check out the PE header to find out why:
1: kd> !dh fltmgr
File Type: DLL FILE HEADER VALUES 8664 machine (X64) B number of sections 4A5BC11F time date stamp Mon Jul 13 19:19:59 2009
SECTION HEADER #A .rsrc name 1E50 virtual size 49000 virtual address 2000 size of raw data 42E00 file pointer to raw data 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 42000040 flags Initialized Data Discardable (no align specified) Read Only
Aha! The .rsrc section is marked as discardable, meaning the the image loader is free to remove this section from memory when the module is loaded. Thus, while this module has a valid .rsrc section on disk, it is not guaranteed to have one in memory.
Discardable is the default used by the compiler/linker for resource sections because the information is typically only used in file property dialogs, where it can easily be retrieved from the image on disk. However, certain Microsoft supplied modules (such as NTFS) go out of their way to mark their resource sections as non-discardable to make it possibly to query version information from the debugger at the cost of some extra RAM.