Discussion :

[ben_popcorn]

Bonjour,

J'ai un soucis plutôt gênant avec une solution développée sous VS2005 sur un PC biprocesseur, 2.5Go de RAM, bref une belle bête qui fait des jaloux dans ma boîte ^^
Depuis un mois, à quasiment chaque modification de code/génération, devenv.exe occupe 100% du processeur (en fait 50% d'un des 2 proc) sur un temps infini ... Je ne récupère pas la main sur Visual Studio. Par contre j'ai quand même la main sur le reste de mes applis (merci le biproc).
Ma solution est connectée à un serveur SourceSafe que j'ai mis en cause. Mais même une fois déconnecté du VSS le problème persiste.
Ce qui est étrange c'est que cette même solution fonctionne sur les autres postes des développeurs de cette solution...J'ai aussi essayé une déconnexion totale du réseau, mais ça ne change rien.
J'ai tenté enfin de passer sous Visual Studio 2008, mais c'est toujours pareil.

J'ai trouvé une solution de dépannage en récupérant un vieux portable mais c'est pas le pied...

quelqu'un a-t-il des idées/pistes à suivre/solutions ?

Merci d'avance
Ben

[lysiandad]

Bonjour,

Votre equipement devrait clairement vous permettre de developper dans des conditions tres confortables... Vous avez deja identifié le probleme, qui est donc une surconsommation du temps CPU sur cette solution particulière. C'était bien la première étape. Le coupable est donc probablement un composant (présent dans la toolbox VS ou non) ou une librairie / un package / un add-in activé lorsque vous ouvrez votre solution "tueuse".

La seconde étape, c'est d'utiliser vos connaissances/compétences en matière de debug sous Visual Studio, et en l'espèce, de savoir surveiller/auditer les threads, la pile d'appel, les modules chargés, etc, dans une application .NET : en êtes vous familier ?

Si c'est le cas, vous trouverez surement interessant de savoir que depuis Visual Studio 2005 au moins, vous avez la possibilité de faire du debug de Visual Studio et de ses designers, etc, à partir de... lui même.

Eh oui.

Cela s'appelle le mode "experimental". Je ne vais pas rentrer dans plus de details, mais VS peut donc fonctionner avec un arbre de clés (dans la base de registre) parallèle au mode standard, appelé le "experimental Hive".

La mise en oeuvre est assez simple.

Lisez d'abord ceci :

http://msdn.microsoft.com/en-us/libr...60(VS.80).aspx

Cela concerne VS 2005, mais on trouverez la meme chose pour VS 2008.

Installez donc le VS 2005 SDK, depuis ici :

http://www.microsoft.com/downloads/d...displaylang=en

(note : je vous recommande, si ce n'est deja fait, d'avoir applique le VS 2005 SP1 avant ; mais bon, le VS 2005 SDK fonctionne quand meme sans le SP1)

Ensuite, en ligne de commande (ou via un raccourci) lancer ceci (adaptez les chemins a votre installation) :

"D:\Program Files\Microsoft Visual Studio 2008 SDK\VisualStudioIntegration\Tools\Bin\VSRegEx.exe" GetOrig 9.0 Exp

Puis, en utilisant une solution "bidon" (avec un seul projet quelconque, même "vide", mais executable), positionner pour les proprietes de debug quelque chose proche de ce screenshot :

http://dotxml.brinkster.net/pour.dev..._exp_debug.jpg

"Start external program" doit indiquer le chemin d'acces vers ce cher devenv.exe (l'exe de l'EDI Visual Studio)

"Command line arguments" : se termine par le chemin vers la solution "a problème" ; notez la valeur magique "Exp" que j'ai entouré en rouge au debut, qui apparait egalement dans la ligne de commande donnée ci-dessus, trois paragraphes plus haut ( "... GetOrig 9.0 Exp" ).

Puis, depuis ce mode standard de VS, faites F5 : cela lancera la deuxieme instance de VS en mode "experimental" en ouvrant votre solution "tueuse", qui sera en session de debug, et vous permettra de l'auditer a partir du premier VS (celui en mode standard).

J'ai utilisé cette technique, avec succès bien sûr, plusieurs fois, pour depister des bugs "bêtes et méchants" dans certains de mes composants (ou d'autres, tierce partie) qui me posaient problème en mode design dans des Winforms, par exemple.

