Version imprimable
La journalisation dans le monde Microsoft, découvrez l'API EventLog
Vos commentaires sont les bienvenus !Citation:
Ce document a pour but de présenter l'API Microsoft EventLog de journalisation dans l'environnement Microsoft Windows. Il présente aussi deux exemples écrits en C, un programme de génération de messages EventLog et un programme de récupération des messages EventLog.
Très bel article, une seule remarque : tu ne précises pas à quel type d'application ce genre de procédé est utilisé.
Ca me semble complexe et lourd à mettre en œuvre pour des petits et moyens projets, mais je peux me tromper.
Merci :oops:Citation:
Envoyé par jmnicolas
Un des buts de EventLog (mis à part le besoin de journaliser) est de fournir des messages EventLog localisés (comprendre, dans une langue donnée). Tu as un peu raison sur la taille du projet car quand on commence à parler de localisation, ce n'est déjà plus un petit projet.Citation:
Envoyé par jmnicolas
Ceci dit, la mécanique à mettre en place n'est pas très complexe (même pour un petit projet) une fois que le squelette fonctionne (ou alors j'ai loupé mon tuto :P).
Bonne idée l'utilisation de la journalisation de Windows. Je pense que je vais utiliser ça dans mes futurs projets plutôt que faire des "dump" dans des fichiers temporaires :mrgreen:.
Pour les déboguages, ça sera plus simple.
Alors tu n'as pas bien compris l'intérêt de la journalisation. La journalisation peut aider dans le débogage des erreurs imprévues, c'est-à-dire qu'elle est utilisée dans des applications suppossées "sûres", c'est-à-dire déjà testées, etc. Si t'es en phase de développement, il est plus simple et plus efficace d'utiliser les outils de débogage de ton ennvironnement de Développement. Enfin, la journalisation ne sert pas non plus qu'au débogage (ce n'est même pas son principal intérêt). Pourquoi journaliser ?
@Melem : Je pense avoir compris l'intérêt de la journalisation :koi:. Lors du développement, j'utilise bien le mode débogage de l'IDE. Mais pour les problèmes sur les applications livrés chez les clients c'est bien de savoir ce qu'il c'est passé. S'il s'agit d'une erreur dans le logiciel ou une erreur dans l'utilisation du logiciel ;).
je viens de le lire (en diagonale raccourcie :)) mais il répondait Exactement à ce que je cherchais. merci msieur!! ;)
j'aurai jamais vu l'utilité d'un tel article et pourtant là il me sauve la vie :aie:
Avec plaisir !!Citation:
Envoyé par Louis-Guillaume Morand
Bonjour,
Tres bon article, juste une petite chose, quand tu dis:
Je trouve cela un peu reducteur, il n'est certes pas possible de l'arreter mais il est possible de l'empecher de demarrer (ou de le mettre en demarrage manuelle si on ne regarde pas les log) et ce sans pauser de soucis majeur au niveau de l'OS :ccool:Code:Jusqu'à Windows XP, il n'était pas possible d'arrêter ce sous-système.
Sinon, exellent article.
Je l'avoue, je n'ai jamais testé de l'empêcher de démarrer.Citation:
Envoyé par sloshy
Ma remarque tient juste du fait que j'ai vu qu'il était impossible de l'arrêter (avec le gestionnaire de services) quand il était démarré.
Tu es sûr de ton coup lorsque tu dis qu'il est possible d'empêcher son démarrage ? Je n'ai pas de XP sous la main et je suis éventuellement prêt à modifier le tuto pour ajouter cette précision mais j'ai besoin d'une certitude et pas d'une idée ou d'un "il me semble".
C'est une quasi certitude, je verifie et te dis quoi des que possible :)
Super article !... riche et complet !.. bravo ! :ccool:
Je cherchais à comprendre le fonctionnement de cette journalisation pour un projet de centralisation de logs, voila qui est parfait.
Je me permet de confirmer qu'il est possible de désactivé ce service au moyen du menu déroulant.Citation:
Envoyé par sloshy
La désactivation ne sera effective qu'après un redémarrage du poste.
Je vous ai joint une copie d'écran avec affichage du service désactivé après un redémarrage.
OK, je mettrai l'article à jour ce soir sur ce point.
:merci: pour le retour
Ceci dit, c'est possible d'arrêter le service (enfin, de ne pas le démarrer) mais Microsoft ne le recommande pas.
[Edit] Article mis à jour
Bonjour,
je n'arrive pas à télécharger le project sur le lien proposé. (Erreur: File Not Found).
Désolé, c'est réparé maintenant :PCitation:
Envoyé par jmad59
Bonjour
tout d'abord bravo pour votre tutoriel, car c'est le plus complet que j'ai pu trouver sur le web, et de surcroit en francais.
Toutefois, je me permets de faire les commentaires ou compléments suivants dans le cas où la journalisation se fait depuis .NET :
1) pour que les caractères accentués contenus dans les textes des évènements et des catégories (ceux qui sont dans les fichiers .mc) soient correctement affichés dans l'event viewer :
- il n’y a pas besoin d'Unicode pour ça, l'ANSI suffit ; le fichier .mc lui-même doit être encodé en ANSI.
- il faut utiliser les options -a ET -A pour la commande mc.exe (par défaut c'est -U -pour Unicode - et les caractères accentués n'apparaissent pas ;
2) les ID d’évènements et de catégories sont à récupérer dans les fichiers .h qui sont générés lors de la compilation du fichier .mc.
Il faut traduire les définitions comme suit :
va devenirCode:#define EVENT_ID_1 ((DWORD)0x200001002L)
C’est cette valeur qui doit être fournie aux méthodes WriteEvent de la classe EventLog.Code:Private Const EVENT_ID_1 as Long = &H200001002L
3) Pour les catégories, il y a quelque chose que je ne comprends pas :
Les API telles que ‘ReportEvent’, de même que les méthodes de la classe EventLog, prennent un entier 16 bits en argument pour l’ID de catégorie.
Or si je mets l’instruction MessageIdTypeDef=WORD (et non DWORD) dans le fichier categories.mc, j’obtiens bien des définitions d’ID telles que :. Jusque là tout va bien, SAUF que si je mets l’option –c à la commande mc.exe, l’ID de catégorie devient 0x200000001L, et là ça n’est plus du tout un WORD, mais un DWORD, et il y a un dépassement de capacité lors des appels à ‘ReportEvent’ ou à ‘EventLog.WriteEvent’.Code:#define CAT_ID_1 ((WORD)0x000000001L)
Donc je ne comprends pas pourquoi on pourrait utiliser le ‘Customer bit’ pour les messages, et non pour les catégories.
4) en .NET il n'y a pas d'équivalent à Success pour la Severity, il n'y a que Information.
5) je ne comprends pas l’intérêt de spécifier l’option « Severity= » dans les fichiers .mc, puisque lors de l’inscription d’un évènement dans le journal avec ‘EventLog.WriteEvent’ :
- soit on ne spécifie pas de niveau de « sévérité », auquel cas c’est ‘Information’ qui est mis par défaut, et absolument pas la valeur spécifie pour « Severity= » dans le fichier .mc ;
- soit on spécifie un niveau de « sévérité », auquel cas c’est cette valeur qui est utilisée, en REMPLACEMENT de la valeur spécifie pour « Severity= » dans le fichier .mc
6) idem pour l’option « Facility= »
Lors de l’appel aux méthodes de la classe EventLog :
- soit on utilise les versions statiques (Shared), auquel cas on ne spécifie pas de journal particulier, et l’évènement est inscrit dans la première source existante qui porte le nom voulu ;
- soit on utilise les méthodes d’instance, auquel cas il faut instancier la classe ‘EventLog’ en pointant sur un journal précis, et là aussi la valeur contenue dans « Facility= » est ignorée
A la condition de surmonter toutes ces petites difficultés, ça fonctionne nickel, même sous Windows 7.
Voilà, s’il me revient d’autres détails, je complèterai.
Hope this helps !
Chris
Merci pour ce retour d'information :ccool:
Bonjour
autres remarques :
- le point 3) de mon commentaire implique autre chose : il faut obligatoirement séparer les évènements et les catégories dans 2 fichiers .mc différents si on veut appliquer l'option -c pour l'un et pas pour l'autre.
- vous aurez obligatoirement besoin d'un administrateur système pour configurer les journaux : pour créer le journal si besoin, et pour créer les sources.
- l'emplacement où vous déposerez vos DLL est un peu le point faible de ce système ; en effet pour que l'Event Viewer affiche tout comme vous le voulez, il faut qu'il ait accès à vos DLL. Pour cela, il utilise l'algorithme de recherche documenté dans l'API LoadLibrary :
* 1ère solution : vous les mettez dans C:\windows\system32 (il faudra sûrement être administrateur là aussi)
* 2ème solution : vous les mettez dans un répertoire avec chemin absolu (ex: "D:\users\toto\DLL") mais il faut être sûr qu'elles ne changeront jamais d'emplacement, et que le système a les droits d'accès.
* 3ème solution : idem mais le chemin sera par exemple "%MonChemin%\DLL", il faudra créer la variable d'environnement MonChemin dans le système (être admin là aussi), et déclarer les valeurs EventMessageFile et CategoryMessageFile de type REG_EXPAND_SZ.
- je vois dans quasiment tous les exemples de code, que l'enregistrement des sources se fait à la volée. Mais il faut être administrateur pour ça ! Dans un environnement professionnel l'utilisateur n'a pas les droits admin, cette instruction ne peut pas être intégrée dans le code qui écrit les évènements.
Chris
@stoffy28: Severity et Facility ne sont-elles pas censées être liées à la valeur des constantes? (0x80000000 pour SEVERITY_ERROR et 0x00070000 pour FACILITY_WIN32 par exemple, comme pour les HRESULT)
le fait de spécifier Severity et/ou Facility dans le fichier .mc impacte en effet la valeur de l'event ID de message ou de catégorie.
(voir le détail du masque de codage de l'ID)
Cependant, fonctionnellement je ne vois pas l'impact qu'ont ces valeurs : rien n'empêche de loguer un évènement, depuis un programme .NET, ayant un ID déclaré avec Severity=Warning dans le fichier .mc, mais en spécifiant Severity=Error lors de l'appel à EventLog.WriteEvent.
Dans l'Event Viewer, lorsque vous visualiserez votre évènement, la sévérité sera bien "Error" et l'icône sera bien la croix rouge. Aucune trace de "Warning" n'apparait.
Stoffy28