Hi,

Answers to your questions.

(1) The problem occurs on both 32-bit and 64-bit Windows. I am using the 64-bit version of PTU on 64-bit Windows and 32-bit on 32-bit Windows.

(2) It shows unknown(s) as the parent function name. It also has times that do not make sense. In this case I have a focus function called RECT_TRIUPDATE. Totalsamplesfor RECT_TRIUPDATE is 214 and self samples is 214. The parent listed in the Caller/Callee window is witha Total sample count of 1 and a self sample count of 169. I know that RECT_TRIUPDATE is called only by one routine in the code.

(3) Some of the routines in B.dll do get resolved. The code has both Fortran and C++. The only pattern I'm noticing so far is that it looks like in the dll's causing trouble, the Fortran symbols are resolved, but the C++ symbols are not. I did not do an exhuastive check, but in the example above the routine RECT_TRIUPDATE (Fortran) should show up as being called by the routine FactorizationDriver (C++). Both of these routines are built into a dll called ABQDDB_SOL_Core.dll.

If I sample directly I seem to largely have correct symbol names. I see one unknown(s). The function I'm looking for in the callgraph test, FactorizationDriver, does not show up in the sampling. This may not be too surprising because FactorizationDriver itself does not do too much work. It does not show up in a sampling run in the "corrected" build (see below) either, but does show up in the call graph run with the "corrected" build.

(4) Symptoms with VTune are as follows. (a) In the "Configure Call Graph" windows the suspect modules show up with "instrumentation status" listed as "Not instrumented" and the "Module Type" listed as "System." When looking at the results the behavior is similar. The routine FactorizationDriver fails to show up in the profile. What else might you be looking for in this description?

To give a bit more detail, if I look at the location of the executable being run here (standard.exe) in windbg it is located at 0x40000000 (2 GB) on the 64-bit Windows machine. Without any modification the dll ABQDDB_SOL_Core.dll ends up located at 0x6850000. If I run PTU with this address, I end up with the described behavior. If I then rebuild ABQDDB_SOL_Core.dll to 0x50000000 (using /BASE:0x50000000 on the link) then all is well (I checked with windbg that the dll does get relocated as a result of the relink).

This "corrected" build also behaves as expected in VTune.

I am not sure that the VTune and PTU issues are exactly the same. I just assumed since the same workaround seems to make both of them behave that the issue is related.

Finally here is the comment from VTune support that started us down the path of rebasing dll's. Also as far as we know using Visual Studio 200

"This sounds like an issue with the image base. Call graph assumes that DLLs based above a certain address are system libraries. One solution is to rebase the DLLs below some address. I don't remember the details, off the top of my head and can't find a reference. I will get you an answer tomorrow, but you might try just lowering the image base address."

Thanks,

Matt

Great. Appreciate your response on this. Let me know if you need me to provide any more information.

Thanks,

Matt