Bon courage, "bonne chance".

N'oubliez pas de dire "merci" aux equipes de dév MS de Visual Studio et de son SDK si vous vous en sortez...

'HTH

Bonjour,

J'ai un soucis plutôt gênant avec une solution développée sous VS2005 sur un PC biprocesseur, 2.5Go de RAM, bref une belle bête qui fait des jaloux dans ma boîte ^^
Depuis un mois, à quasiment chaque modification de code/génération, devenv.exe occupe 100% du processeur (en fait 50% d'un des 2 proc) sur un temps infini ... Je ne récupère pas la main sur Visual Studio. Par contre j'ai quand même la main sur le reste de mes applis (merci le biproc).
Ma solution est connectée à un serveur SourceSafe que j'ai mis en cause. Mais même une fois déconnecté du VSS le problème persiste.
Ce qui est étrange c'est que cette même solution fonctionne sur les autres postes des développeurs de cette solution...J'ai aussi essayé une déconnexion totale du réseau, mais ça ne change rien.
J'ai tenté enfin de passer sous Visual Studio 2008, mais c'est toujours pareil.

J'ai trouvé une solution de dépannage en récupérant un vieux portable mais c'est pas le pied...

quelqu'un a-t-il des idées/pistes à suivre/solutions ?

Merci d'avance
Ben

[ben_popcorn]

Merci pour cette réponse détaillée
Je vais explorer tout ça, y a du boulot

[ben_popcorn]

Ok, j'ai mis le système en place.
Mais question naïve, comment faire des breakpoint ? Est-ce une notion qui a du sens dans ce genre de procédé ?

J'ai oublié de précisé que le pb de CPU intervient aussi quand je fais une modification de code que je sauve...l'icône de sauvegarde (disquette clignotante dans la status bar) flashe quelques secondes puis plus rien et le CPU grimpe en flêche...

[lysiandad]

Oui, vous pouvez poser des breakpoints, bien sûr, dans un source (C#, VB.NET, etc) d'un composant impliqué dans un des projets de la solution qui "tue". Mais bien sûr, n'ayant pas d'info sur l'architecture / les technos utilisée dans celle-ci, ne l'ayant pas sous les yeux, il est difficile, comme ça, de vous dire a priori où mettre ce(s) breakpoint(s)...

Utilisez votre intuition sur ce qui est impliqué quand vous sauvegarder tout ou partie de cette solution ; si nécessaire, procédez par "dichotomie" en qq sorte et excluez les projets un par un par... ou excluez les de la compilation/du build... ou excluez certains sources, etc

A nouveau, bon courage, "bonne chance".

C'est clairement un problème que vous devez adresser assez rapidement de toute façon, je suppose...

Ok, j'ai mis le système en place.
Mais question naïve, comment faire des breakpoint ? Est-ce une notion qui a du sens dans ce genre de procédé ?

J'ai oublié de précisé que le pb de CPU intervient aussi quand je fais une modification de code que je sauve...l'icône de sauvegarde (disquette clignotante dans la status bar) flashe quelques secondes puis plus rien et le CPU grimpe en flêche...

[ben_popcorn]

Bon, j'ai fai du ménage dans ma solution et il me reste juste un projet WinForms (l'IHM de mon appli).
Je suis désolé mais j'ai du mal à comprendre comment je peux débugger la sauvegarde d'un fichier source par Visual Studio
La montée du CPU n'intervient pas au RuntIme de mon projet mais bien pendant l'édition sous VS2005.

Ma solution initiale (l'appelante) ne contient le minimul syndical (1 formulaire vierge) , me trompe-je ?

Merci en tout cas de votre aide

[lysiandad]

Hmm..

au moins, vous avez isolé le projet coupable. Verifiez que VS se comporte bien avec un projet Winforms minimal (Form1, Program.cs, blabla), au moins. Avant d'investiguer plus dans votre projet Winforms.

Si c'est le cas, il faudra nous en dire plus sur les librairies et/ou add ins impliqués par votre "méchant" projet pour avoir un debut de piste (meme si c'est du sable...) pour debugger celui ci plus avant en mode experimental...

Bon, j'ai fai du ménage dans ma solution et il me reste juste un projet WinForms (l'IHM de mon appli).
Je suis désolé mais j'ai du mal à comprendre comment je peux débugger la sauvegarde d'un fichier source par Visual Studio
La montée du CPU n'intervient pas au RuntIme de mon projet mais bien pendant l'édition sous VS2005.

