-3

I have a pointer to some object that was loaded from DLL using GetProcAddress:

CSomeClass* pSomeClass;
pSomeClass = (CSomeClass*)GetProcAddress(someDLLinstance, "SomeUnknownName");

I cannot modify the code above, but I need to obtain "SomeUnknownName" string after it has gone out of scope. All I can access is pSomeClass pointer. Is there any convenient way I can get the imported object's name from its pointer? Right now I just dump all the export names from DLL, then use GetProcAddress() on each of them to get all pointers to all exported objects/functions, and then compare pSomeClass to those pointers, but it appears to be very slow for a solution.

πάντα ῥεῖ
  • 1
  • 13
  • 116
  • 190
Vyacheslav Nikitenko
  • 3
  • 1
  • What do you actually mean looking up by `"SomeUnknownName"`?? – πάντα ῥεῖ May 08 '15 at 18:13
  • 4
    `GetProcAddress` does not return an object. It returns a procedure address. `pSomeClass` has no information about what `SomeUnknownName` was; it's simply a pointer. Once the string `SomeUnknownName` goes out of scope, there's no way to get it back except exactly as you're doing it - calling `GetProcAddress` on each exported name until you find an address that matches. – Ken White May 08 '15 at 18:23
  • GetProcAddress does not return an object itself, but it might return an object pointer, as well as a function pointer. And I just assume it looks up some table to find a pointer for given name. What I want is, find a name for given pointer, not vice versa. – Vyacheslav Nikitenko May 08 '15 at 18:36
  • Objects don't have names. Your question remains obscure, – user207421 May 08 '15 at 18:59
  • Exports have names. Consider these lines in DLL: `extern "C" __declspec(dllexport) CSomeClass firstInstance; extern "C" __declspec(dllexport) CSomeClass secondInstance;` then, I can get a pointer to either of the objects: `pSomeClass = (CSomeClass*)GetProcAddress(someDLLinstance, "firstInstance");` – Vyacheslav Nikitenko May 08 '15 at 19:06
  • *Variables* and *functions* have names. *Objects* don't. – user207421 May 08 '15 at 19:30
  • You knew the name when you called `GetProcAddress`. So remember it. Cure the disease. – David Heffernan May 08 '15 at 20:40
  • @KenWhite: DLLs can export data also. So it might indeed be a pointer to an object, not a function. – Ben Voigt May 08 '15 at 21:54
  • @Ben: [GetProcAddress](https://msdn.microsoft.com/en-us/library/windows/desktop/ms683212%28v=vs.85%29.aspx) returns a pointer. What that pointer represents may indeed vary (and you can typecast it into whatever you want), but the function itself returns a pointer. Calling the function that you obtain via `GetProcAddress` may indeed return an object, and you can do whatever you want with the return value of the function, but `GetProcAddress` returns a pointer. – Ken White May 08 '15 at 21:58
  • @Ken What Ben means is that the pointer returned by `GetProcAddress` may not point to code. It may point to data. – David Heffernan May 09 '15 at 06:27

1 Answers1

1

If you really need to do this, you can use the DbgHelp functions to do the job. Specifically, you'd be looking at SymFromAddr in this case.

You start by calling SymInitialize, then you can call SymFromAddr. You give it the address of a SYMBOL_INFO structure. You fill in the address and maximum symbol length, and it'll return the name.

When you're done, you're at least supposed to call SymCleanup to let the symbol manager library shut down, release any memory it's holding, etc. Presumably that would/will all happen when your process ends, but it's cleaner to call it when you're done.

If you have debug information, that will succeed for pretty much any symbol. Even without debug information, however, it will (at least normally) succeed for exported symbols.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111