Discussion :

[Laox23]

Bonjour,

Je poste ce message ici, car je ne sais pas dans quelle direction regarder pour corriger le problème (ce post n'est peut être pas dans le bon groupe ).

Explication :

Nous développons une application .Net Winform et depuis un petit moment un problème apparait aléatoirement. Le plantage fige totalement l'application et plus aucune intéraction n'est possible, mais sans que cela bloque Windows ou que s'affiche "le programme ne répond pas", ça réagit comme si l'application était devenue une image en fond, aucune interaction. Impossible de fermer l'application autrement qu'en tuant le processus.
Le problème se produit sur certain postes, mais il semblerait ne pas ce produire sur tous.

Le problème semble indépendant de la configuration (version de Windows, 32 ou 64 bits, ...).

Une manipulation semble néanmoins reproduire le problème très fréquemment :- Ouverture du programme.- Ouverture d'IE , navigation sur quelques pages.- Fermeture d'IE.- La le programme se fige.

J'ai regardé dans l'observateur d’événement Windows puis avec procmon, mais rien n'a attirer mon attention (il n'y a même rien aux heures où le problème survient)...

C'est là que mes connaissances sont à leurs limites, impossible de savoir quand a débuté le problème (entre 6 mois et 1 an) donc pas possible de faire un lien avec une modification du code.

Je ne sais pas dans quelle direction regarder pour continuer à creuser.

Si quelqu'un a une idée je suis preneur.


Merci.


Ps : Précision après recherche, dans le cas cité au dessus, si l'option supprimer l'historique de navigation après sortie n'est pas cochée, l'application ne plante pas.
L'application plante si manuellement j’exécute la commande "rundll30.exe inetcpl.cpl clearmytracksbyprocess 4351" qui supprime l'historique d'IE.

[micka132]

Peut etre un objet COM utilisé à la fois pas IE et par l'appli, et qui pour une raison étrange entre en conflit?

[DotNetYo]

Si l'application fige, il y a fort à parier que c'est le thread de la WinForm qui ne s'en sort pas...

Vérifie dans le programme, toutes les actions que tu fais dans le thread de la WinForm et qui ne concernent pas la WinForm (qui ne concernent pas : mise à jour de boutons, de texte, etc ...)
=> En fait toutes les actions d'IO ne concernant pas la gestion du rendu de la Winform.

Exemple d'action à éviter dans les threads de Winform : copie d'un fichier volumineux car cela fige très facilement la WinForm.

Vérifie donc à quel moment et comment fais-tu l'appel de rundll30.exe par exemple.

@+

[Laox23]

Bonjour et merci à vous deux.

Effectivement il doit y avoir un objet COM mais impossible (en tout cas je ne vois pas comment) de savoir lequel car l'application est quand même assez énorme (5 Go de code, avec solution framework perso, métier, outils, vues, install ...) .

C'est bien la le problème, je ne vois pas comment isoler une partie du code en particulier.

Par contre DotNetYo, je pense que si c'étain une exécution trop longue, il y aurait une erreur avec "écran blanc" et "Application ne répond pas" ? Mais ce n'est pas notre cas, l'application est juste "figée comme une image" .

[DotNetYo]

Par contre DotNetYo, je pense que si c'étain une exécution trop longue, il y aurait une erreur avec "écran blanc" et "Application ne répond pas" ? Mais ce n'est pas notre cas, l'application est juste "figée comme une image" .

Il peut arriver, même si tu n'as pas le message "L'application ne répond pas ", que ton application se fige.
Si tu me dis qu'elle se "comporte" comme un image, je pense vraiment qu'elle est figée et quelle attend qu'une opération synchrone se termine.
La difficulté effectivement, c'est de trouver l'endroit dans le code qui fige l'interface.

Ci dessous un exemple simple de code qui fige l'interface lors d'un clic sur un bouton nommé Button1 :

Code :

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

1
2
3
4
5
6
 
Public Class Form1
    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        System.Threading.Thread.Sleep(120000)
    End Sub
End Class

Utilise ce code dans un projet de test et vois si le comportement est identique à ce que tu constates avec ton programme.
Lance le via Visual Studio car sinon tu auras peut être du mal à killer le process.

Si le comportement est similaire, j'essaierai de trouver un moyen de t'aider à trouver là où ça bloque.

@+

:-)

[micka132]

Essaye de faire tourner cette classe
http://pastebin.com/55Kfftiv , qui je pense t'affiche la liste des objet COM déclarés.
Tu copies colles sur google les guid que tu trouves pour chercher le COM correspondant (000209FE-0000-0000-C000-000000000046 ==> word).
Normalement tu devrais avoirs quelques com en lien avec visual studio, les autres c'est peut etre des com qui viennent de ton appli.

[Laox23]

Il peut arriver, même si tu n'as pas le message "L'application ne répond pas ", que ton application se fige.
Si tu me dis qu'elle se "comporte" comme un image, je pense vraiment qu'elle est figée et quelle attend qu'une opération synchrone se termine.
La difficulté effectivement, c'est de trouver l'endroit dans le code qui fige l'interface.

Ci dessous un exemple simple de code qui fige l'interface lors d'un clic sur un bouton nommé Button1 :

Code :

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

1
2
3
4
5
6
 
Public Class Form1
    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        System.Threading.Thread.Sleep(120000)
    End Sub
End Class

Utilise ce code dans un projet de test et vois si le comportement est identique à ce que tu constates avec ton programme.
Lance le via Visual Studio car sinon tu auras peut être du mal à killer le process.

Si le comportement est similaire, j'essaierai de trouver un moyen de t'aider à trouver là où ça bloque.

@+

:-)

Bonjour,

Je ne pense pas que ce soit une exécution trop longue pour plusieurs raisons, dune part, si j'ajoute moi même un spleep trop long j'obtient un écran blanc ("l'application ne répond pas"), l'erreur ne survient jamais lors d'une action sur l'application mais toujours quand on utilise un logiciel tiers, et enfin, si je m'attache au processus (quand il est figé), je ne suis pas dans une méthode ou boucle mais dans le showDialog de ma fenêtre mère.

Je pense que cela vient d'un composant partagé qui pose problème, mais sans arriver à mettre le nez dessus.

Encore merci.

[Laox23]

Essaye de faire tourner cette classe
http://pastebin.com/55Kfftiv , qui je pense t'affiche la liste des objet COM déclarés.
Tu copies colles sur google les guid que tu trouves pour chercher le COM correspondant (000209FE-0000-0000-C000-000000000046 ==> word).
Normalement tu devrais avoirs quelques com en lien avec visual studio, les autres c'est peut etre des com qui viennent de ton appli.

Bonjour et merci,

Je ne sais pas si j'ai bien compris mais j'ai lancé le programme (ton lien) en lançant mon application et sans la lancer et j'obtient les même résultats ...

J'ai effectivement des COM pour visual et pour acces et une autre pour ATI, qui est inscrit en base de reg par ATICCCom64.reg, je vais éssayer de creuser sur ce point pour voir.


Merci

[Buzzak]

1.coupure réseau,
2.une erreur est produit et pas capter,
3.l'application est bourrer en mémoire