Application C # WPF avec les MahApp qui ne s’affichent pas dans Windows 2008

Donc, c’est étrange.

J’ai créé une application WPF à l’aide de MahApps pour l’interface graphique. Jusqu’à présent, mes tests indiquent que l’application fonctionne correctement sur plusieurs machines différentes. Bien sûr, ce n’est pas le cas sur la machine du client.

Le client utilise les services Terminal Server et Windows Server 2008R2. Plusieurs utilisateurs peuvent être connectés à leur propre version du serveur à tout moment. L’application démarre bien une ou deux fois, mais après un jour ou deux, elle ne s’ouvre plus.

L’application n’apparaît pas dans l’onglet Application du Gestionnaire des tâches, mais son processus peut être vu comme s’exécutant dans l’onglet Processus du Gestionnaire des tâches.

Pour être honnête, je suis complètement déconcerté. J’ai jeté un coup d’œil au journal du gestionnaire d’événements et je n’ai rien trouvé qui puisse indiquer un problème. (Bien sûr, j’ai peut-être manqué quelque chose). J’ai vu une autre question SO suggérant de désactiver l’accélération matérielle, mais je ne suis pas si cela pourrait aider.

Toutes les idées seraient grandement appréciées.

EDIT: Je pensais que je pourrais mentionner la seule chose qui aide est de redémarrer la machine cliente.

EDIT: Je pense avoir isolé le problème de l’intégration avec Twain (cela aurait probablement dû être mentionné comme un autre facteur possible). Je pense que la bibliothèque Twain (code non géré) cale en quelque sorte sans renvoyer d’erreur. Sa désactivation a “résolu” le problème.

Cela concerne en quelque sorte les configurations Twain et multi-sessions. J’en suis presque sûr.

Vous pouvez d’abord parsingr la chaîne d’attente dans le moniteur de ressources Windows pour vérifier si le processus attend des ressources. (Vous pouvez trouver plus d’informations sur la chaîne d’attente ici ou ici .)

Si vous ne trouvez pas de suspects viables, vous pouvez créer un vidage de mémoire du processus suspendu et parsingr les stacks d’appels. Si vous ne savez pas comment en créer un, vous pouvez lire à ce sujet ici . Si vous souhaitez utiliser le Gestionnaire de tâches Windows et que votre système d’exploitation est 64 bits, veuillez noter que vous devez utiliser le même bitness que le Gestionnaire des tâches de l’application.

C’est-à-dire que si votre application est 64 bits, vous devez utiliser C:\Windows\System32\taskmgr.exe et si elle est 32 bits, vous devez utiliser C:\Windows\SysWOW64\taskmgr.exe . Si vous oubliez cette étape importante, vous obtiendrez simplement une décharge inutilisable pleine de charabia.

Après avoir obtenu le vidage de la mémoire, vous pouvez soit le charger dans WinDbg (en utilisant le même bitness que l’application) ou Visual Studio (mieux utiliser 2015 ou plus tard) et parsingr les stacks d’appels de tous les threads en cours d’exécution.

Vous pouvez télécharger WinDbg ici et lire la configuration WinDbg nécessaire ici . Pour la liste de tous les threads, vous devez utiliser cette commande SOS.

Si vous avez besoin d’aide pour charger des vidages de mémoire dans Visual Studio, vous trouverez plus d’informations ici .

Une fois que vous avez regardé les stacks d’appels, vous trouvez certainement la réponse à ce qui attend sur quelles ressources et empêche ainsi l’arrêt ou le démarrage de l’application. Il peut s’agir d’une impasse classique ou d’une ressource externe telle que l’écriture / lecture d’un fichier ou toute autre attente sans délai, comme accéder à une firebase database ou à une URL inaccessible pour le moment. Et bien sûr, il ne peut s’agir que d’une boucle infinie – s’il ne consum pas beaucoup de CPU, peut-être avec une sorte de DoEvents entre les deux.

Et last but not least: Si vous êtes vraiment intéressé par ce qui peut être analysé si une application se bloque, vous pouvez lire un exemple d’parsing faite par le génial Mark Russinovich ici .