Using volatility to inspect a services.exe process in a memory dump, I built a list of dll's that are loaded in the process space. (The modules are from the InLoadOrder module list)

This is just an excerpt (full list: http://pastie.org/8560797):

0x5b860000 netapi32.dll
FileObject @8a3cb028, Name: \WINDOWS\system32\netapi32.dll

0x77f60000 shlwapi.dll
FileObject @8a3e0df0, Name: \WINDOWS\system32\shlwapi.dll

As you can see there is a shlwapi.dll loaded in the process.Thanks to DependencyWalker (looking at the imports of services.exe) I found out how shlwapi.dll is loaded. ( -> means imports )

netapi.dll -> dnsapi.dll -> iphlpapi.dll -> mprapi.dll -> setupapi.dll -> shlapi.dll

But only netapi.dll is loaded. dnsapi.dll is not loaded, there is no entry for it in the InLoadOrder module list, neither is any of the other dlls from the from the above "dependency chain" loaded.

This is not only for shlapi.dll but for many other dll's that are loaded as well. For example: shell32.dll, psapi.dll... Neither does this only happen for services.exe process.

Any ideas why these dlls are loaded into the process?

Any help is most appreciated, regards!

1 Answer 1


The netapi.dll might have loaded the dnsapi.dll in order to do some network inspection, and then freed the DLL on completion. However, the shlwapi.dll might hold some handles to objects open for whatever reason, or have a non-zero reference count because of circular loading, and thus remain in memory even after the other DLLs have unloaded. A request to unload does not guarantee that it will be honored, nor does it prevent the requester from unloading first. user32.dll is another DLL that usually displays this behavior.

  • Ok, I understand this - thank you for making things clear to me. This leads me to another question. Looking at the dlls loaded by a csrss.exe process (which actually imports only ntdll.dll and csrsrv.dll) I found a bunch of other dlls in the process space, namely: basesrv.dll, winsrv.dll, user32.dll, sxs.dll, kernel32.dll, gdi32.dll, advapi32.dll, rpcrt4.dll. Where do these imports come from? They are neither dependecies of ntdll.dll nor of csrsrv.dll. Thank you!
    – user3365
    Commented Dec 19, 2013 at 14:16
  • since Windows XP, kernel32.dll is force-loaded into all processes, to prevent a crash during process startup (ntdll.dll has a dependency on kernel32.dll). kernel32.dll in turn loads gdi32.dll, advapi32.dll, rpcrt4.dll, etc. Each of those might load other DLLs, eventually covering your entire list. Commented Dec 19, 2013 at 22:27
  • I just checked the imports of kernel32.dll and according to DependencyWalker, kernel32.dll depends only on ntdll.dll.
    – user3365
    Commented Dec 20, 2013 at 13:00
  • While kernel32.dll might import only from ntdll.dll in your example (that's true up to Win7 - then it imports from other DLLs, too), for even simple APIs like WinExec, kernel32.dll will load advapi32.dll, which will load rpcrt4, etc. Commented Dec 20, 2013 at 22:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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