views:

299

answers:

4

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

A: 

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.

Evan Teran
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).
avakar
@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.
Evan Teran
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.
avakar
A: 

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.

Rob K
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).
avakar
+1  A: 

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.

Yakeen
+4  A: 

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.

Filip Navara
Filip, this is exactly what I was looking for. Many thanks. :-)
avakar