Intel Thread Profiler thinks my DLL is Type System

[andy-glaister]

So it only offers to instrument module imports. Other DLL's we load in the same folder are marked as 'User DLL's and I'm able to fully instrument them. Why does it think this one DLL is a system DLL? The app loading it is instrumented (All functions) and other DLL's I load give me the option of how much to instrument.

I have tried renaming it, rebuilding it but I can't get it to instrument. Any ideas?

Thanks,

Andy

[Mark_D_Intel]

The base address for the DLL is used to determine whether it is a system or user DLL.
Use the rebase tool to set the base address to something below 0x70000000.

For more information, see the help under
VTune Performance Analyzer
- Collectionng and Analyzing Performance Data
- Using Call Graph Profiling
- Troubleshooting Call Graph
- Troubleshooting Instrumentation Failures



However, something seems odd here. Thread Profiler only needs the API Imports level of instrumentation to work. The "All Functions" instrumentation level should not even be an option in Thread Profiler. This level is needed for Call Graph and Thread Checker.

Also, even marked as a system dll, it should allow "API Imports" level of instrumentation. There may be something else preventing instrumentation.

[andy-glaister]

Sorry, it's Thread Checker I'm trying to use - the profiler works ok.

My DLL is at the default base of 400000, so it may be getting relocated higher up. There is no standard that says anything above 0x70000000 is a system DLL many system DLL's are rebased lower than this (All the D3D DLL's for example).

In the 'Configure Intel Thread Checker' dialog, the Level for my DLL says 'module imports' and when I right click and try and change this I get a warning in the Status column and results window that says 'Full Instrumentation not applicable'.

Is it saying this because it thinks it's a system DLL?

Thanks,

Andy

[TimP]

For what it's worth, I don't put much effort into attempting thread checker with dynamic instrumentation. I find recompilation and running with /Qtcheck more satisfactory, if you have that option.

[Mark_D_Intel]

Two other simple things to check are
- make sure debug information is available (see the instrumentation tab grid)
- look for any error messages during instrumentation in the output window

Beyond that, I would suggest contacting support at http://premier.intel.com/

There appears to be some problem instrumenting this particular DLL (more than just getting the user/system distinction wrong)

Mark

[andy-glaister]

I got it working - the help file is actually pretty good - it's just hidden behind the 'more help' button. It was the fact that the DLL gets rebased high causing Thread Checker to think it's a system DLL - I had to try rebasing it at a number of different addresses before I managed to get Thread Checker happy - it would be great to remove this limitation or have an option to force the instrumentation.

Thread Checker turned out to be not very helpful for our application. We only have a tiny number of critical sections and insteadresolve all our thread dependencies via reference counts and lock free lists - Thread Checker didn't tolike the factthat one thread was using data after another thread has used it - which was fine in our aqrchitecture because the threads only ran once their dependencies we met. I guess for applications that wrap all shared data in CriticalSections maybe this works better. I looked through a few hundred errors and didn't see any real threading issues :-( doh oh well, it was pretty and worked well (once I rebased).

Andy

[Mark_D_Intel]

Glad to hear you got it working.


There are some API's to tell Thread Checker about synchronization. Look in the help under API Support -> User-Level Synchronization API. I don't know if it's possible to map this to the way your app is organized - perhaps you could treat each reference count as a "lock"?

Mark