Investigate further by:
1.) Terminate the program gracefully by pressing it's window's close button or another built in shutdown mechanism,
but not by pressing VTunes red stop button during the profile run.
2.) If this does not help go to Menu->Configure->Modyfiy->Instrumentation->Advanced and set everything to "Module Imports" except the executable. Does it work in this case ( also procceed like in 1. )? If yes, investigate further by incrementally resetting the libs to API Imports. One single lib could cause the problem (had this problem with DirectX9 Lib).
3.) Do an instrumentation during compilation by using the /Qtprofile switch in the compiler command line. A *.tp
file will be genrated after running the executable which you can open with Thread Profiler. Does it work in this case?
4.) If nothing helped, built a statically linked executable - does it work in this case?
Thanks for your time on reply my post R4dium.
I was working on your suggestions with the following results: 1) and 2) didnt work, I continue getting same error message.
Option 3) generate a tp.tp file after I run it, good news is that I can open this file with Thread Profiler, bad news is that results not make sense to me, I'm going to try explain better. The program that i want to profile was parallelized with OpenMP. I may check it with Thread Profiler with OpenMP -specific collection mode fine, in this view I can see thread times fine and actually most of the time the program runs with parallel regions. Then I want to verify my program with Instrumentation collection mode, here is where I have the issue. After I worked with option 3) you suggested me, I may open it the file, but the report tells me that I have my threads the whole time in wait mode and show me that only one thread perform whole the job in serial mode, I mean, same program give two different results: one with OpenMP specific collection mode and different result with Instrumentation collection mode by getting profile data with /Qtprofile switch. So, at this point I don't know if profiling with /Qtprofile switch is reliable. I'm wondering if you have results with this method that make sense to you ?
And to be honest I do not know howto perform option 4) you suggested me, I'm sorry =(
I'm going to continue investigating and if I found something new, I'll post news here.
Try to further isolate the problem:
If you only use a few libs, it might be useful to find out
if profiling works if you comment out a specific lib's function calls.
It might be more comfortable if you program a test-main() routine for each lib
were you only call the functions of a certain lib and look if this program is profilable
in thread profiler.
This is the only way to make sure that no lib is responsible for the unexpected exit.
In my case it was a lib called "libavcodec.dll" which caused the same error message
even if the functions where never calles during runtime (was enough to compile in such functions).
With regards to option 3, the compiler-instrumentation option (/Qtprofile) doesn't work well with OpenMP because all the threading calls in the Openmp library won't get instrumented. You will need to use Openmp-specific profile information (/Qopenmp_profile), or get binary instrumentation working.
Just one more data point - I am also getting this error on my home system - quad core system running Vista
I am usingIntel VTune Performance Analyzer 9.0
Get the same error just trying to profile the primes example that comes in the Vtune TProfiler Smpales folder - This is much simpler reproducer if you can get it to work on Intel system on Vista as it only requiress the following dlls
I have tried running VTune as administrator etc no luck
It just does not seem to create a tp file at all
The TP cahce folder is set to default here:
running Thread Profiler places several temp files here but NO TP file is created - I wonder if it is an over zealous Vista protection issue of some kind