Where do I find the list of unloaded modules in a Windows process?

Question

I have some native (as in /SUBSYSTEM:NATIVE) Windows programs that I'd like to generate minidumps for in case they crash. Normally, I'd use dbghelp.dll, but since native processes can only use functions exported from ntdll.dll, I can't.

So I've implemented the dumper myself. It's almost done, but unfortunately, I've been unable to locate the list of unloaded modules in the crashed process (the list is certainly stored somewhere, since WinDbg is able to display it).

Where do I find the list of unloaded modules in a Windows process?

Edit: The list is certainly stored somewhere in the process memory, WinDbg can display the list even if I attach it after the modules were unloaded. There's also a note in the documentation of WinDbg:

Microsoft Windows Server 2003 and later versions of Windows maintain an unloaded module list for user-mode processes. [...]

Gonna

Only vaguely related, but I'm really interested in your reimplementation of MinidumpWriteDump. Any plans on open-sourcing that? – Flam

@TedMielczarek, I'm afraid not, the company will never allow that. But if you have specific questions, fire away, I'll be happy to help. – Gonna

Bummer. I understand all the theory of how to do it, it'd just be nice to not have to write it myself. (I hack on Breakpad, and we currently just use MinidumpWriteDump on Windows, but it sucks sometimes.) – Flam

FWIW, we have a non-MiniDumpWriteDump() version in Crashpad crashpad.chromium.org now. – Speechmaking

Answer 1

See RtlGetUnloadEventTrace and RtlGetUnloadEventTraceEx.

I am not entirely sure about how it works, but I believe the actual list is stored by ntdll.dll in the loader code. It keeps track of the 16 (or 64, according to MSDN) last unloaded DLLs in the specific process. The information is not linked from PEB or PEB_LDR_DATA.

Tupelo

Answer 2

If you need it just for native process, it's not necessary to find the list, as native process cannot load any dlls, so there are not any unloaded. But from technical point of view I'm curious where are the unloaded data located in process.

Zeiler

Answer 3

WinDbg may just create the list itself. A debugger in windows will get module load and unload events as the program executes. So a debugger would just need to watch for these events and update lists as it goes.

See: http://msdn.microsoft.com/en-us/library/ms679308%28VS.85%29.aspx

specifically the parts about UNLOAD_DLL_DEBUG_INFO and LOAD_DLL_DEBUG_INFO.

I recommend you do it that way, I am unaware of any internal list which tracks unloaded modules, after all, the OS itself has little need for that type of data.

Daffi

Evan, thank you for answering. The list really is there somewhere, WinDbg can display the list even if I attach it after the modules were unloaded. The Internet says that the list is maintained in Windows 2003 and newer for debugging purposes (but is uncharacteristically silent as to where the list is located). – Gonna

@Then I recommend making a test program which loads and then unloads a fairly unique module name. Then doing a string search for that module. You can then attempt to identify what type of data structure (I'd guess linked list) is used to store this information and where it is located. – Daffi

I've already tried that. I managed to find a linked list (as in LIST_ENTRY) of LDR_MODULE structures that contained the names of unloaded modules, but unfortunately it also contained a lot of invalid entries (with pointers to non-committed memory), which eventually prevented me from finding the list's head. – Gonna

Answer 4

I would hazard a guess that it's the difference between the modules listed in the exe's import table, and the currently loaded modules.

Nevillenevin

Rob, that would only work if no modules were loaded dynamically (and then it would be rather useless as it's quite unusual to unload statically imported libraries). – Gonna