VTune reports high CPU usage when profiling .NET app

[fleisch]

Iam using the sampling profiler mode of VTune to profile the CPU usage of several .NET managed applications, and I am getting some unexpected results that are cause for concern. Specifically, 40-50% of the CPU usage recorded by VTune is in the mscorwks.dll.

As an example, in one of my .NET apps,the contributions to mscorwks.dll CPU usage are (in diminishing order):DllUnregisterServerInternal, TranslateSecurityAttributes, CreateAssemblyCache, IEE, and others. This application makes many calls into unmanaged DLLs through PInvoke, it has a high object creation rate (equivalent to about 40 MB/sec), and it uses the default (workstation) garbage collector.

In another example, the contributions are: DllUnregisterServerInternal, IEE, CreateAssemblyCache, TranslateSecurityAttributes, and others. This application does not make PInvoke calls (except those I don't know about through .NET methods), it has a much lower object creation rate, and it also uses the default garbage collector.

Is all of this real CPU usage? Is this common for .NET applications?Unfortunately, there is little or no documentation on the functions I have listed, so I don't know what they are doing or why they take so much time.

Any help would be much appreciated!

[Milind_H_Intel]

Hello,

Looks like you might not have proper symbols for mscorwks.dll. By default, if you have not specified the pdb, then VTune will give export functions (mscorwks.dll) and that is what you are seeing. Can you please do the following?

If you have installed .NET SDK, mscorwks.pdb will be in C:Program FilesMicrosoft Visual Studio 8SDKv2.0symbols directory. Copy the mscorwks.pdb to where CLR is installed. i.e in C:WINDOWSMicrosoft.NETFrameworkv2.0.50727 directory as example. Then right click on sampling results and go to symbol resolution window. In the dialog box, select mscorwks.dll and in the right hand side, you will see places for dll and pdb. Make sure you have correct pdb set (path wise). then open your sampling results and see if still you see same functions/hotspots in mscorwks.dll

Aother thing is it is not too surprising to see mscorwks.dll is consuming ~40% of your clocks. It is totally based on your application and mscorwks.dll is the cor runtime and it is important to see what those functions are in mscorwks where you are spending time. And based on my experience, those are not proper hotspots.

Thanks,