Incident récurrent: «Une exception win32 non gérée s'est produite dans mscorsvw.exe». Comment diagnostiquer / réparer?

3

J'ai récemment eu un nouveau PC au travail et j'ai dû réinstaller les outils de développement, etc. Le PC fonctionne sous Windows XP (blech). service packs et correctifs. Windows XP lui-même est également à jour (si l’on pouvait dire cela :-)

Un problème récurrent que j'ai remarqué est le dialogue suivant, qui a tendance à apparaître après que la machine a été tourner au ralenti pour un moment:

Visual Studio Just-In-Time Debugger: An unhandled win32 exception occurred in mscorsvw.exe ... Do you want to debug using the selected debugger?

Je soupçonne que cet incident est dû au fait que .NET Framework a effectué la compilation Ngen des assemblys système en arrière-plan et qu’il se bloque lorsqu’il atteint un assemblage en particulier.

J'ai trouvé une autre mention Pour résoudre ce problème sur les forums MSDN, l’une des solutions de contournement suggérées consiste à configurer la fonctionnalité de prévention de l’exécution des données de Windows XP. "Activer la PED pour les programmes et services Windows essentiels uniquement" . Cependant, c'est déjà le réglage en vigueur sur mon PC.

Comment puis-je diagnostiquer plus loin? Lorsque j'essaie de m'attacher au processus, il est déjà parti.

Existe-t-il d'autres solutions suggérées ou probables?

METTRE À JOUR:

J'ai trouvé plus d'informations sur ngen ici et ici .

J'ai exécuté ce qui suit à une invite de commande: ngen executequeueditems Cela me permet maintenant de reproduire le problème de manière fiable au lieu d’attendre l’exécution du ngen inactif.

Donc quand ngen.exe obtenu à l'entrée suivante:

Compiling assembly Microsoft.SqlServer.Management.MultiServerConnection, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91 (CLR v2.0.50727) ...
WARNING: Cannot hardbind to mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 because dependency does not have a native image (check FusLogVw for reason)
Failed to generate native code for dependent image Microsoft.SqlServer.Management.MultiServerConnection, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91 because of the following error: The remote procedure call failed. (Exception from HRESULT: 0x800706BE)

... le résultat était la boîte de dialogue d'erreur suivante:

.NET Runtime Optimization Service has encountered a problem and needs to close.

Considérant que, d'autres assemblys qui ont échoué la génération d'image native n'a pas réellement causé crash , juste un message d'erreur.

Donc, l'assemblage spécifique sur lequel il échoue est: Microsoft.SqlServer.Management.MultiServerConnection .

Que puis-je faire d'autre? Je ne me soucie pas particulièrement de savoir si ça peut être générique ou non à ce stade; Je veux simplement arrêter cette boîte de dialogue d'erreur récurrente ennuyante d'en haut. J'ai déjà essayé:

ngen uninstall Microsoft.SqlServer.Management.MultiServerConnection,

... mais il est écrit "ERROR: l'assembly spécifié n'est pas installé".

Est-il possible de supprimer un assemblage du ngen queue , alors ngen ne va même pas essayer de générer une image native pour cela?

— Chris W. Rea
source

Quelles informations le journal des événements fournit-il? Parce que vous pouviez résoudre ce problème si vous saviez pourquoi "L'appel de procédure à distance a échoué. (Exception de HRESULT: 0x800706BE)". Existe-t-il des vidages mémoire disponibles?

— Tom Wijsman

3

Le nGen de l'assembly Sql Server échoue car une tentative précédente de nGening de l'assembly .Net Framework 2.0 mscorlib a échoué . Cela n’a rien à voir avec .Net 4, je vous suggère donc de cesser de regarder son service ngen (les 2 et 4 utilisent leurs propres services).

En ce qui concerne les raisons de cet échec - eh bien, il n’ya pas beaucoup d’information sur le net à ce sujet. J'ai trouvé ceci sur les forums MSDN cependant - il y a quelque chose à l'intérieur pour confirmer si mscorlib a été correctement configuré - j'aimerais vérifier cela.

Fait intéressant, SQL Server est également mentionné sur ce fil. bien que nous soyons en 2005 et je pense que les assemblys de la version 10 dont vous parlez ici sont des SQL 2008, mais peut-être quelque chose.

