Runtime profile support

[misuo]

The old DependencyWalker also support listing information about loaded executables (dll's) loaded at runtime by an executable (.exe) through its Profile feature.

This issue is about adding the same Profile feature so it is also possible to track which .dll's are loaded after the .exe has started. Different user actions may cause different .dll's loaded at runtime.

[learn-more]

That is a huge task, which involves writing a debugger to monitor module loads...

[lucasg]

Exactly. If one day I wanted to implement this feature, it would be a separate tool anyway. In the meantime ProcMon, wtrace and a good breakpoint with Windbg can do the job.

[learn-more]

Loader snaps (gflags /i process.exe +sls) + a debugger or DbgView to view the output is even simpler, and it also shows why a dll load fails (if it fails), as well as the reason why a dll is found.

[learn-more]

How dependencies handles this:

• It starts the target process under a debugger (dependencies is the debugger)
• It injects a dll in the target process
• It redirects all LoadLibrary[Ex][A|W] and GetProcAddress imports from all dlls in the target process to this dll (this is done from the dependencies process)
• The dll logs the result of these functions using OutputDebugString, which is captured in dependencies.

There are multiple ways to implement this, but these seem to be the most obvious:

• Start a process under a debugger
• Inject a dll (Either from the debugger, or as verifier plugin,see note 1)
• Redirect the functions (either from the debugger, or from the dll itself, see note 2)

Note 1: The downside of this method is that the dll should be in system32. However this means we can leverage the verifier subsystem to hook the relevant functions (which makes point 2 no longer a concern)

Note 2: Hooking the functions can be done from the debugger (host) process, which is slightly more complicated, or from the injected dll itself. The original depends is doing it from the host process, but I do not know if there is a good reason for this.

When adding support for this feature, would it be a problem if there is a requirement to drop support dll's in system32? (requiring elevation)