Lock and Waits analysis empty of information

Lock and Waits analysis empty of information

I am trying to improve a component library we developed. If I call the library in a console based (text) program, written specifically to test one routine, vTune Lock and Wait analysis do show Worker thread wait/running states and lock transitions. However, when I run the original main GUI based application, vTune Lock and Wait analysis shows absolutely no information. All the Bottom-Up, Caller/Callee and Top-down Tree basically have one row with [Unknown]/[Unknown]/[No call stack information]. The Tasks and Frames shows the work threads are all running between my VTPause() and VTResume() calls, for approximately 10 seconds, and the CPU Usage graph has a realistic graph, but the Thread Concurrency graph is FLAT, there is no Waits region (click on the Waits graph does nothing), and no Thread/Lock transitions are displayed when the Transitions box is checked.

The collection has no error, the resolve process produced no error. The application runs fine, but the collector output (when run in a command prompt) does not appear to look for debug symbols for some dlls which I know are loaded and was running. It does fail to load debug symbols for mscorwks.dll, perfdisk.dll, user32.dll (system / .Net framework dlls), but there are no error messages.

Any idea what I should do to allow me to perform the analysis on the project showing call stacks and lock / waits?

Thanks

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

What are my thoughts are:

1. Is this main GUI based app multithreaded application?

2. Did you built this with debug info, even in release mode? Check compiler option "/Zi" & linker option "/DEBUG" enabled? You may test a simple Win-based GUI application - e.g. Helloworld, created by MS Visual Studio, running Locksandwaits should get wait-objects, such as message, single, multipleobjects, etc. You may compare their project's properties.

3. If you remove Pause/Resume API, could it work? Have you tried on latest build Update 15? 

Hi Peter

1) Yes, the GUI app is also written in C# and is multi-threaded, including those launched by the shared component I am trying to profile.

2) All projects (there are at least 10) are C#, with 1 being CLI/C++, built with debug information (each dll in the project output directory has a corresponding .pdb debug symbol file, as well as the main .exe file has a .pdb). This includes the CLI/C++ portion (which was also included/required in the console/text based test program, the one vTune can profile)

3) That was the first thing I tried. I only added the Resume/Pause after I saw missing stack, thinking maybe it can better analyze given a smaller time period to analyze where the data processing actually occured (about 15 seconds)

There is no problem - I just test C# code with LocksandWaits. I don't think it does make sense if you add Resume/Pause API to track wait-objects and transition, the reason is that VTune doesn't know objects' status before 10ms - how to calculate wait time?

You can profile whole application, and select small time period (Use Zoom-in/Filter on Selection) to generate a new report. How to do that? I suggested you to use Mark "user task" in other thread.

Are you saying that Resume and Pause calls are causing the problem of having no stack information and no wait/transition information? I did state that I was able to do the Locks and Waits analysis by creating a separate C# Console application that test a limitted portion ot the component. The Resume and Pause calls were each added only ONCE in the running of the program to isolate the portion that does the data analysis.

Quote:

Min Xu wrote:

Are you saying that Resume and Pause calls are causing the problem of having no stack information and no wait/transition information? I did state that I was able to do the Locks and Waits analysis by creating a separate C# Console application that test a limitted portion ot the component. The Resume and Pause calls were each added only ONCE in the running of the program to isolate the portion that does the data analysis.

 

It should be confused on computing object's wait time, for example - if the lock was freed in time-1 (you paused VTune), on time-2 (you resume to profile) you don't know the lock was freed, regard the lock locked since you paused profiling on time-1.

It there any problem to do scenario I posted before? 

Leave a Comment

Please sign in to add a comment. Not a member? Join today