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. [...]

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.

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.

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.

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.