Les nouvelles API de Windows Vista et Windows Serveur 2008 :

API Windows Error Reporting

Auteur : Eric Vernié, responsable technique en charge des relations développeurs

Document de référence

Révision 1.0

Table des matières

INTRODUCTION

WINDOWS ERROR REPORTING

UTILISATION DES API WINDOWS ERROR REPORTING

• Application de test
• Quelques mots sur le code fournis

CONCLUSION

Introduction

A la sortie de Windows Vista on vous a beaucoup parlé de l'expérience utilisateur, au travers de sa nouvelle interface graphique, au travers de la sécurité, ainsi qu'au travers de la version 3.0 du Framework .NET. Pléthore d'articles sur la possibilité de développer de nouvelles applications qui prennent en charge la 3D avec les API Windows Presentation Fundation (WPF), qui communique à l'aide de Windows Communication Fundation (WCF), ainsi que Windows Workflow Fundation (WF).

Mais ce n'est que la partie émergée de l'iceberg. En effet Windows Vista et Windows Serveur 2008 vont bien au delà, et apportent de grandes nouveautés, tant au niveau noyau, qu'au niveau API Win32 et COM et qui ne sont pas exposées directement par le Framework .NET.

Ces nouveautés, mettent en évidence 3 piliers fondamentaux de Windows Vista et de Windows Serveur 2008 :

• La robustesse
• La performance
• La sécurité

Dans mon 1er article, qui traitait des API Application Recovery & Restart, j'indiquais qu'elles allaient de pair avec l'infrastructure de Windows Error Reporting, mais sans rentrer dans le détail. Dans ce second article consacré à Windows Error Reporting nous irons une peu plus loin, en examinant les nouveautés qu'apportent Windows Vista et Windows 2008 Serveur.

Technologies utilisées:

C/C++

C++/CLI (C++ qui cible la plate-forme .NET)

Visual Studio 2008 Beta 2

