In a few cases Memory Validator will fail to load symbols for a DLL that you believe you have provided symbols for.
This topic describes the possible causes. Please read the suggested course of action for each compiler.
|
Memory Validator uses the Microsoft Debugging DLL, DbgHelp.dll
However, there are cases where your application can be started independently, and you must ensure that your application uses the correct DbgHelp.dll.
Diagnostic error messages appear on the Diagnostics tab as in the example below detailing which version of DbgHelp.dll was expected and what was actually loaded.
If you see any DbgHelp warning dialogs, or get diagnostic errors, ensure the correct DbgHelp.dll is used by:
•Copy (don't move) DbgHelp.dll
from: the Memory Validator install directory
to: the location of the application being tested (the same directory as the .exe).
Rerun your test.
•Try updating the versions of DbgHelp.dll in:
c:\windows\system32
and
c:\windows\system32\dllcache
Accept any Windows permission warnings if you try to do this.
Rerun your test.
If you still continue to have problems, please drop us a line via our support email.
|
, copying the correct private version to your application's directory as your program is started. 
For versions of Memory Validator older than 3.48, see the next question. (Also, consider upgrading if you can!) Memory Validator uses the Microsoft Debugging DLL, DbgHelp.dll
However, there are cases where your application can be started independently. For example, if you are linked to the Memory Validator API, you can attach to a running or newly started instance of Memory Validator.
In these situations you must ensure that your application uses the correct DbgHelp.dll.
Installing the correct DbgHelp yourself
To help you detect when the wrong DbgHelp.dll is loaded, Memory Validator has some error messages and a warning dialog.
Diagnostic error messages appear on the Diagnostics tab as in the example shown below indicating which function could not be found in DbgHelp.dll and which feature was trying to use this function.
An optional warning dialog also gives the same information.
•Help
•Don't show this warning dialog again
If you see this warning dialog, or get diagnostic errors, ensure the correct DbgHelp.dll is used by:
•Copy (don't move) DbgHelp.dll
from: the Memory Validator install directory
to: the location of the application being tested (the same directory as the .exe).
Rerun your test.
•Try updating the versions of DbgHelp.dll in:
c:\windows\system32
and
c:\windows\system32\dllcache
Accept any Windows permission warnings if you try to do this.
Rerun your test.
If you still continue to have problems, please drop us a line via our support email.
|
Displays this help topic
It can be confusing to see why symbols fail to load for modules built with compilers that generate PDB files, eg: Microsoft, Intel.
There are typically three reasons for failure: the PDB file is...
•missing, for example it was not provided with the executable •in the wrong place, so the the debugging library can't find it •the wrong version, for example from a different build
The diagnostic tab
The Diagnostic tab of Memory Validator displays lots of messages that can help diagnose many problems.
To show only DbgHelp debug information, use the message filter drop down at the top of the diagnostic tab. This lets you examine where DbgHelp.dll looks for symbols.
Examine the output to see if it's finding the PDB file you think it should, and if it rejects the contents of any PDB file it finds.
Output for alternate modules is shown in alternating coloursets, and the messages are the exact same output from the DbgHelp.dll debugging stream.
Examples of examining the diagnostics
Below we show three examples using nativeExample.exe and nativeExample.pdb from our example application.
•Correct symbol file found
DbgHelp first searches in various places looking for nativeExample.pdb
Depending on your machine, there may be other search paths included.
Finally nativeExample.pdb is found in the same directory as the .exe file of the target program
DbgHelp loads private symbols and lines, (the alternative being that DbgHelp loads public symbols).
Outcome: Success. Symbols are loaded.
•Missing symbol file
As before, DbgHelp first searches in various places looking for nativeExample.pdb
But, nativeExample.pdb doesn't get found in the same directory as the .exe file of the target program.
nativeExample.pdb never gets found on the search path.
SymSrv might then look for additional locations for nativeExample.pdb, but has no luck.
DbgHelp might find some COFF symbols in the executable, however these don't contain filename or line number information.
Finally all options are exhausted.
Outcome: Failure. The PDB file could not be found. Some default symbols are loaded but are not of much use.
Resolution: Check the File Locations PDB paths to ensure that all the possible paths for PDB files are listed.
•Incorrect symbol file
As before, DbgHelp first searches in various places looking for nativeExample.pdb
This time, nativeExample.pdb does get found in the same directory as the .exe file of the target program.
DbgHelp tries to load the symbols but fails - the checksum inside the PDB file does not match the module.
This might be because the symbols are for a different build of the software, or it's an incorrectly named PDB file belonging to another program.
Finally all options are exhausted.
Outcome: Failure. A PDB file was found, but it was not the right one.
Resolutions: Double check the PDB is the correct one for the build you are running. When copying builds from another machine (or from a build server), make sure to copy the correct PDB as well. Check the File Locations PDB paths to ensure that all the possible paths for PDB files are listed. Check the order of those PDB paths in case there are multiple paths resulting in the wrong PDB being found first.
|
