Profiling Nested DLL calls.

Profiling Nested DLL calls.

Hi,

I am currently evaluating vtune.

I develop a product in which the main application calls functions in dll "A" , A then calls functions in dll "B". I have no problem seeing the data for A however there is no profiler data for B.

Thanks,

Ben

4 post / 0 nuovi
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione

Hi Ben!

Did you build dll "B" with symbols?  Are the symbols in the location generated by the build, or was the PDB moved to a different directory? By default, on Windows, VTune Amplifier XE will look for the symbols file in the location specified within the DLL, which is where the build placed the PDB file.  If the file was moved, you can inform the VTune Amplifier XE where to look for the symbols using the Search Directories tab in the Project Properties.

Also, note, there are two checks to ensure that the PDB matches the DLL: 1) internal timestamps must match and 2) the "signatures" must match.  This is all defined by Microsoft* and you can search the web for more info (e.g., www.debuginfo.com).  If either check fails, VTune Amplifier XE will not load the symbols.  (FYI: if it does not load symbols, it will still load the function entry points from the Exports table, but it does not have function "extent" information or info on internal functions, i.e., only exported functions.)

Let me know if any of that helps, or if you still can't see the symbols for dll "B".

Regards,
MrAnderson

You can also check the IAT table of A dll for this use please dumpbin or LordPE.More advanced troubleshooting option is to use gflags and set loader snaps on, so you could test your application's callee resolution.Any problem will be reported by tracking the execution of NtLoader functions and reported to windbg console.

Besides symbol file location issue, I just comment on other reasons:

1. Maybe you called APIs from dll "B" quickly, so there is no enough workload - dll "B" cannot be profiled. Try lightweight-hotspots instead of hotspots.

2. Was it possible that functions from dll "B" were exported as "inline" function called in depth loop in dll "B"? See this article      

Lascia un commento

Eseguire l'accesso per aggiungere un commento. Non siete membri? Iscriviti oggi