Because Microsoft C++ Runtime library is distributed as a side-by-side assembly, GetModuleHandle and LoadLibrary is no longer available to locate the library within the process. Both API calls would return NULL handle.
HMODULE hModule = GetModuleHandle(_T("msvcr90.dll")); HMODULE hModule = LoadLibrary(_T("msvcr90.dll"));
Still, how to locate the modules in order to, for example, be able to check DLL version? Process Status API (PSAPI) can help:
#include <psapi.h> #pragma comment(lib, "psapi.lib") ... DWORD nDataSize = 4 << 10; // 4K EnumProcessModules(GetCurrentProcess(), NULL, 0, &nDataSize); nDataSize += nDataSize / 2; CTempBuffer<HMODULE> phModules; ATLENSURE_THROW(phModules.AllocateBytes(nDataSize), E_OUTOFMEMORY); if(EnumProcessModules(GetCurrentProcess(), phModules, nDataSize, &nDataSize)) { const SIZE_T nCount = nDataSize / sizeof *phModules; for(SIZE_T nIndex = 0; nIndex < nCount; nIndex++) { CPath sPath = _VersionInfoHelper::GetModulePath(phModules[nIndex]); // uses GetModuleFileName if(_tcsicmp(FindFileName(sPath), _T("msvcr90.dll")) == 0) { // NOTE: Here we found it ATLTRACE2(atlTraceGeneral, 2, _T("msvcr90.dll version is %s\n"), _VersionInfoHelper::GetVersionString(_VersionInfoHelper::GetFileVersion(sPath))); break; } } }
Actually, I guess one can use the GetModuleHandleEx with GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS and with an address of a function defined in msvcr90.dll. The only limitation is XP+, which nowadays doesn’t seem so limiting, and anyway the SxS hadn’t been there beforehand…
I thought about GetModuleHandleEx, but it does not look as a convenient wokraround. First of all, it limits to XP/Server 2003, which still can be an issue (there are still people with Windows 2000 around so you don’t always have an option just put it into production code).
Second is that if you do something like
The address might still point to the image of your binary rather than directly to shared runtime DLL.
And the last this is that it does not seem to work :)
Hmm… That’s strange ;)
I used it many times just this way (although not for the msvcrXX.dll modules, but who cares?)
eax = 0 means the call failed, it might be interesting to see the GetLastError…
… just checked on my XP Pro Sp3, VS 2008 with (LPCTSTR)&malloc.
Got exactly the expected result.
It must be something in your environment, although I can’t guess what it may be… Maybe it doesn’t like the hardcoded address that you specified?
I was checking this with Windows 7. (LPCTSTR) &malloc expression itself pointed to address range of the executable, not the CRT DLL and failure to locate the DLL was more than expected. This is why I quick-hardcoded the address to at least get into the address range of interest.
OK, GetModuleHandleEx/GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS works great. It was my problem with code with incorrect argument (third argument is zero on the screenshot above).
&malloc still gives incorrect HMODULE for the reason mentioned above.
Code snippet:
Output: