Gestionnaire d'exceptions non gérées dans .NET 1.1

Je gère une application .NET 1.1 et l'une des tâches qui m'a été confiée est de m'assurer que l'utilisateur ne voit aucune notification d'erreur hostile.

J'ai ajouté des gestionnaires à Application.ThreadException et AppDomain.CurrentDomain.UnhandledException , qui sont appelés. Mon problème est que la boîte de dialogue d'erreur CLR standard est toujours affichée (avant que le gestionnaire d'exception est appelé).

Jeff parle de ce problème sur son blog ici et ici . Mais il n'y a pas de solution. Alors, quelle est la manière standard dans .NET 1.1 de gérer les exceptions non interceptées et d'afficher une boîte de dialogue conviviale?

La réponse de Jeff a été marquée comme la bonne réponse, car le lien qu'il a fourni contient l'information la plus complète sur la façon de faire ce qui est requis.

0
ajouté édité
Vues: 7
Si vous pensez que ce message a reçu une réponse, veuillez marquer comme réponse.
ajouté l'auteur Anonymous User, source

8 Réponses

À côté du journal ULS mentionné par Jaap, vous trouverez également des informations pertinentes dans le journal des événements "Application".

Vous pouvez trouver l'Observateur d'événements dans les Outils d'administration ou écrire simplement eventvwr.exe dans Exécuter.

Il y a aussi beaucoup de projets sur Codeplex qui sont utiles pour gérer le fichier journal ULS. Il suffit de chercher ULS sur Codeplex.com

Enfin, je peux vous recommander d'utiliser SPTraceView par Hristo Pavlov, qui vous donne les événements ULS tels qu'ils se produisent en temps réel. Particulièrement puissant lors du débogage de production. Il peut également être combiné avec DebugView .

EDIT: A good blog post on all the logs of SharePoint: How do i troubleshoot SharePoint? So many logs!

8
ajouté
Service de journalisation unifiée
ajouté l'auteur Anonymous User, source
Les journaux ULS sont des journaux de trace dans lesquels SharePoint écrit des données lors de l'exécution de ses API. Vous pouvez définir individuellement des niveaux de trace pour les ULS et les journaux d'événements pour différentes catégories dans CA> Opérations> Enregistrement des diagnostics. Sachez cependant que cela peut affecter à la fois les performances et le stockage si vous définissez des niveaux de journalisation trop élevés. Dans le cas de débogage d'un problème, vous pouvez les définir sur Verbose et les remettre à Medium après. En savoir plus:
ajouté l'auteur Anonymous User, source
ULS est court pour?
ajouté l'auteur engtech, source
Qu'est-ce que Unified Logging Service? Quelque chose de spécifique à SharePoint Server? Avez-vous d'autres documents à lire?
ajouté l'auteur engtech, source

Les journaux ULS sont générés par le serveur dans le dossier suivant:

C: \ Program Files \ Fichiers communs \ Microsoft Shared \ Extensions du serveur Web \ 12 \ LOGS

Vous pouvez modifier le niveau de journalisation via Admin Central, par ex. plus verbeux ou moins verbeux.

C'est une bonne idée de ajouter une barre d'outils "12 ruche" à la barre de démarrage pour accéder facilement aux journaux et à tout le reste de SharePoint résidant dans la ruche 12.

Il existe également des outils open source qui vous permettent d'afficher les journaux via une interface conviviale. Un exemple est Lecteur de fichier journal WSS/MOSS , développé par Stuart Starrs .

4
ajouté
C'est aussi une bonne idée de déplacer ces fichiers journaux loin de C: et dans votre lecteur de données :-) Vous pouvez déterminer à la fois les diagnostics et les chemins du fichier journal de suivi dans l'Administration centrale
ajouté l'auteur Anonymous User, source
c'est parce que le journal de suivi est continuellement écrit par sharepoint
ajouté l'auteur Anonymous User, source
Lorsque je regarde le dernier fichier journal, j'ai rencontré une erreur - le fichier est en cours d'utilisation par un autre processus. Des idées ce qui ne va pas?
ajouté l'auteur engtech, source
MS a également publié son outil ULS Viewer ici code.msdn.microsoft.com/ULSViewer
ajouté l'auteur Alex Angas, source
@AlexAngas Ce lien pour ULS Viewer n'est plus bon. (5 ans plus tard, c'est ...)
ajouté l'auteur bgmCoder, source
@BGM Maintenant re-publié ici: microsoft.com/en- nous/download/details.aspx? id = 44020 . Bizarre timing ...
ajouté l'auteur Alex Angas, source
@AlexAngas Merci pour la mise à jour du lien!
ajouté l'auteur bgmCoder, source

"Le serveur a renvoyé une erreur non spécifique en essayant d'obtenir des données de la source de données.Vérifiez le format et le contenu de votre requête et réessayez.Si le problème persiste, contactez l'administrateur du serveur." error est une erreur de SharePoint Designer et vous ne verrez probablement rien dans les journaux à ce sujet.

If you are only doing Data View -> Insert Dataview and getting this error, I'd be surprised. Are you doing anything else before you get the error? It could be that you are trying to insert the Dataview in a part of the page where it cannot be, such as inside another control.

1
ajouté
vous devriez probablement créer un nouveau sujet si vous voulez une réponse à ce que l'erreur pourrait être. La question portait sur la journalisation en général.
ajouté l'auteur Anonymous User, source
Salut Marc, je suis en train de glisser Dataview dans une page de mise en page WebPart (je crée une nouvelle page webpart vierge basée sur la mise en page). Pourrais-je faire glisser Dataview dans un WebPart?
ajouté l'auteur engtech, source
J'ai obtenu celui-ci dans de tels cas - implique généralement l'ajout d'un champ de recherche à une liste qui a déjà beaucoup d'éléments et de flux de travail et d'autres choses amusantes - il y a une combinaison étrange que SP n'aime pas. Retrait des éléments de test définit tout droit dans le monde.
ajouté l'auteur ebruchez, source

Est-ce une application console ou une application Windows Forms? S'il s'agit d'une application de console .NET 1.1, c'est malheureusement, par conception - c'est confirmé par un développeur MSFT dans le deuxième article de blog que vous avez référencé :

BTW, sur ma machine 1.1 l'exemple de MSDN a la sortie attendue; c'est juste que la deuxième ligne n'apparaît qu'après que vous avez attaché un débogueur (ou pas). Dans v2, nous avons inversé les choses afin que l'événement UnhandledException se déclenche avant que le débogueur ne se connecte, ce qui semble être ce que la plupart des gens attendent.

On dirait que .NET 2.0 fait mieux (Dieu merci), mais honnêtement, je n'ai jamais eu le temps de revenir en arrière et vérifier.

0
ajouté

Oh, dans Windows Forms, vous devriez pouvoir le faire fonctionner. La seule chose que vous devez faire attention est que les choses se passent sur différents sujets.

J'ai un ancien article de Code Project ici qui devrait aider:

Manipulation d'exception conviviale

0
ajouté

C'est une application Windows Forms. Les exceptions qui sont interceptées par Application.ThreadException fonctionnent correctement, et je n'obtiens pas la boîte d'exception .NET ( OK pour terminer, Annuler pour déboguer? avec ça??).

Je recevais des exceptions qui n'étaient pas interceptées par cela et finissais par aller à l'événement AppDomain.UnhandledException qui causait des problèmes. Je pense que j'ai attrapé la plupart de ces exceptions, et je les affiche maintenant dans notre belle boîte d'erreur.

Donc je dois juste espérer qu'il n'y a pas d'autres circonstances qui pourraient empêcher les exceptions d'être interceptées par le gestionnaire Application.ThreadException.

0
ajouté

AppDomain.UnhandledException is an event, not a global exception handler. This means, by the time it is raised, your application is already on its way down the drain, and there is nothing you can do about it, except for doing cleanup and error logging.