Mais finalement, si c’était ma machine, je le ferais:

Désinstallez .Net 2.0, 3.0 et 3.5 (si vous vous sentez courageux, désinstallez également la version 4.0)
Désinstallez le composant Sql Server contenant l'assembly qui fait échouer le nGen.
Installez le .Net 3.5 sp1 redistribuer; en vous assurant que vous avez aussi le correctif qui est référencé plus loin dans la page.
Attendez que tout le nGening soit terminé avant de continuer.
Si vous avez désinstallé .Net 4, réinstallez-le aussi maintenant.
Réinstallez le composant Sql Server supprimé à l'étape 2.

Oui, je sais, un peu une réponse «éteignez-la et rallumez-la», mais je pense que c'est mieux que d'essayer de contourner le problème. Si mscorlib 2.0 n'a pas correctement généré nGen, alors .Net 2.0 n'est pas vraiment utilisable dans son état actuel. Et puisqu'il s'agit d'un composant SQL Server qui tente de nGen - seul un mscorlib v2 nGen fonctionnerait avec ce dernier (ce ne sera pas le cas pour nscen mscorlib v4).

— Andras Zoltan
source

+1, accepté et prime attribuée. La désinstallation et la réinstallation de .NET 2.0 et .NET 4.0 comme décrit ci-dessus semblent avoir résolu le problème. Il n'y a plus de crash, plus de message concernant les échecs de ngen dans le journal des événements, et la file d'attente de ngen est maintenant vide. Merci!

— Chris W. Rea

@Chris W. Rea - Excellente nouvelle, heureux de vous aider :)

— Andras Zoltan

3

mscorsvw.exe pourrait être considéré comme un programme Microsoft tout en bénéficiant du DEP, vous pouvez vérifier s’il est vraiment hors tension avec Explorateur de processus . Soit en ajoutant une colonne DEP ou en vérifiant les propriétés du processus.

Visual Studio (du moins pour moi) n'est pas vraiment pratique pour déboguer des collisions, vous ferez mieux de faire un dump afin que nous puissions essayer de rechercher les causes possibles. Vous pouvez installer le débogueur par défaut en utilisant drwtsn32.exe -i. Ou si vous voulez apprendre, vous pouvez utiliser WinDBG , ce qui vous permet d’analyser plus en détail les programmes bloqués. Bien que ce soit bien si ça ne vous intéresse pas ...

Je soupçonne que cet incident est dû au fait que .NET Framework a effectué la compilation Ngen des assemblys système en arrière-plan et qu’il se bloque lorsqu’il atteint un assemblage en particulier.

Ne serait pas ngen.exe crash à la place alors? Pouvez-vous confirmer que ngen.exe courait?

Vous pourriez mettre en place Moniteur de processus de sorte qu'il ne montre que les processus / threads au début / arrêt pour que vous puissiez voir ce qui a été exécuté, laissez-le fonctionner pendant un moment et consultez-le dès que vous aurez cette fenêtre de débogage.

— Tom Wijsman
source

1

Je peux maintenant reproduire le problème avec ngen executequeueditems; s'il vous plaît voir ma mise à jour ci-dessus dans la question.

— Chris W. Rea

1

p.s. Merci pour le conseil sur WinDBG; J'ajoute ceci à ma liste de choses que j'ignore et que je devrais en apprendre davantage. :-)

— Chris W. Rea

2

"Activer le DEP pour les programmes et services Windows essentiels uniquement".

Comme mscorsvw.exe est un service, cela ne l’affecte pas vraiment.

Comment puis-je diagnostiquer plus loin?

Regardez les fichiers journaux ngen. Ils se trouvent probablement dans divers dossiers tels que C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 ou n’importe quelle version d’infrastructure que vous avez installée.

— sgmoore
source

Merci, le fichier journal est utile. +1 Je reste toujours avec le problème, mais maintenant au moins je sais quel assemblage est à l'origine de la panne de ngen.

— Chris W. Rea

