Some callstacks may not have a symbol name and can display the value <UNKNOWN>.
There are several reasons this may happen:
•The program you are monitoring has no debugging information
You'll need to enable debugging information in your program.
Debugging information is controlled from the Linker Tab on your Visual C++ project settings, and is available for Debug and Release builds.
•The PDB files with the debug information can't be found
The program you are monitoring may have the debug information but Thread Validator can't find the debug information if it's stored in PDB files that are not in the current directory.
Use the File Paths dialog to set where the PDB files can be found.
If you don't have PDB files for a particular DLL, but do have MAP files, you can also set the location of these too.
•A stack trace contains a location not present inside a DLL
This sometimes happens when hooks cause the program to jump to dynamically allocated memory holding the hook.
These hooks will not have any debugging information referencing them.
•The DLL has no filename and line-number data in the debugging information
This is the case for some release mode DLLs from Microsoft such as mfc42(u).dll and mfc80(u).dll.
These only have symbol name information available, with filename and line-number removed.
If you have this problem, you could try and get more up to date symbol information from Microsoft using the symbol server support page in the global settings dialog.
If none of the above solves your problem and all symbols are still displayed as <UNKNOWN> please drop us a line. We have found that newer versions of Visual Studio sometimes change the debug information format and need a newer version of DbgHelp.dll. The version of DbgHelp.dll that is shipped with Thread Validator is compatible with Visual Studio.net and all previous versions of Visual Studio.
|
Note that this will only work if the symbol server symbols
If Thread Validator can't find debug information for DLLs that have their functions exported as ordinal values, the functions are named OrdinalXXX, using the decimal number of the function.
These ordinal values can be displayed as function names, but only if the linker definition (.def) file that refers to each relevant DLL is known.
You can define the Ordinal Handling, but don't forget to also select the Convert DLL exported function ordinals to symbols check box on the Symbols and Warnings page of the global settings dialog.
Here's an example of Ordinal function names without debug information: Ordinal711 and Ordinal187
And here's the same thing without debug information but after ordinal to symbol conversion, showing __cdecl operator new() and int AfxWinMain()
|
This is relevant to one version of the VisualStudio.net DbgHelp library that sometimes does not correctly identify the end of a stack walk.
When this happens, a stack trace can have numerous addresses of value 0x006d0065 tacked onto the end of it, even if the stack walking callback informs DbgHelp that the address is not valid.
We don't filter these addresses out, in case a valid DLL does get loaded and uses this address space, producing symbols for this address.
Callstacks that contain this error look like this:
As you can see from the image, the program started at the UNICODE entry point wWinMainCRTStartup, so there should be no symbols (other than GetPriorityBoost or other kernel32.dll symbols) after this entry.
Subsequent versions of the DbgHelp.dll from Microsoft fix this bug.
|
