Getting a list of DLLs currently loaded in a process

Last edited on Sep 23, 2020

Introduction¶

It can be useful to know which .dlls an application has loaded when analysing DLL-related problems.

For this particular purpose you can use Microsoft’s Process Explorer tool.

Getting list of DLLs with Process Explorer¶

Viewing the list of currently loaded DLLs¶

вљ пёЏ After starting Process Explorer select the process or application that you want to inspect. We have used notepad++.exe in this example:

Then click View→Lower Pane View→DLLs (or press Ctrl+D):

вљ пёЏ Now the lower pane view is visible; it lists the DLLs loaded by the selected process only!

Saving the list of DLLs of the selected process¶

The list of DLLs of the selected (!) process can be saved (which is useful if you want someone else to look at it) by clicking Fileв†’Save as… (or press Ctrl+A):

The resulting file starts with the process list and after that it lists the selected process’s DLLs:

Getting list of DLLs with ListDLLs¶

The command line tool ListDLLs from Microsoft can also list the DLLs loaded by a process:

Saving the list of DLLs¶

For this standard I/O redirection can be used:

The output of the command is then contained in the file temp.txt .

Usage Data Processing by Google

We would like to use Google Analytics to get a better understanding of how you use the website.

By agreeing to this, your usage data will be stored in the USA and processed by Google LLC. Both Google as well as federal US agencies can access this data and combine it with any other data about you, such as your search history, personal accounts or any other data known to Google.

See our privacy policy to toggle this feature and to learn more, or contact us.

ListDLLs v3.2

By Mark Russinovich

Published: July 4, 2016

Download ListDLLs (307 KB)

Introduction

ListDLLs is a utility that reports the DLLs loaded into processes. You can use it to list all DLLs loaded into all processes, into a specific process, or to list the processes that have a particular DLL loaded. ListDLLs can also display full version information for DLLs, including their digital signature, and can be used to scan processes for unsigned DLLs.

Usage

listdlls [-r] [-v | -u] [processname|pid]
listdlls [-r] [-v] [-d dllname]

Parameter	Description
processname	Dump DLLs loaded by process (partial name accepted).
pid	Dump DLLs associated with the specified process id.
dllname	Show only processes that have loaded the specified DLL.
-r	Flag DLLs that relocated because they are not loaded at their base address.
-u	Only list unsigned DLLs.
-v	Show DLL version information.

Examples

List the DLLs loaded into Outlook.exe, including their version information:

listdlls -v outlook

List any unsigned DLLs loaded into any process:

listdlls -u

Show processes that have loaded MSO.DLL:

listdlls -d mso.dll

Download ListDLLs (307 KB)

Runs on:

• Client: Windows Vista and higher
• Server: Windows Server 2008 and higher
• Nano Server: 2016 and higher

—>

Questions Regarding DLL Loading in a Process Address Space

Well, I read several of Matt Pietrek’s articles on Portable Executable (PE) files, like:

In addition, I have read a few other sources on the subject. It is either me overlooking some parts, or the questions aren’t answered there.

So, here are the questions:

It is known that, when loading an EXE, the Windows Loader reads the list of imported DLL’s from the Importa Address Table (IAT), and loads them into the process address space.

The process address space is a virtual space. The DLL may have already loaded into some physical space. This happens for DLLs like KERNEL32.dll or USER32.dll . What is the relation between the physical and virtual address? Does the loader just allocate pages and copy the DLL, or does it make references?

If a DLL is not loaded, does the Loader load the whole DLL, or just the functions needed? For instance, if you used function foo() from bar.dll , does the loader load the whole bar.dll into the process address space? Or, does it just load the foo ‘s code into the process address space?

Assume your EXE file uses function MessageBox() from USER32.DLL , which resides in %WINDIR%\system32\user32.dll . Can you develop a customized USER32.DLL , put it in the same directory as your EXE file, and expect that your customized MessageBox is called by your app instead of the system’d default MessageBox ?

2 Answers 2

Re 1: physical addresses play no role, everything involved here is virtual memory. The physical address is only established when a virtual memory page gets mapped into RAM, triggered by a page fault. Many basic DLLs appear at the same virtual memory address in several processes, like kernel32.dll. The processes simply share the same pages of code (not data).

Re 2: no actual ‘loading’ takes place, the feature used is the same one that supports memory mapped files. The backing of these pages is the DLL file itself, not the paging file. Nothing gets loaded until a page fault forces Windows to read the page from the file into RAM. But yes, the entire code section of the DLL gets mapped.

