Outils de débogage WinRT

Pour faire suite à notre session TechDays, nous vous livrons tous nos outils et secrets :-)

Voici les premiers.

Débogage de l’activation des applications

L’exemple est le suivant : Votre application implémente le contrat de partage et plante seulement lorsqu’elle reçoit des données. Bien évidement, il va sans dire que votre application se comporte tout a fait correctement si elle est déjà lancée de façon traditionnelle.

La question posée est : Comment déboguer une application qui ne fonctionne pas (crashe) lors d’un lancement (c’est à dire une Activation) par contrat ou par protocole ?

Simplement en modifiant les propriétés du projet dans Visual Studio 2013 avec un clic droit sur le projet / Properties / Onglet Debug et en cochant

Do not launch, but debug my code when it starts

Initiez ensuite le débogage classiquement avec F5 ; Visual Studio ne lance pas l’application mais déboguera le processus dès que vous allez le lancer par quelque moyen que ce soit. Merci Visual Studio !

De la même façon, pour l’activation par protocole, activez cette option et lancez votre application par une des méthodes suivantes :

• IE moderne ou classique en tapant "VotreProtocole:Vos paramètres"

IE vous demande de confirmer le changement d’application :

L’application ActivationURI est ensuite lancée

• Touche Windows + R
• Dans la barre de l’explorateur Windows
• Par une application comme celle de Richard Clark - https://www.c2i.fr/c2iPackageExplorer 

Débogage des évènements Suspend/Resume/Terminate

Votre application plante sur du code s’exécutant lors du Suspend ou du Resume : Comment la déboguer ? En effet, si vous lancez l’application avec Visual Studio, nous n’aurons jamais de Suspend car une application WinRT déboguée n’est jamais suspendu !

Visual Studio à encore une fonctionnalité pour nous : la barre d’outils Debug Location

L’utiliser simule les évènements Suspend, Resume voire Suspend suivi par une Terminaison. Vous pouvez, de ce fait, déboguer votre code mais aussi vérifier que vous faites le nécessaire pour sauvegarder/charger l’état de votre application en cas de Terminaison.

L’exemple que nous avons montré pendant la session n’était pas une simple exception lors du Suspend. En effet, nous avons simulé un traitement long. Le plantage venait donc du dépassement du temps alloué pour l’exécution du Suspend.

D’ailleurs, pour mentionner ce temps maximum alloué, fut un temps où il était indiqué dans les Certification requirements des applications Windows Store (je me souviens de la version archivée 4.7 où le temps alloué était même de 2s !). Ce n’est plus le cas mais cela ne change pas le fait que ce temps est court et pour vous le prouver nous avons ajouté des traces dans le Suspend :

Pour les visualiser, Visual Studio nous les affiche dans la fenêtre Output lors du débogage :

Nous pouvons aussi les intercepter lorsque l’application est installée ou hors de Visual Studio avec DbgView.exe de SysInternals :

Cela confirme que notre code n’a que 5s pour travailler lors d’un Suspend. La recommandation est donc de mémoriser ce qui est important au fil de l’eau pour ne pas alourdir le traitement demandé lors d’un Suspend.

Vous allez me dire, oui ok, nous pouvons tester le Suspend hors Visual Studio car il suffit de basculer vers une autre application en plein écran et attendre que la notre soit suspendue. Mais comment simuler la Terminaison hors de Visual Studio ?

Nous avons ByeBye bien sùr ! Merci Christophe :-) L’outil se charge d’allouer le maximum de mémoire RAM afin de forcer Windows à s’alléger des applications Windows Store qui seraient en mode Suspend. Nous pouvons donc vérifier que notre application se comporte correctement lorsque nous la relançons après une Terminaison.

Il me restera à aborder dans mon prochain billet le débogage Mémoire et de dumps du Store.

Bon debug !

Sebastien.