Profiling Nested DLL calls.

Profiling Nested DLL calls.

Imagen de benjamin s.

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

publicaciones de 4 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.
Imagen de MrAnderson (Intel)

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
Imagen de iliyapolak

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.

Imagen de Peter Wang (Intel)

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      

Inicie sesión para dejar un comentario.