"Analysis is completed successfuly.
Failed to finalize the result."
In the Collector messages window I have this:
" Warning: user32.dll instrumentation requested more than once ...
Target process's profiling finished but the following processes are still being profiled:
PPID PID STATE NAME
003260 006244 RESUME MidiTester.exe
You may stop collection manually. The processes listed above will be terminated."
One project will analyze ok in Win64 but not Win32.
I have the same symptoms as:
Any idea why it's ok for some projects but not others?
It appears that the application is still running for some reason although the target finished. Have you tried the -duration option as suggested in the other forum post? Alternatively, manually stop your application execution. With this, does the behavior change? In terms of the Failed to finalize the result. You can try to re-resolve the results after the application has ended to see if the results can then be finalized.
To set duration for
a project in the Intel VTune Amplifier XE GUI:
1.) Click the Project Properties button
2.) In the Target tab on the left pane select the method you wish to use (Launch Application, Attach to Process, Profile System). The properties are then displayed for that method
3.) To set a duration, click the Automatically stop collection after (sec): checkbox option
4.) Enter some number of seconds in the field to the right of this option
5.) Click the OK button once you are done setting project properties
Does VTune cause the executable to be loaded and run more than once?
Are the Intel
VTune Amplifier XE Project Properties > Advanced > Allow multiple runs
or Analyze child processes options enabled?
If so, temporarily disable these options and attempt a new run to see if
/ how the behavior changes. Let us know
If the behavior persists, can you let us know the VTune Amplifier command line you are running where the unexpected behavior occurs? To get the command line in the GUI, click the Get Command Line button in the lower right corner of the GUI. Then copy / paste the command into your reply. If there is detail you wish to be private, you can make the forum post private if you wish.
It may be helpful for us to examine one of your VTune Amplifier results file, however, we can hold off on this until we know more about the command line being ran and the results of any changes in behavior based on the info in the previous paragraph.
Disabling those two options has no effect -- I'm getting the same behaviour every time now.
The command line parameters are:
amplxe-cl -collect concurrency -knob accurate-cpu-time-detection=false -knob collect-signals=false -no-follow-child -mrte-mode=auto -target-duration-type=short -no-allow-multiple-runs -no-analyze-system -data-limit=100 -slow-frames-threshold=40 -fast-frames-threshold=100 --search-dir sym=c:/Source/trunk/Source/Build/MidiTester/Release.Win32 --search-dir sym=C:/Source/trunk/Source/Projects/Utilities/MidiTester --search-dir sym=c:/windows/symbols --search-dir sym=c:/windows/symbols/singlepdbs --search-dir sym=c:/windows/symbols/microsoftpublicsymbols --search-dir sym=c:/Source/trunk/Source/Build/DeviceTester/Release.Win32 --search-dir sym=c:/Source/trunk/Source/Build/FourCCConverter/Release.Win32 --duration 60 -- c:\Source\trunk\Source\Build\MidiTester\Release.Win32\MidiTester.exe
I will be happy to supply further details if required.
Thank you for the additional information. I will ask Development about possible interaction with QtSingleApplication or similar situations and hope to have an update for you soon.
I am not sure if you have tried this already, but if you have the application running and attach Intel VTune Amplifier XE to your Application process (By name or PID) do you get different behavior? This is assuming that your application runs for enough time to gather data using this method.
To attach to process:
1.) Start your application
2.)Then switch over to Amplifier
3.) Click on Project Properties > Attach to Process
4.) Select the Process name or PID radio button and enter either the process name or PID
5.) Click Start
6.) Click Stop to stop sampling or wait until the application runs its course
Additional information about attach to process can be found here.
Another option may be to start the analysis paused (Start Paused button) and click Resume after your application has gone through its warm up. Information about start paused relating to the GUI can be found here. There is also a video here.
Also an option might be to use the Collection Control API within your source. Additional information about this can be found here. Let me know if this is an option and you need additional information about Collection Control.
This problem seems to be unique to Win32 applications -- I've not had any problems at all with my x64 binaries. I've tried several Win32 applications built from our codebase and VTune fails in the same way on all but the most trivial, so I'm inclined to think there's something about our codebase or the libraries we use which trips VTune up.
Can you let me know the
- The version and build if possible of amplxe-cl you are running. To do this, run amplxe-cl version at the command prompt. If you are running version 2011 with less than update 3, can you update to a minimum of update 3 or the latest which is update 4 of amplxe-cl?
- Does the analysis behavior always come back with a reference to user32.dll?
- Can you let me know the processor manufacture and model and also OS version you are working with?
- Are you running the analysis as Administrator?
- I'm running Update 3 (build 150226), I'll try to get hold of Update 4.
- Yes, it does appear that user32.dll is always referenced in the collector log. It never seems to get further than that.
- Intel Core i7 950 @ 3.07GHz. Win 7 64-bit
- I've tried running with elevated privileges (ie run as admin) and normally (my user has admin privileges but UAC is on)
Thank you for the additional information. So far I have not been able to replicate the behavior or locate an exact previous report with an apparent applicable resolution. However, there may be some leads To narrow the scope of the issue further can you let me know the following?
- When the behavior occurs, does Windows (Windows 7 / 64-bnit in your case) report any Error level System events in the Event Viewer > Windows Logs > System?
- What compiler and version are you working with?
I suspect that update 4 will produce the same behavior, but it is worth a try. If by chance you have a small reproducer MS Visual Studio solution that would be ideal.
Sorry for the delay in responding. I've checked the Event Viewer and sure enough there is a report of my application crashing when VTune tries to profile it. I've dug out the crash log file and analysed in windbg and it shows the following stack:
I suspect that some of the elements in the stack trace are bogus, but it does appear to point to a conflict between the tpsstool's injection into the process and the qjpeg4.dll (which is part of Qt). My build environment is VS2008 SP1. Unfortunately I can't provide a very minimal solution as this only occurs when I link against libraries in our codebase (which link against Qt), though I can provide some binaries if that's any use.
To reiterate, 64-bit builds work fine, this just seems to affect 32-bit builds.
Development is asking for additional information to help debug and / or replicate the behavior. First, would it be possible to install the latest update for Intel VTune Amplifier XE which you can obtain from the Intel Registration Center at https://registrationcenter.intel.com after you login? Then try to replicate the behavior. Let us know if the error message or behavior changes.
If the issue persists, Development is asking if you can please attach a debugger after the crash and collect stacks of threads in the failed application? If this is not possible then can we obtain either a reproducer to investigate locally or remote access to the machine where it crashes?