Thank you for your time.
Most probably, there are callson path wheresystem modules or moduleswhich have no .pdb files with debug information are involved. In this case Thread Checker marks those calls as 'Unknown'.
If you feel that I missed the point, please provide the screen shots and explain in more details.
Actually Thread Chaker does not need to explicitly point out path to pdb files if you didn't move them after recompiling the project.
Just make sure you set the folloing options in the project properties:
C/C++ -> Debug Information Format -> /Zi
Linker -> Debugging -> Generate debug info -> /DEBUG
Linker -> Advanced -> Fixed Base address -> /FIXED:NO
Better results in symbols resolution canbe achieved by disabling compiler optimization:
C/C++ ->Optimization -> Optimization -> /Od
I've tried moving the .pdb files to the directory that contains the application executable. I've also tried moving some of the pdb files to the location of their corresponding .dll. Moving the pdb files to the dll location resulted ThreadChecker reporting different error messages. I didn't see as many of the "unknown" error messages, but the callstacks that were reported didn'tseem entirely correct.
I'm considering rebuilding all the 3rd party libraries and applicationusing Z7 instead of Zi.
OK. This sounds more clear. If some third party libraries are being built apart, Thread Checker's symbol resolver might not find the right paths. Usually, it's enough to assosiate those paths to dlls and pdbs. Go to Menu -> Configure -> Options -> Directories -> File Assosiation. Find the list of binary files of your project on each file type (Binary/Symbol) and assosiate the files with right paths. This might not result the similar behaviour to when moving dlls/pdbs, as I'm not sure if symbol resolver is used during collectiom. But give it a try.
If this doesn't help much, the reason is most probably compiler opimization options. You didn't mention whether you switched them off.
I don see any benefit in recompiling with Z7 instead of Zi or ZI.
The application's code was compiled with /Od. But not all of the 3rd party libraries were compiled with /Od.
Make sure you have at least one module of interest selected for your activity. Usually it's .exe file. You can check it at Activity Properties -> Advanced Activity Configuration Dialog -> Application/Module Profiles field -> [Your application] -> Configure -> Modules of Interest. This module should also appear in the File Association dialog (Context: Your Project; File Type: Symbol). If not, assosiate it with appropriate symbol file name manually. Try the collection again.
Note the module names of the "Unknown" functions in the stack. Check the level of instrumentation for those modules in the instrumentation table: Activity Properties -> Advanced Activity Configuration Dialog -> Data Collectors -> Intel Thread Checker -> Configure button -> Configure Chread Checker Dialog -> Instrumentation Tab. If the current level of instrumentation for the noted module is "Module imports", it means that thre is no debug info found for it. "Debug" column in the table can confirm that. In this case having the Unknowns in the stack is unavoidable.
If you see "Module imports" level of instrumentation for some dll, but you are sure that pdb-file is present, check the dll with Static Analizer: Menu -> File -> Open Static Module Viewer -> Choose the dll in the Open dialog. If you see all the functions of the dll in the list, it means that Thread Cheker couldn't find the path to the pdb file. If no functions listed (exept export ones), then it's something wrong with symbol information in the pdb.
Look through the output window messages after collection. There should be meaningful messages there regarding inability to instrument some ddls.
Could you confirm it - do you keep all thePDB filesinthe same directory as DLLs located in?
And if by mixed mode DLL you mean that some of DLLs are stripped out (no debug info), the stack will be UNKNOWN right after a call to such DLL.
Oh, I see now. Of course we use 'mixed' term when some .net part is incorporated. I just confused itwith the previous app description.
Thead Checker doesn't support .NET, which is unfortunate. This might affected the stacks reconstruction.Whereas, VTune static analyser is tolerant towards clr calls.