Re 3: yes, that would work. But it is next to impossible to make it work in practice since you will have to write replacement functions for all the user32 exports that your program uses. Including the ones that other Win32 functions use, you cannot know. API hooking is the typical technique used, Detours from Microsoft Labs is a good one.

Windows Internals edition 5 is an excellent book to learn more about the plumbing.

How do I find out which dlls an executable will load?

If I have a Windows executable, how can I find out which dlls it will load?

I’m just talking about which ones that will be loaded statically, not ones it might load dynamically with something like LoadLibrary.

10 Answers 10

There are utilities that will do this for you.

In the past I’ve used the MS tool (depends.exe) that came with (I think) VB.:
VS2010 VS2012 VS2013 VS2015 Current

and probably others as well.

dumpbin is a tool that comes with VC++.

To see what DLLs a program will import:

• Open Visual Studio
• Menu Item Tools | Visual Studio Command prompt
• cd to folder containing executable
• dumpbin /dependents whatever.exe

To see what functions (and DLLs) it will import, use

Open the command prompt and then type below command

tasklist /m /fi «imagename eq netbeans.exe»

Type instead netbeans.exe whatever name your exe file name.

Just go to the command prompt and type tasklist /m , you will see the list of dll files used by specific program.

Dependency Walker can help you determine which .dll will be loaded.

Solution for Microsoft .Net:

There is a handy tool called NDepend that will give you all DLL dependencies.

Benefits: allows to explore the process that is already running (I have not found a was to attach the dependency walker to the existing process)

Dependencies — An open-source modern Dependency Walker shows which DLLs a Windows executable will load and it works well in modern Windows 10.

It is a little less powerful than Dependency Walker, but the latter may or may not work in Windows 10 as it was last updated in 2006. (Newer versions of Dependency Walker were bundled with some versions of Windows Development Kit for Windows 10, but not any more.)

Not the answer you’re looking for? Browse other questions tagged dll executable or ask your own question.

Linked

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

site design / logo © 2021 Stack Exchange Inc; user contributions licensed under cc by-sa. rev 2021.4.16.39093

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Why does process loads modules(dlls) in different phases?

The phenomenon goes like this.

I’m trying to implement dll injection. My application create process in ‘suspended’ state, (Using CreateProcess with CREATE_SUSPENDED), wait for an important dll to be loaded(kernel32.dll of course), and then executes injection. The suspended process is resumed using ResumeThread after the injection.

I’m using suspended process creation in the hope that dll is injected prior to any other execution except dll load. But while executing this, I found something interesting.

I’ve simply tested this injection using notepad.exe and it worked just fine. But when I’ve duplicated the executable as notepad2.exe, my injection waits for infinite time. Kernel32.dll never loads up until the main thread of the process is resumed.

It seems there’s some sort of ‘authenticated’ executable that modules are loaded beforehand (or maybe some security solutions installed in my computer that already uses dll injection might cause this different execution).

Does Anyone knows if there’s any sort of thing that modules are loaded in different manner? (Frankly, I still don’t understand the life cycle of windows process. )

1 Answer 1

I think I’ve found an answer. The answer is that though the process is in SUSPENDED state, and therefore main thread is stopped, when certain thread in that process tries to access to a module, then the required modules are loaded (Which means, that windows application seems to ‘Lazy Load’ require modules)

In the comment, I said that the process protected by certain security solution installed on my PC uses Detour to inject DLL, and therefore modules in certain Process loaded while the process is in SUSPENDED state. But that was not a specific case of Detour, but general issues on every processes.

I was stupid that the injection technique I used was, to list all the modules loaded in the target process, find kernel32.dll, calculate the offset of LoadLibraryW, and call that function using remote thread. In this technique, the injector enumerates all the modules BEFORE LoadLibrary functions are ever called, and therefore LazyLoading never happens, and therefore I can never see kernel32.dll loaded on the process.

When I used simple technique that use GetProcAddress from current process, get the address of LoadLibrary function, and remotely calling the process, kernel32.dll was successfully loaded and the injection succeeded.

In case of several applications protected through the ‘security solutions using Detour’, even though I suspended the process, the injection tries do happen, and that’s why kernel32.dll was loaded on notepad.exe (which is in the list of the security solution), but not loaded on notepad2.exe (as image name differed, it is not in the list).

I was just stupid, trying to use more complicated methods for dll injection, and that’s what caused all these problems.