Die Ursache hierfür liegt dadrin, dass das mit dem Client Profile installierte .NET Framework 4 zur Performanceoptimierung versucht, in einem portablen Byteformat vorliegende .NET-Anwendungen und deren Assemblies in prozessorspezifischen Binärcode zu übersetzen, der dann in einem Cache vorgehalten wird. Dies ist an und für sich auch gar nicht verkehrt und das Framework versucht standardmäßig zunächst nur die wichtigsten Assemblies zu übersetzen und sich die restlichen zu einem Zeitpunkt vorzunehmen, an dem der Computer nicht ausgelastet ist. Allerdings scheint diese Vorgehensweise nicht immer richtig zu funktionieren, so dass der dazugehörige mscorsvw-Prozess exzessiven Ressourcenverbrauch zeigt, wie im Task-Manager beobachtet werden kann.

Wenn dies der Fall ist, hilft das Öffnen einer Kommandozeile und das Programm ngen weiter. Dieses Programm findet sich beispielsweise unter C:\Windows\Microsoft.NET\Framework\v4.0.30319. Aufgerufen mit der Option executequeueditems wird der Kompiliervorgang für alle verbleibenden Assemblies angestoßen, was zwar einige Zeit dauert — dafür ist das System danach wieder gewohnt schnell. Das Programm findet sich ggf. ebenfalls im Parallelordner v2.0.50727, muss aber für diese Version des .NET Frameworks nicht erneut aufgerufen werden.