Ce qui s'est passé dans les coulisses est la suivante: Le framework a détecté l'exception, a remonté la pile des appels jusqu'au sommet, n'a trouvé aucun handler récupérant de l'erreur, donc n'a pas pu déterminer s'il était sûr de continuer l'exécution. Ainsi, il a commencé la séquence d'arrêt, et a lancé cet événement par courtoisie afin que vous puissiez rendre hommage à votre processus déjà condamné. Cela se produit lorsqu'une exception n'est pas gérée dans le thread principal.

Il n'y a pas de solution unique à ce genre d'erreur. Vous devez placer un vrai gestionnaire d'exceptions (un bloc catch) en amont de tous les endroits où cette erreur se produit et le transmettre à (par exemple) une méthode / classe de gestionnaire global qui déterminera s'il est sûr de simplement signaler et continuer, basé sur type d'exception et / ou contenu.

Edit: Il est possible de désactiver (= hack) le mécanisme de rapport d'erreurs intégré à Windows, de sorte que la boîte de dialogue obligatoire "Crash and Burn" ne s'affiche pas lorsque votre application tombe en panne. Cependant, cela devient efficace pour toutes les applications du système, pas seulement les vôtres.

0
ajouté

Le comportement d'exception non gérée dans une application Windows Forms .NET 1.x dépend de:

  • Le type de thread qui a lancé l'exception
  • Si cela s'est produit pendant le traitement du message de la fenêtre
  • Si un débogueur était attaché au processus
  • Le paramètre de registre DbgJitDebugLaunchSetting
  • L'indicateur jitDebugging dans App.Config
  • Si vous avez ignoré le gestionnaire d'exceptions de Windows Forms
  • Si vous avez géré l'événement d'exception du CLR
  • La phase de la lune

Le comportement par défaut des exceptions non gérées est:

  • Si l'exception se produit sur le thread principal lors du pompage des messages de la fenêtre, elle est interceptée par le gestionnaire d'exceptions de Windows Forms.
  • Si l'exception se produit sur le thread principal lors du pompage des messages de la fenêtre, il met fin au processus de l'application sauf s'il est intercepté par le gestionnaire d'exceptions de Windows Forms.
  • Si l'exception se produit sur un thread manuel, threadpool ou finalizer, il est avalé par le CLR.

Les points de contact pour une exception non gérée sont:

  • Gestionnaire d'exceptions Windows Forms.
  • Commutateur de registre JIT-debug DbgJitDebugLaunchSetting.
  • Événement d'exception non géré CLR.

La gestion des exceptions intégrée à Windows Form effectue les opérations suivantes par défaut:

  • Catches an unhandled exception when:
    • exception is on main thread and no debugger attached.
    • exception occurs during window message processing.
    • jitDebugging = false in App.Config.
  • Shows dialog to user and prevents app termination.

Vous pouvez désactiver ce dernier comportement en définissant jitDebugging = true dans App.Config. Mais rappelez-vous que cela peut être votre dernière chance d'arrêter la fin de l'application. L'étape suivante pour intercepter une exception non gérée consiste donc à enregistrer l'événement Application.ThreadException, par exemple:

Application.ThreadException += new
Threading.ThreadExceptionHandler(CatchFormsExceptions);

Notez le paramètre de registre DbgJitDebugLaunchSetting sous HKEY_LOCAL_MACHINE \ Software.NetFramework. Cela a l'une des trois valeurs dont je suis conscient:

  • 0: affiche la boîte de dialogue de l'utilisateur demandant "debug ou terminate".
  • 1: laisse passer l'exception pour que CLR s'en occupe.
  • 2: lance le débogueur spécifié dans la clé de registre DbgManagedDebugger.

Dans Visual Studio, allez dans le menu Outils ? Options ? Débogage ? JIT pour mettre cette clé à 0 ou 2. Mais la meilleure valeur est généralement 1 sur la machine d'un utilisateur final. Notez que cette clé de Registre est activée avant l'événement d'exception CLR non géré.

Ce dernier événement est votre dernière chance de consigner une exception non gérée. Il est déclenché avant que vos blocs Last soient exécutés. Vous pouvez intercepter cet événement comme suit:

AppDomain.CurrentDomain.UnhandledException += new
System.UnhandledExceptionEventHandler(CatchClrExceptions);
0
ajouté