NET Runtime Optimization Service (mscorsvw.exe) uses CPU & RAM while machine is not idle - by Mike Honey - Manga Solutions

Status : 

  Not Reproducible<br /><br />
		The product team could not reproduce this item with the description and steps provided.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 783503 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 4/11/2013 7:45:23 PM
Access Restriction Public


Via Windows Task Manager, I frequently notice that instances of mscorsvw.exe are consuming 100% of one Core and as much as 2GB RAM for many minutes.  From my understanding this process is spawned from the NET Runtime Optimization Service, and should only be active when the machine is idle.  This behaviour occurs whether the machine is idle or not. 

Obviously such intense resource use has a significant impact on the performance of the machine.
Sign in to post a comment.
Posted by Microsoft on 4/16/2013 at 3:02 PM
Thank you for your feedback. Since the scheduling policy of .NET Runtime Optimization Service is different depending on the type of the OS and .NET Framework, could you please provide the following information: What is the version of the .NET Framework, and the version of the Windows? Is this a client or server SKU of OS? What are the parent processes of mscorsvw.exe?

Generally speaking, .NET Runtime Optimization Service runs more proactively on server systems than on client systems. In particular, on Windows Server 2012, it no longer waits for idle, in order to bring the server more quickly to a stable state. In Windows 7 and below, the scheduling is handled by .NET Framework, while on Windows 8 and Windows Server 2012, the scheduling is controlled by Windows. Regardless of the version, the Optimization Service should always be running at low prioriy, to minimize impact to other applications.

John Chen / Common Language Runtime
Posted by Microsoft on 4/15/2013 at 4:25 AM
Sorry the pre comments is wrong comments. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by Microsoft on 4/15/2013 at 4:22 AM
Thank you for submitting feedback on Visual Studio and .NET Framework. In order to efficiently investigate and reproduce this issue, we are requesting a WinPrf file. We look forward to hearing from you with this information.
Posted by Microsoft on 4/11/2013 at 7:51 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(