Discussion :

[ram-0000]

La journalisation dans le monde Microsoft, découvrez l'API EventLog

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.

Vos commentaires sont les bienvenus !

[jmnicolas]

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.

[ram-0000]

Très bel article...

Merci

...Ca me semble complexe et lourd à mettre en œuvre pour des petits et moyens projets, mais je peux me tromper.

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.

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 ).

[ILP]

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 .
Pour les déboguages, ça sera plus simple.

[Melem]

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 ?

[ILP]

@Melem : Je pense avoir compris l'intérêt de la journalisation . 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 .

[jmad59]

Bonjour,
je n'arrive pas à télécharger le project sur le lien proposé. (Erreur: File Not Found).

[ram-0000]

je n'arrive pas à télécharger le project sur le lien proposé. (Erreur: File Not Found).

Désolé, c'est réparé maintenant

[stoffy28]

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#define EVENT_ID_1  ((DWORD)0x200001002L)

va devenir

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Private Const EVENT_ID_1 as Long = &H200001002L

C’est cette valeur qui doit être fournie aux méthodes WriteEvent de la classe EventLog.

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#define CAT_ID_1  ((WORD)0x000000001L)

. 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’.
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

[ram-0000]

Merci pour ce retour d'information

[stoffy28]

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