How do you detect DLLs that are being statically loaded at run-time?

Question

Objective

To make troubleshooting easier for the technicians who are deploying our software into a production environment, I would like our Windows service to log any DLLs that it cannot load/locate at run-time when the service starts. Nothing fancy, just:

name of DLL
success / failure

This is easy enough for DLLs that are explicitly loaded (e.g. using LoadLibrary()). Unfortunately I have no idea how to do this for DLLs that are loaded automatically when the application starts (i.e. implicitly loaded DLLs).

In otherwords, how do you detect DLLs that are being statically loaded at run-time? Is this even possible?

Any guidance you can provide would be greatly appreciated!

Additional Context

Test Machine: Windows 8.1 Enterprise (64bit)

References

MSDN: Linking an Executable to a DLL
- Implicit & Explicit Linking
MSDN: Using Run-Time Dynamic Linking
MSDN: LoadLibrary function
MSDN: Dumpbin /Dependents
- Example: DumpBin.exe /Dependents c:\Path\To\Application.exe

Updates

Update1

To make things as easy as possible for the deployment team, I had hoped to write a clear message to the application's event log MyWindowsService.log (after all, that is where they look for all of the other messages)... but to Mark Segal's point, a Windows Event Log entry is created:

Faulting application name: MyWindowsService.exe, version: 2.7.4.1, time stamp: 0x55673caa
Faulting module name: ImplicitlyLoadedLibrary.dll, version: 6.3.9600.17736, time stamp: 0x550f42c2
Exception code: 0xc0000135
Fault offset: 0x0009d4f2
Faulting process id: 0x168c
Faulting application start time: 0x01d0997fc49e50fe
Faulting application path: C:\Program Files (x86)\CompanyName\ApplicationName\MyWindowsService.exe
Faulting module path: ImplicitlyLoadedLibrary.dll
Report Id: 024adcd5-0573-11e5-830a-6c198fb1a83d
Faulting package full name: 
Faulting package-relative application ID:

For anyone who is interested Exception code: 0xc0000135 means: A dependent dll was not found

Update 2

The original intent was to see if:

Can you check for dependencies before the loader begins it's job, or
Can you hook into the loading process to see what DLLs are being loaded

While it is true I could implement an entirely new loading mechanism (i.e. think plug-in architecture), that would be way beyond the scope of what I had wanted to accomplish.

From the answers thus far, it doesn't appear like 1. or 2. are possible.

Google "windows show loader snaps". Suitable to technicians, hmm, they are probably better off with SysInternals' Process Monitor. — Hans Passant, May 28 '15 at 19:25
PE? I am uncertain as to what this is. Could you please clarify? — Pressacco, May 28 '15 at 19:26
@Mike Holt: The posting you are referring to suggests using an external tool. Ideally, I would like to perform the check when the service starts. Therefore, this is not a *Possible Duplicate*. http://stackoverflow.com/q/475148/949681 — Pressacco, May 28 '15 at 19:29
@Pressacco Every Windows executable has the form of a Portable Executable on disk - check http://en.wikipedia.org/wiki/Portable_Executable — Mark Segal, May 28 '15 at 19:35
@Mark Segal: Thanks for the feedback, much appreciated. Correct me if I am wrong... but wouldn't I have to read the PE before my application even started? I had hoped that there would be a way to hook into the loader while it was locating the DLLs **or** perform my own check before the loader starts to locate the DLLs. Thoughts? — Pressacco, May 28 '15 at 19:38
Generally, your application shouldn't start if some of the imports (i.e DLLs) are missing. Therefore it is pretty silly to try to hook on the loader (and each failure is logged by Windows and you can see it in the Events thingy). If you application started and your code is running, (if I'm not mistaken...) - you are guaranteed that all DLLs were successfully loaded. — Mark Segal, May 28 '15 at 19:41
procmon has this event and you can probably filter on it. Maybe you can automate it. — Daniel, May 28 '15 at 20:22

Cheers and hth. - Alf · Answer 1 · 2015-05-28T20:21:32.067

One possibility is to make your current service logic a separate DLL s, loaded from a driver program d. Then in d, before loading s, load dynamically the DLLs that s depend on. In the old days you could find that set via the depends tool, Dependency Walker, from the Resource Kit (I think it was); nowadays it's apparently distributed via its own web page.

Note that when a DLL has been loaded, regardless of loading mechanism, it's loaded. Thus when d subsequently loads s, all its DLL dependencies are fulfilled. Including the static ones.