Ma solution initiale (l'appelante) ne contient le minimul syndical (1 formulaire vierge) , me trompe-je ?

Merci en tout cas de votre aide

[Graffito]

Ce qui est étrange c'est que cette même solution fonctionne sur les autres postes des développeurs de cette solution...

Je verrai bien des événements qui s'appelent recursivement.
Vérifier en priorité les events générés par des Timer!

[lysiandad]

En effet, assez probable. Mais cela génère souvent des stackoverflows, hors on ne nous a pas dit que VS "crashait"... juste qu'il accapare tout le CPU ; je pencherais donc plutot tout betement pour une boucle infinie quelque part, sans impliquer la pile d'appel, ce qui ne va pas faciliter le debug...

Je verrai bien des événements qui s'appelent recursivement.
Vérifier en priorité les events générés par des Timer!

[Graffito]

Mais cela génère souvent des stackoverflows

Exact, mais il semble qu'on puisse parfois attendre très longtemps.
En pratique, j'ai encore jamais vu vu de stack overflow quand mon programme bouclait. On peut imaginer que dans certains cas il devait y avoir des alloc infinies, mais j'ai apparament toujours interrompu avant l'overflow (disons au bout de qq minutes).

[lysiandad]

Anyway (je touche du bois), VS ne m'a jamais fait ça, jusque la, j'ai toujours pu finir par debugger le composant ou l'add in coupable, en mode conception, comme pour les applis.

J'espere et je suis donc assez curieux de voir comment notre ami va s'en sortir...

( )

Exact, mais il semble qu'on puisse parfois attendre très longtemps.
En pratique, j'ai encore jamais vu vu de stack overflow quand mon programme bouclait. On peut imaginer que dans certains cas il devait y avoir des alloc infinies, mais j'ai apparament toujours interrompu avant l'overflow (disons au bout de qq minutes).

[ben_popcorn]

Alors...
- Mon VS2005 fonctionne parfaitement avec d'autres projets (gros ou petits)
- Je n'utilise aucun timer dans mon application
- Je ne pense pas que ce soit des boucles sur des évènements puisque le CPU est accaparé au Design Time
- A tout hasard je vais tenter d'amorcer le problème pour voir si je récupère bien la main ou pas....

Je précise aussi que je suis bien en VS2005 SP1 sur un PC reformaté récemment.

[ben_popcorn]

Je progresse, limite j'ai trouvé mais je n'en suis pas sûr.
J'avais en fait décharger" les projets annexes de ma solution. Là je viens de les supprimer véritablement et je n'arrive plus à reproduire le problème. Je vais tenter maintenant de charger indépendemment chacun des sous-projets.
Je vous tiens au jus

[ben_popcorn]

Retour arrière.
[contexte] projet "tueur" seul
J'ai isolé un contrôle utilisateur qui, à chaque édition provoque des problèmes.
exemple:
-CPU à 100% pendant 1mn 30 quand j'ajoute une ligne vierge dans mon fichier source .cs
-CPU à 100% pendant 5mn quand je génère la solution après la modif précédente