High CPU usage of IIS process (w3wp.exe) because of many slow clr.dll!CopyPDBs

Question

I am using Windows Server 2008 R2 Enterprise with IIS 7.5, hosting ASP.NET MVC 5 applications.

I've noticed lately that one of the w3wp.exe processes is using extremely high CPU bandwidth:

After investigated little bit more, I've also noticed that the reason of this is the function clr.dll!CopyPDBs:

Does anybody know what can be the problem?

If the reason is not related to .NET Framework and clr.dll!CopyPDBs how can I investigate further to find the actual reason for this

Solution 1

This is usually because you have a custom application on top of IIS. If it is an in house built application, speak with the Developers about it.

If it is not developed in house, please have a look at .net CLR with counters https://msdn.microsoft.com/en-us/library/x2tyfybc(v=vs.110).aspx and more tips on CLR performance https://msdn.microsoft.com/en-us/library/ee851764(v=vs.110).aspx and https://msdn.microsoft.com/en-us/magazine/cc163528.aspx .

Solution 2

That simply means it's a .NET application that's taking all the CPU, but Process Explorer can't find the .pdb files for it. See https://stackoverflow.com/a/31705019/8479 for more detail.

If you can't get Process Explorer to say what's going on then try other avenues like log files, event log and Process Monitor.

Solution 3

This is a guess at best, but perhaps your development team is building and deploying the application in debug mode, in stead of release mode. This will cause the occurrence of .pdb files. The implication of this is that your application will take up additional resources to collect system state and debugging information during the execution of your system, causing more processor utilization.

So, it would be simple enough to ensure that they are building and deploying in release mode.

Comments

[zihotki]

Unfortunately, the answer makes no sense at all. The issue happens sometimes after you build in Visual Studio an application which is configured to use IIS (Not IIS Express which is default for VS web projects). The issue is not in the application code but somewhere in IIS. Killing the process in task manager fixes the problem (IIS will start a new process for the application and it will work fine).