Masquer les messages d'erreur Windows AU SECOURS !!!!
gerbito
Messages postés39Date d'inscriptionmardi 14 décembre 2004StatutMembreDernière intervention20 octobre 2015
-
4 juin 2008 à 18:04
gerbito
Messages postés39Date d'inscriptionmardi 14 décembre 2004StatutMembreDernière intervention20 octobre 2015
-
5 juin 2008 à 14:55
Bonjour,
Quelqu'un connaîtraît-il une méthode valable pour masquer les messages d'erreur Windows ?
En effet j'ai une appli développée en C# dont le graphisme est pollué par l'apparition d'un message d'erreur
"svchost.exe Application Error L'instruction à l'adresse 0x77c43dbd référence l'adresse 0x90909090 la mémoire ne peut pas être écrite"
Après avoir passé 2 semaines à essayer de résoudre cette erreur en vain, le seul recours qui me reste est d'essayer de la mettre "sous le tapis", et pour cela il faudrait éviter que cette boîte grise n'apparaisse DEVANT le formulaire de mon appli.
J'ai mis la TopMost de la form à vrai, je l'affiche avec la méthode ShowDialog et pourtant rien n'y fait.
Ce serait excellent si quelqu'un connaissait la réponse...
Liverion
Messages postés296Date d'inscriptionmardi 22 avril 2008StatutMembreDernière intervention18 août 2008 5 juin 2008 à 10:07
Salut,
Euh pour ma part ca fait très moche de camoufler une fenetre d'erreur ^^
En plus je crois que les fenetres d'erreur sont modales non ? Tu pourras pas utiliser ta form tant que tu n'auras pas cliquer sur l'erreur.
Sinon tu peux toujours afficher ton code, peut etre que des personnes pourront t'aider à resoudre ton problème.
Bonne chance ;)
~~~~~~~~~~
Les trois lois de Codes-Sources :
1) Tu lis et respecte le reglement
2) Tu pense a valider si une reponse apportée a ton probleme t'a aidé
3) Si tu ne respecte pas les 2 premières ....TU SORS !!!
~~~~~~~~
gerbito
Messages postés39Date d'inscriptionmardi 14 décembre 2004StatutMembreDernière intervention20 octobre 2015 5 juin 2008 à 13:31
Bonjour,
Il est clair que ce n'est pas très joli de masquer des fenêtres d'erreur, mais si tu as une meilleure solution, elle est bienvenue. L'erreur ne vient pas de mon appli mais de svchost, il m'est impossible de la détecter avec des gestionnaires d'exception, cela fait plus de 2 semaines que je m'acharne à déterminer la cause de cette erreur, et il ne reste plus de temps à passer dessus, donc sachant que l'erreur ne bloque pas le fonctionnement de mon appli tant qu'on ne clique pas sur le "OK" de la boîte grise, j'essaie de parer au plus pressé et donc de la faire passer "sous le tapis".
J'avais déjà posé une question dans une autre partie du forum à propos de ce problème. Il m'avait alors été répondu que le problème pouvait venir de l'utilistion par une DLL native d'un pointeur transmis par mon appli C# et supprimé par le ramasse-miettes, ou d'une mauvaise utilisation du Marshal pour formater les variables à transmettre. Mon appli utilise en effet l'API Ras.
Plus loin la classe que j'ai amélioré pour empêcher le ramasse-miettes de buter mes variables dans mon dos. C'est fait un peu à l'arrache, tout est dans la même méthode (située à la fin) qui fait tout et dont les dernières instructions ordonnent au ramasse-miettes de ne pas toucher à mes variables. Auparavant j'utilisais une classe avec une connexion Ras asynchrone et le passage d'un délégué de traitement des messages de statut de la connexion Ras, mais le seul moyen d'utiliser GC.KeepAlive c'était à l'intérieur d'une même méthode, voilà pourquoi j'ai tout mis dans la même méthode, avec des principes de codage qui pourront paraître sales (goto...). L'interface MBTClient est dérivée par mon composant qui contient le Socket Tcp. Malgré tous mes efforts, ca plante encore.
Pour décrire sommairement l'appli, c'est une appli dont l'affichage graphique dépend de données reçues en permanence d'un serveur via une liaison par modem GPRS et protocole Tcp. L'appli doit pouvoir tourner sans discontinuer pendant plusieurs mois. Pour éviter ce problème de svchost, j'ai pensé aussi à :
-> injecter une méthode du style : void faitRien() {;} en lieu et place de la fonction système qui affiche les boîte grise (ca doit etre faisable)
->mettre svchost sous surveillance (apparement pas possible)
->Abandonner l'API Ras et utiliser un client Port série pour causer directement au modem et reproduire le protocole Tcp dans ce client port série (j'avais déjà commencé à m'y intéresser, mais pas assez de temps pour le faire)
Mais si quelqu'un pense pouvoir m'aider en regardant mon code utilisant l'API Ras :
Nikoui
Messages postés794Date d'inscriptionvendredi 24 septembre 2004StatutMembreDernière intervention19 août 200813 5 juin 2008 à 13:48
Je ne suis pas sur du tout que tu puisses arriver à masquer les boites d'erreur modale (et ce n'est pas une vrai solution à ton problème de toute façon).
Dans ton cas (pas simple), ce que je ferai (dans l'ordre):
- Etre sur que le problème ne vient pas de ton code
- Si le problème vient d'une librairie tierce, voir avec les personnes à l'origine de cette librairie (est ce un bug connu ? est il possible/prévu de le corriger ? quand? etc)
- Si pas de support de fournit sur cette librairie : est ce qu'il est possible d'en récupérer les sources et corriger toi même le bug ?
- Si tout ça n'est pas possible : changer de librairie
- Si pas de librairie équivalente -> faire autrement ou en développer une soi même.
Masquer l'erreur ne peut être (à mon avis) qu'une solution temporaire...
<hr size="2" width="100%" />
Working as designed
www.nikoui.fr
gerbito
Messages postés39Date d'inscriptionmardi 14 décembre 2004StatutMembreDernière intervention20 octobre 2015 5 juin 2008 à 14:55
Tout d'abord, merci aux personnes qui m'ont répondu.
J'ai longuement vérifié le code utilisé précédemment qui comme je le disais était plus "propre" avec utilisation d'une vrai classe, des méthodes plus petites, des délégués de rappel.
Supposant que le problème venait de la suppression par le GC de pointeurs transmis à la dll Ras, j'ai fait, dans l'ordre, les modifs de code suivantes :
->Tentative de passer toutes les variables transmises à l'API en statique dans la classe alors utilisée : aucun effet
->Tentative de créer un projet en C++ natif pour utiliser la dll Ras, avec un autre projet en C++ .Net managé utilisable directement depuis C# et utilisant cette ma dll native : Peine perdue, dans mon projet natif j'incluais pourtant le ras.h et utilisais directement ses structures, mais la méthode RasDial me renvoyait une erreur au motif que la taile de la structure déclarée dans ras.h était mauvaise, apparement à cause d'un #ifdef WINVER >= 0x500 qui rajoute 2 variables superflues dans la structure RasDialParams. J'ai alors essayé de mettre "#define WINVER 0x4ee" avant l'inclusion de ras.h, mais je me ramassais une erreur de compilation à cause de la structure jugée du coup trop petite. J'ai dû renoncer à cette option.
->Enfin, j'ai refait le code tel que vous pouvez le voir, tout dans une seule méthode encapsulée dans un thread, connexion synchrone sans délégué essayée 5000 fois avant de déclarer la connexion inutilisable, et utilisation de la méthode GC.KeepAlive sur toutes les variables transmises à la dll interdisant
leur ramassage par le GC depuis le début de la méthode jusqu'à l'appel de cette méthode KeepAlive (enfin c'est ce qui est dit dans msdn). Résultat : idem que précédemment, erreur dans svchost.exe.
Je me suis documenté sur l'API Ras (c'est pas facile de trouver de la doc francophone sur le sujet), le PInvoke, le Marshall de structures. J'ai appliqué toutes les recommandations que j'ai pu trouver à ce propos, pour chaque fois un résultat inchangé.
Les sources de l'API Ras sont apparemment indisponibles, donc aucun moyen de savoir ce qui se trame derrière tout ceci, à moins de pouvoir décompiler ce truc, mais de toutes façons je n'y connais rien en assembleur.
Sinon, ce qui me pousse à incriminer l'API Ras dans l'apparition de cette erreur, c'est le fait que svchost s'occuppe apparemment des connexions réseau sur un ordi, ainsi que de l'utilisation de dll. Toutes les autres libraries que j'utilise sont intégrées à mon projet, elles ont été codées en C#, blindées de try..catch, et elles ont été testées et retestées par d'autres développeurs.
Lorsque je me suis documenté sur les erreurs du même type que la mienne, on m'a parlé d'un virus de type "Blast", ou de problèmes récurrents dans Outlook ou Internet Explorer. Mais rien qui ne puisse me faire avancer, l'image XPe que j'utilise sur la cible ou va tourner mon appli est garantie sans virus. Peut-être IE et Outlook utilisent-ils l'API Ras...
L'erreur se produit au bout d'un temps d'éxécution qui varie de 20 mn à 22 h. A chaque fois qu'elle se produit Windows me signale ensuite que la connexion GPRS vient d'être établie, alors que mon programme n'avait rien demandé au préalable (toutes les actions de mon appli sont tracées, et je n'ai pas trouvé la survenue de l'évènement de déconnexion ni la tentative de reconnexion dans le fichier de trace dans les minutes qui précèdent l'apparition de l'erreur).
Peut-être que Windows surveille lui aussi cette connexion, il me faudrait alors trouver un moyen de l'en empêcher. Je dois préciser que ma connexion GPRS est déclarée au préalable dans les connexions réseau du panneau de configuration, et utilise un modem que j'ai configuré via ce même panneau de configuration. Il y a sans doute un moyen de la créer de toutes pièces par l'API Ras, mais je ne le connais pas.
Apparemment l'API Ras est le seul moyen de manier des connexions réseau, si quelqu'un en connaît un autre, je ne demande que cela.
Sinon, l'option "en développer une soi-même" est une très bonne idée que j'aimerais beaucoup appliquer si j'en avais le temps. Au moins jze pourrais garder une totale maîtrise du code éxécuté au lieu de passer des pointeurs marshallés à des API en croisant les doigts pour que ca marche. J'y avais en pensé car je souhaitais développer un client port-série (j'utilise un modem externe relié par port COM) qui dans un premier temps enverrait les commande AT, (AT+CGDCONT=1,"IP","[mon APN]", etc...) et ensuite discuterai directement avec le serveur. J'avais télécharger un espion de port série voir voir les trames qui passait. Pour les commandes AT ca allait, mais pour la discussion avec le serveur, il le faudrait connaître le protocole Tcp, ses checksum, les réponses, l'en-tête. J'avais posé une demande sur ce forum à ce sujet mais personne n'y a répondu.