(disponible en téléchargement ici : https://msdn2.microsoft.com/en-us/vstudio/aa700831.aspx)

Software development Kit Vista  : https://www.microsoft.com/downloads/details.aspx?familyid=FF6467E6-5BBA-4BF5-B562-9199BE864D29&mg_id=10114

Si vous n'avez pas installé Visual Studio 2008 Beta2, il vous faut le framework .NET 3.5 https://www.microsoft.com/downloads/details.aspx?FamilyID=1343d537-a62f-4a6e-9727-7791bf4cc2bd

Windows Error Reporting

WER est une fonctionnalité de Windows qui permet à l'utilisateur de notifier Microsoft via le site http://winqual.microsoft.com des erreurs de l'application, des erreurs du noyau etc. Microsoft, est en mesure alors d'utiliser cette fonctionnalité pour fournir des solutions à l'utilisateur. Les développeurs peuvent utiliser cette infrastructure et recevoir des informations afin d'améliorer leurs applications.

Figure 1, illustre Windows Error Reporting lorsque l'application TestRM.EXE plante.

Si l'utilisateur clique sur le lien "Check online for a solution and close the program", WER se connecte au portail Microsoft http://winqual.microsoft.com, pour essayer de trouver une solution au problème.

Si vous êtes éditeurs de logiciels, vous avez la possibilité d'ajouter votre application en adhérant (gratuitement) au site Winqual. Pour de plus amples informations rendez-vous à cette adresse https://www.microsoft.com/whdc/maintain/StartWER.mspx.

WER est une fonctionnalité déjà présente dans Windows XP et Windows Serveur 2003, mais elle a été améliorée avec Windows Vista et Windows Serveur 2008.

Alors quelles sont les améliorations ?

Pour les utilisateurs :

Problem Reports and Solutions: C'est le point central ou les utilisateurs peuvent interagir avec WER. L'utilisateur peut après coup vérifier les solutions, voir l'historique de leur rapport, voir les détails de leur rapport etc.

L'utilisateur peut configurer WER pour que les erreurs soient vérifiées automatiquement.

Si l'utilisateur n'est pas connecté à internet, ou qu'il ne souhaite pas envoyer de rapport directement, les problèmes sont mis dans une file d'attente.

Pour les développeurs :

Les développeurs peuvent utiliser les nouvelles API WerCreateReport, WerReportSummit pour personnaliser le rapport d'erreur et pas seulement pour des plantages d'applications.

Il est également possible de personnaliser l'interface de WER.

C'est ce que nous allons détailler dans les lignes qui suivent :

Utilisation des API Windows Error Reporting

Tout d'abord il faut inclure le fichier werapi.het se lier à la librairiewer.lib, toutes les fonctions, structures, constantes, sont reconnaissables, car elles commencent par le préfix Wer.

Par défaut, toutes les applications qui tournent sous vista, y-compris la votre sont assujetties à WER.

Bien qu'il soit possible de configurer WER via des clés de registre (cf aide en ligne ms-help://MS.MSDNQTR.v90.en/debug/base/wer_settings.htm), la fonction WerAddExcludedApplication vous permet de le faire par programmation.

Exemple :

HRESULT hr=::WerAddExcludedApplication (L"TestRM.EXE",false);if (FAILED(hr)){//Code omis pour plus de clarté}  

En excluant de WER votre application, les problèmes ne sont plus mis dans une file d'attente, et la boite de dialogue classique Figure 4, apparait ne vous demandant plus de vérifier la solution sur internet.

Pour revenir en arrière, utilisez la fonction WerRemoveExcludedApplication()

Il est également possible de modifier les messages de l'interface de WER comme à la Figure 5

1. Pour ce faire, il faut créer un handle de rapport avec la fonction WerReportCreate().
2. Ensuite on utilise le handle précédemment crée, avec la fonction WerReportSetUIOption()
   pour personnaliser la fenêtre de WER.
3. On soumet le rapport avec la fonctionWerReportSubmit()
4. Puis on ferme le handle de rapport avec la fonction WerReportCloseHandle()

Application de test

Avec cet article, vous retrouverez, un exemple qui met en œuvre ces API. Mais attention, il ne fonctionne que sous Windows Vista ou Windows Serveur 2008, car ces API ne sont pas disponibles avec les versions antérieures de Windows.

1. Démarrez l'application TestRM.EXE

   

    

2. Cochez la case "Exclure de Windows Error Reporting"

3. Appuyez sur le bouton "Appliquer"

4. Appuyez sur le bouton "Crash"

5. La boite de dialogue suivante doit apparaître

   

Il est également possible de redémarrer l'application en lui demandant de restaurer les données saisies.

1. Répétez les étapes 1 et 2 ci-dessus

   

2. Cochez les cases "Redémarrer" et "Callback"
   En cochant la case "Callback", on indique au système d'exécuter une méthode de rappel, qui à pour but essentiel de sauvegarder les données saisies. (cf. article Application Recovery & Restart pour de plus amples informations)

3. Appuyez sur le bouton "Appliquer"

4. Attention, pour que l'application redémarre il faut attendre au moins 60 Secondes

   

Modification de la fenêtre de Windows Error Reporting.

1. Exécutez le programme TestRM.EXE

2. Sans attendre appuyez sur le bouton "Crash 2 !!" La fenêtre suivante doit apparaître, j'y ai remplacé le texte de vérification sur internet et le texte de fermeture de l'application

   

3. Windows Error reporting, à mis en file d'attente l'erreur qui c'est produite. Dans mon exemple, j'ai ajouté au rapport, mes propres informations, comme le type d'erreur, ainsi que la pile des appels. En appuyant sur le bouton "View Problem details", vous y aurez accès.

   

4. Il est également possible de vérifier via Problem Reports and Solutions que Windows Error Reporting a mis en file d'attente le problème.

   

5. En double cliquant sur l'erreur, on obtient également le détail.

   

Quelques mots sur le code fournis :

Pour illustrer mon exemple, j'ai utilisé le langage de développement C++/CLI (qui cible la plate-forme .NET) pour son incroyable efficacité en termes d'interopérabilité entre le monde Natif et le Monde .NET. En effet c'est le seul langage qui permet de mixer dans le même source, à la fois du code .NET (C++/CLI) et du code natif, facilitant ainsi l'utilisation de ces API Win32.

L'interface a été développée à l'aide des Windows Form de la plateforme .NET.

Elle fait appel à une bibliothèque nommée HelperAPI, qui encapsule l'appel aux API de Windows Error Reporting ainsi que celle de l'API Application Recovery & Restart.

Cette bibliothèque est en charge entre autre de convertir les types .NET en type natif.

L'intérêt d'avoir mixer les deux mondes, est de démontrer que l'on peut très bien continuer à développer en C++ natif et améliorer son système, tout en l'intégrant facilement dans une nouvelle plate-forme comme .NET. Si vous avez des questions, n'hésitez pas à me contacter ericv@microsoft.com

Conclusion

Comme nous le venons de le voir, l'infrastructure Windows Error Reporting apporte une formidable opportunité aux développeurs d'ajouter à leurs applications plus de robustesse et de fournir ainsi à l'utilisateur une meilleur expérience en cas de crash. Si vous souhaitez en savoir plus sur l'aide que peux apporter Windows Error Reporting, rendez-vous à l'adresse https://www.microsoft.com/whdc/maintain/WERHelp.mspx

Dans les prochains articles, nous continuerons notre saga sur la robustesse d'application avec Windows Vista et Windows Serveur 2008, en illustrant les API suivantes :

• Kernel Transaction Manager (KTM) et NTFS Transactionnel (TxF) De la transaction ACID sur des fichiers
• Wait Chain Traversal Comment détecter les étreintes fatales (deadlock) dans son application ?
• Performances logs & Alert Comment collecter des informations utiles pour la résolution de problèmes ?

Haut de page