In a few cases Performance 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.
|
Performance 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 Performance 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. 
It can sometimes be quite confusing to see why symbols fail to load for modules built with compilers that generate PDB files, e.g.: 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 debugging library can't find it •the wrong version, for example from a different build
The diagnostic tab
The Diagnostic tab of Performance 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. |
If you don't have the ability to use .PDB files for debug information , you may be able to use .MAP files with line information.
The following is only applicable to Debug builds. Map files for Release builds can't have line number data.
To select the /MAPINFO:LINES option for Visual Studio 6.0 use the following steps. If you are using Visual Studio 7.0, 7.1 (i.e .NET 2002 or 2003) the project settings user interface is slightly different, but the basic principle remains the same.
In Visual Studio:
|
Microsoft discontinued support for including line information in .MAP files with Visual Studio 8.0 (2005). There is no easy workaround to this.
