Getting a list of 3rd party modules with Windbg?

Question

I'm using windbg to examine some crash dumps sent in by an app. There seems to be some correlation between a crash I'm seeing and having a certain 3rd party DLL loaded into the process (a flaky Winsock LSP, I suspect). To make this sort of analysis easier in the future, is there a windbg script that would just show me a list of modules that are non-Microsoft? This would make patterns between crashes more obvious to me. I'm using "lm D sm", but going through the list manually right now is a pain.

Thanks!

Answer 1

You can use cdb to script the debugger, and it just prints to stdout - open the crash dump, have it print the loaded module list then exit, then you can use your favorite text manipulation tool (hint: its name is Perl ;) ) to search the list.

EDIT: Just to add some extra info, cdb is the command-line version of WinDbg; they both use the same engine, it's just a different frontend.

Answer 2

I'm not sure I see why you want to do this, but you can output from WinDbg to a log and correlate with a list of DLLs. That's pretty easy to do in any scripting language such as Perl, Python etc.

Answer 3

Try using "lm e" with your symbol path set to Microsoft's symbol server (and with only MS symbols loaded). That will cause WinDbg to show a list of all modules with any sort of symbol "problem" including modules that have not been loaded.

The keys to making this work are:

1. The sympath is only set to use the MS symbol store (use ".symfix" to achieve this)
2. Symbols have been loaded using the above sympath

From there you can add on the other options for "lm" to get info like full path, etc.

Answer 4

Hey,
The way that I do this now is I run sos.dll from the CLR10 directory from the Debugging Tools for Windows installation.

.load clr10\sos
!sam c:\temp\modules

I open the directory c:\temp\modules in Windows Explorer. I right click in the Header column and I add the column for Company. Then I sort on company and move DLLs with Company of "Microsoft Corporation" into a separate subdirectory called "Microsoft"

Whatever DLLs are left in the Directory are usually 3rd Party or custom developed code.

Thanks, Aaron

Answer 5

I wrote a small command-line app to solve exactly this problem a while back.

http://www.sleep1000.com/software/dumpmod