how to know the method loaded from which DLL

Question

A common method foo() is defined in two DLLs A.dll and B.dll. Now when a process proc.exe loads both DLLs and call foo() method simultaneously from two threads. is there any way to know foo() was loaded from which DLL A.dll or B.dll at run time. I need this information for logging purpose. I couldn't find anything relevant on internet.

GetModuleFileName() would return the process name proc.exe not the Dlls name.

you seem to be missing something though I'm not sure what. If you _dynamically_ load two different dlls and use GetProcAddress, you already know which one is being called. In the other case, it's the linker that decides which foo() gets linked to hence called at runtime. The case you describe makes no sense: the exe is either linked agains the import lib from A or from B, or from both but in that last case still only one foo() could be used else you'd get duplicate symbol errors during linking.. — stijn, Aug 22 '13 at 06:56
The scenario I mentioned above is simple version of complex problem I have so that it could be understood easily. Dlls are loaded through implicit linking so I am not doing and LoadLibary() & GetProcAddress(). If you inject your DLLs in some process and there are many threads running. Doesn't question make sense when you want to solve a synchronization issue ? — irsis, Aug 22 '13 at 07:10
No cause what you say is pretty much impossible: "_method foo() is defined in two DLLs A.dll and B.dll_". This is the standard recipe for multiply defined symbols, so please explain how you do this. If you use implicit linking it will either be A or B but not both, beacuse the linker wouldn't allow that. It seems you oversimplified the complex problem :] — stijn, Aug 22 '13 at 07:26
oh yeah... love the unresolved external symbols, multiply defined symbols and all the other linker madness. Sometimes resolving these after import of a project takes longer than altering the piece of code you came for ;) — AnyOneElse, Aug 22 '13 at 07:59
@stijn I don't know how to do that but I would recommend to look into two DLLs EMSMDB32.dll (Transport Provider) and MSPST32.dll (Store Provider) in standard Microsoft office installation through dependency walker. Both of these DLLs have a common method MSProviderInit(). FYI, Outlook loads them together. — irsis, Aug 22 '13 at 08:59
@stijn: I think if you really had to you could instruct the linker to alias the function names (perhaps by specifying the ordinal?) though I don't recall the details offhand. — Harry Johnston, Aug 26 '13 at 04:42

score 3 · Accepted Answer · answered Aug 22 '13 at 07:32

3

Assuming that you have the address of the function you should be able to use the following to determine the base address of the module.

HMODULE ModuleFromAddress(void *address)
{
  MEMORY_BASIC_INFORMATION mbi;
  if (VirtualQuery(address, &mbi, sizeof(mbi)) != 0)
    return (HMODULE)mbi.AllocationBase;
  return NULL;
}

Then feed the result of that into GetModuleFileName

answered Aug 22 '13 at 07:32

torak

5,684
21
25

Your answer makes sense. Though I don't even have address of the function but there have been posts (http://stackoverflow.com/questions/3048670/pointer-to-current-function?rq=1) on SO to determine that. I'll try it. – irsis Aug 22 '13 at 07:48

score 1 · Answer 2 · answered Aug 22 '13 at 06:58

1

Doesn't the callstack (atleast in MS Visual Studio) tell exactly that? (Sorry can't write comments due to reputation limit)

answered Aug 22 '13 at 06:58

AnyOneElse

406
2
6
17

it does, but accessing the callstack to provide logging is overkill; but again as in my comment: I fail to see how the OP can _not_ know which foo it is – stijn Aug 22 '13 at 06:59

score 1 · Answer 3 · edited May 23 '17 at 12:05

1

You could find out the address where foo is located and the address range where each dll is loaded. Foo must be in one of the 2 address ranges. For finding out where a dll is loaded, check Finding the memory address of a loaded DLL in a process in C++. The MODULEINFO structure mentioned in the link provides the start address & the size.

edited May 23 '17 at 12:05

Community

1
1

answered Aug 22 '13 at 07:06

Tobias Langner

10,634
6
46
76

Thanks Tobias. Your answer makes sense but I thought there must be some easy for such a trivial issue. – irsis Aug 22 '13 at 07:13
2

yes, as stijin mentioned before. You linked the dlls statically, you know what you are calling. You told the linker to resolve this during link time. Everything is known. Probably your problem is something different. – Tobias Langner Aug 22 '13 at 07:17

how to know the method loaded from which DLL

3 Answers3