Scripting DLL Load

A few weeks ago I wrote about how to debug DLL loading problems. Today, I want to share some tips on how you can debug the early stages of DLL load by scripting the debugger.

Your friend sxe

First, it's useful to remember that in windbg and related debuggers, module loading (mostly DLLs, that is) surfaces through the exception mechansim. So the sx family of commands is used to control them.

The documentation page on Controlling Exceptions and Events documents ld as the "Load Module" event. Note that it has a handy optional syntax for filtering by module name, and in turn the specification can use wildcards.

This is quite handy and we're going to use that today, but unfortunately the debugger only has one such ld setting, so you can't use this for multiple different modules by name.

There is another interesting feature in the sxe command ("set exception enabled"), which is that you can specify a command to execute. Let's put all of that together.

Let's say for example that you don't care for the .natvis information in a module foo.dll and would like to unload that whenver the DLL is loaded. This command should do the trick:

sxe -c ".nvunload foo.dll;gc" ld:foo.dll 

This is how the command reads out:

Another common thing to do is to do this sort of early access to either modify memory locations (like we did a few weeks ago to touch up a module's global tracing flags) or to set up break-on-access breakpoints ("data breakpoints").

There are other ways of doing something like this where you need early processing, like setting a breakpoint on the DllMain of a module. bu and bm let you specify symbol names, and also support running commands - but that's a post for another day.

Happy debugging!

Tags:  cppdebugging

Home