Comment tuer mscorsvw.exe
mscorsvw.exe (a.NET l'optimisation de la précompilation des assemblées) est de prendre un pourcentage substantiel de mon CPU - de 50 à 100%.
Cet article (et bien d'autres) dire que
ngen.exe executequeueditems
À partir de la ligne de commande doit le tuer. Pour moi, cette commande se bloque. Est-il une meilleure façon de tuer ce processus?
Je n'ai pas essayé de redémarrer. J'ai vu mon utilisation du PROCESSEUR pic plus d'une fois dans les derniers jours, et je crois que cela a été mon problème; j'aimerais savoir comment le tuer à l'avenir.
Pourquoi est-ce arriver a voté la fermeture? Ce processus est un .net précompilation optimizer (que des épaves les performances de votre ordinateur). Cette question est assez sur le sujet pour les programmeurs aussi loin que je peux dire.
La vraie question est, pourquoi est-il tellement CPU. Le tuer ne va pas les aider. C'est comme:
Pourquoi ce processus prend tellement le CPU est quelque chose pour MS de répondre. Mais il prend beaucoup de CPU est un problème très commun. google.com/...
La vraie question est, pourquoi est-il tellement CPU. Le tuer ne va pas les aider. C'est comme:
why is the engine of my car using so much gasoline? Well: I'll just axe the front of my car, and hope it stops using gasoline. Seulement, cette fois, sans doute la voiture a été construite pour relancer automatiquement le moteur après avoir mis la hache :).Pourquoi ce processus prend tellement le CPU est quelque chose pour MS de répondre. Mais il prend beaucoup de CPU est un problème très commun. google.com/...
OriginalL'auteur Adam Rackis | 2011-06-24
Vous devez vous connecter pour publier un commentaire.
Essayer
Espérons-le, se montre plus que simplement "je suis" et montre ce qu'il est en train d'essayer de compiler. Le
ngen queue stopcommande arrête le service.Ce service démarre lorsqu'un installateur déployé une assemblée et a demandé au service de pré-compiler avec
ngen install. Clairement que vous avez eu une mauvaise expérience sur votre machine, je suppose que c'est un échec de plus et plus de nouveau pour compiler une assemblée. Vérifiez le journal des événements Windows pour un fil d'ariane à ce sujet. Désinstaller le programme qui l'a fait.OriginalL'auteur Hans Passant
Nope, il n'a pas la tuer. Au lieu de cela, il rend intentionnellement pire. Au lieu de goutte à goutte de fond compile (alors que, normalement, vous n'auriez pas remarqué), il permettra de traiter tous en file d'attente des éléments à la fois. Cela va prendre un peu de temps pour terminer. Il ne traîne pas, il va travailler très dur. Quand c'est fait, c'est fait, et il n'y aura pas plus de choses à gauche à l'arrière-plan-compiler.
Remarque que le fond de la compilation d'emplois ont été ajoutés (le plus probable) par une mise à jour récente (vous avez probablement installé un service pack). Windows est en train de faire, par une faveur AOT-la compilation de toutes les assemblys gérés à l'aide de l' .NET compilateur JIT qui sait tout sur votre matériel et le type de processeur, de sorte qu'il sera émettent le plus de code optimisé. De cette façon, .NET garantit que le logiciel s'exécute plus rapidement à l'avenir, le coût de la compilation de votre assemblées maintenant
De nombreuses ressources qui vous sont indirectement liés à yoursef, lire celui-ci par exemple:
OriginalL'auteur sehe
.NET, à mon avis, a une conception discutable, alors qu'une "Juste À Temps" compilateur est nécessaire de courir à travers tout le compiler avant l'Heure.
Il y a normalement deux
mscorsvwdémons en cours d'exécution, l'un pour la version 64 bits et un pour 32-bit (ils se synchronisent avec les uns des autres). L'UC à 100% est ce que vous attendez pour un compilateur, mais c'est fait à faible priorité, et pas plus d'un noyau devrait être liée à la fois. Un avantage de Cpu multi-core est que des choses comme celles-ci vous reste encore un cœur à la voiture de l'interface utilisateur de l'interaction. (Notez que la recherche de l'indexeur est un autre démon du même genre, conçues dans le même sens.) Si vous avez un single-core CPU, alors vous verrez vraiment la charge ajoutée.OriginalL'auteur DAGwyn
Cela entraîne parfois sur un bug. Mon cas de SQL Server msiexec.exe les processus de continuer à fonctionner après l'installation de SQL Server 2012 SP1 Attendre la prochaine mise à jour comme d'habitude.
OriginalL'auteur 84RR1573R
J'ai eu le même problème après l'installation de SQL 2012. Après l'exécution de la commande ngen état des files d'attente, j'ai vu qu'il était le CLR optimisation des processus en cours d'exécution. De nouveau à l'aide de ce fil, j'ai pu voir, il y avait deux services Microsoft.NET Framework NGEN v4.0.30319_X64 et Microsoft.NET Framework NGEN v4.0.30319_X64 indiquant le 32 bits et 64 bits optimmization code.
J'ai vu que ces deux ont commencé, et la version x86 était le coupable. J'ai arrêté le service et le CPU est venu de retour de 100% à 0% et de la mémoire réduite d'environ 2 GO.
OriginalL'auteur Sar
Look .NET meurtres de base unique des Pc media center. De vieux ordinateurs lents pendant des heures, basé sur le web vidéo devient unwatchably agitée. Autant pour l'efficacité énergétique - dois-je laisser mon PC compilation 24/7 pour être parfois pris? L'utilisateur orientée processus ne prenez pas la priorité. Mieux encore il ne sera pas un pas de côté pour les mises à jour automatiques... y compris de .NET! Qui induisent une autre recompiler l'ensemble des ressources, de ne jamais se terminer avant le Patch Tuesday. Je n'ai pas trouvé les solutions de rechange suggérées ('ngen.exe installer /file d'attente" ou "ngen.exe mise à jour" - trouver ngen dans le cadre de répertoire) réactif. . - Je DÉSACTIVER Microsoft .NET Framework NGEN service dans les services.msc ou via la ligne de commande ('sc config clr_optimization_v4.xxxx start= disabled " où xxxx est le numéro de version; obtenir le numéro de version via sc query ou un nom de répertoire ou de services.msc); "arrêt" juste redémarre en quelques secondes. Examiner ou de la tentative de suppression totale du .NET 4.
OriginalL'auteur Relth