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 Memory 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 traces contain location is 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 Memory 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
The documentation for VariantCopy()
Since the reference count for these objects with the VT_BYREF flag is unknown, Memory Validator assumes a new object is deallocated prior to the copy (destination variant is cleared) and that a new object is allocated in the destination.
For the cases where the operating system does not do this, but simply adjusts reference counts, leaks will get reported where there are none.
The MSDN documentation indicates this can only happen for COM objects and not for BSTRs.
Memory Validator only tracks BSTRs in VariantCopy(). We've not seen false reports of memory leaks for VariantCopy() but this question is here in case you do!
|
states that the operating system does not know the reference count for any object in a Variant that has the VT_BYREF flag. As such VariantCopy() cannot modify the reference count in the destination and source arguments.
If Memory Validator can't find debug information for DLLs that have their functions exported as ordinal values, the functions are named OrdinalXXX, using 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 Map Ordinals to function names check box on the Source Parser 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()
|
The following information applies to older operating systems.
Some machines have been found to exhibit unusual behaviour during the startup phase of the target program.
The result is a few memory allocations from the CRT that appear to come from an exception handler.
We have seen this behaviour on a Windows 2000® machine that, for unknown reasons meant neither Memory Validator nor Visual Studio could not find debug information for msvcrtd.dll and mfc42ud.dll despite it being available.
We suspect that the debug information, although present, was in some way not the correct debug information for the respective DLLs. Probably this was a configuration issue for the machines, caused by incorrect installation of a service pack, platform SDK, or other SDK.
Here's an example of one of these unusual data traces:.
All of these data traces happen at program startup.
This behaviour has been observed on one Windows 2000® machine, configured as a laptop computer.
This information is provided now only so that users do not get confused by this extra data that is collected by Memory Validator in this circumstance.
|
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.
|
