Download demo project - 110 Kb
Download project source files - 134 Kb

Have you ever experienced an error while loading a DLL when you start an application? Invalid DLL version? Entry point @XXXX not found?
If the answer is yes, then this application is for you!
On you LAN, there may be thousands of versions of a DLL! Which version are you using? Which DLL has effectively been loaded by your application? You must check the PATH, the current working directory of your process, etc...
This small application, called "DisplayLoadedModules", connects to a running process, gets the list of DLLs loaded by the process, and displays the following information for every DLL:
- Module File Path (e.g. "C:\WINNT4\System32\WS2_32.dll")
- Module Description (e.g. "Windows Socket 2.0 32-Bit DLL")
- Module File Version (e.g. "4.00")
- Associated Product Name (e.g. "Microsoft(R) Windows NT(TM) Operating System")
- Associated Product Version (e.g. "4.00")
- Module File Size (e.g. "59664 bytes")
- Module Creation Date (e.g. "October 14, 1996 03:38:00")
The application can also save the output to a text file. If your application runs on a machine "A" and not on a machine "B", you can compare (using 'diff' or 'windiff') the output of the program on both machines. If you're experiencing a DLL version problem, you'll figure out very easily...
On Windows NT, the executable uses two additional DLLs/Lib: PSAPI.DLL and PDH.DLL For more on these APIs, please refer to MSDN Platform SDK:
On Windows 98, the executable uses the ToolHelp32 library. For more on this APIs, please refer to MSDN Platform SDK:
Note that you must select the proper WIN32 Configuration to build the executable:
- On Windows 98: select configuration Win32 Windows 98 Debug or Win32 Windows 98 Release
- On Windows NT: select configuration Win32 Windows NT Debug or Win32 Windows NT Release
| You must Sign In to use this message board. |
|
| | Msgs 1 to 12 of 12 (Total in Forum: 12) (Refresh) | FirstPrevNext |
|
 |
|
 |
Please, I need make a back track of DLL calls. The scene is:
APP.EXE --(call)--> DLL1.DLL --(call)--> DLL2.DLL | | +<----------------<------------------<-+
The question is:
How I can perform a back trace to get the DLL1.DLL name and path from DLL2.DLL?
I can get APP.EXE, but not DLL1.DLL. Can you help me?
Thank's
willian@williansilva.net
Willian S. Rodrigues willian_cpp_br@hotmail.com
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
|
 |
|
|
 |
|
 |
I have the latest SDK library installed on my machine, but when I tried to compile the source, it came back with a message that it couldn't open file '.\pdh.Lib'. What is it talking about?
Another thing, because I am running Win2k, would there be a problem if I were to remove all those Win98 '.cpp' (with their corresponding '.h') files from use?
Thanks.
William
|
| Sign In·View Thread·PermaLink | 1.50/5 (2 votes) |
|
|
|
 |
|
 |
How to unload DLL loaded by another process, for example, shell extension DLL to allow Visual C++ relink its file?
|
| Sign In·View Thread·PermaLink | 1.67/5 (3 votes) |
|
|
|
 |
|
 |
This is a very useful tool, that also shows dlls that are loaded halfway your program run, while MS Depends shows only dlls loaded at startup.
However, when using the NT version with Windows 2000 the program seems to have a bug (although it could be a Microsoft bug). For example, when you run a program that uses the MSVCRT.DLL the program shows file version nr "6.10.8637.0", while the actual version is "6.1.8637.0" (both in the dll's properties and defined on the microsoft website).
The following query for the fileversionnr results in the correct version nr:
if ( ::VerQueryValue( (void **)m_lpVersionData, _T("\\"), &lpData, &nQuerySize ) ) { VS_FIXEDFILEINFO versionInfo = *(VS_FIXEDFILEINFO*)lpData; UINT uiMajorNr = HIWORD(versionInfo.dwFileVersionMS); UINT uiMinorNr = LOWORD(versionInfo.dwFileVersionMS); UINT uiBuildNr = HIWORD(versionInfo.dwFileVersionLS); etc
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
to find the DLL Version: it looks in the search path for a matching module (dll) and displays the version directly from the found file and and not from the dll the process actually loaded. Under certain circumstances there can be differences: If a dll is already in memory, a process will use this first! So if an other process has already loaded a dll succeeding load will get the same dll. So this tool can help analyze the dll hell where 'depends' can not
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
|
 |
|
 |
And 'Depends' doesn't show really loaded dll in memory. It can be used for dll and exe file without running them.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
http://www.dependencywalker.com (from here you can get the last version supplied in only with .NET though) Its true. On file open this tools displays only static dependecies( and delay loaded modules are verified). On the other side, this tool can start profiling and checks all dynamic dependecies( including COM dependecies). Also this is tool detects dll colision( rellocation) and lot of other stuff
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
General
News
Question
Answer
Joke
Rant
Admin