Si je comprends bien, la liste des éléments qui devraient être ngen-ed est stockée dans le registre à l'adresse HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ .NETFramework \ v2.0.50727 \ NGENService \ Roots. Donc, il pourrait être possible de supprimer une entrée à partir de là. Cependant, je ne peux pas m'empêcher de penser qu'éviter ngen-ing cette dll va juste éviter cette erreur, mais vous pourriez avoir une erreur lorsque vous essayez d'utiliser cette dll.

— sgmoore

Ce que j'ai lu, c'est que si un assemblage n'est pas générique, le CLR l'exécutera simplement via la compilation JIT traditionnelle. Il y aura probablement une pénalité de performance avec JIT au lieu de l'image native. Mais je ne m'attendrais pas nécessairement à ce qu'il plante, si la compilation JIT est suffisamment différente du générateur d'images natif.

— Chris W. Rea

Ce que je veux dire, c'est que je soupçonne qu'il peut y avoir une corruption avec cette dll (ou quelque chose qu'elle utilise) qui provoque le crash de ngen et si tel est le cas, le problème restera malgré tout.

— sgmoore

1

De Qu'est-ce que mscorsvw.exe? comment le désactiver de l'exécution :

Mscorsvw.exe est un processus lié à   Microsoft .NET Framework. Mscorsvw   processus est utilisé pour précompiler .Net   assemblages-cadres dans le   Contexte.

Le processus Mscorsvw.exe s’exécute uniquement dans le   fond s'il faut compiler   assemblées les plus prioritaires après   installation de .NET Framework   redistribuable et une application   utiliser .NET Framework est installé pour   avoir ses assemblées compilées.

Précompilant normalement une priorité élevée   les assemblées se feront par   mscorsvw.exe processus avec dans 5 à 10   minutes, puis il va essayer de   traiter des assemblages de faible priorité lorsque   votre ordinateur est inactif.

Désactiver ou arrêter mscorsvw.exe

Aller vers C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 dans l'explorateur Windows.

Ouvrez l'invite de commande en tapant cmd dans la boîte d'exécution et appuyez sur Entrée.

Maintenant, nous devons spécifier le chemin ci-dessus dans la commande et maintenant taper
ngen.exe executequeueditems
et appuyez sur Entrée.

Maintenant, attendez que le processus précompile tous les assemblys, après   quelques minutes ce sera   terminé.

Maintenant, vous observez qu'il n'y aura pas   processus mscorsvw.exe en cours d'exécution dans la tâche   directeur.

Vous pouvez également utiliser cette commande à tout moment pour voir s'il y a quelque chose en attente d'être exécuté:

ngen queue status

et aussi :

ngen display

Pour effacer tous les éléments en file d'attente, procédez comme suit:

ngen /delete *

Pour savoir quels assemblys sont à l'origine du problème, consultez les fichiers journaux susceptibles de vous aider:

C:\Windows\Microsoft.NET\Framework\<version>\ngen.log
C:\Windows\Microsoft.NET\Framework\<version>\ngen_service.log

Sur une autre note, vous n'avez pas besoin de .NET Frameworks 2.0 et 3.5, car 4.0 est supposé les remplacer.

— harrymc
source

+1 pour ngen.exe executequeueditems .. m'a permis de reproduire le problème en dehors du contexte de fond inactif. Ensuite, ngen queue status simplement des rapports "Le nom du service est: clr_optimization_v4.0.30319_32 .. Le service d'optimisation de l'exécution .NET est en cours d'exécution." Cela ne montre pas s'il y a quelque chose dans la file d'attente, mais ngen.exe executequeueditems semble toujours avoir du travail à faire.

— Chris W. Rea

Vous pouvez essayer de désactiver le service "Microsoft .NET Framework NGEN v4.0.30319_X86". Cela peut empêcher la compilation en arrière-plan.

— harrymc

@harrymc Une lourde solution de contournement. Je préfère continuer à faire fonctionner le service et supprimer de la file d'attente uniquement l'assembly unique à l'origine du problème.

— Chris W. Rea

J'ai ajouté quelques informations supplémentaires.

— harrymc

1

@Chris W. Rea: Il est possible qu'une (non) installation ait mis en file d'attente un assemblage inexistant. C’est pourquoi il est recommandé d’arrêter le service ngen lors de l’installation (non) d’un produit contenant des assemblys. Avez-vous essayé de vider la file d'attente en utilisant ngen /delete * ?

— harrymc