none
Une version 32 bits d'un programme plante aleatoirement sur un 64 bits RRS feed

  • Discussion générale

  • Bonjour,

    je fais actuellement face à un soucis plus ou moins étrange. J'ai bossé sur une application qui tourne "très bien" depuis plusieurs années sur Xp.

    Seulement, celle-ci "plante" lorsqu'elle tourne sur Seven 64 bits. Elle ne plante pas à son lancement et peut "tourner" pendant un long moment (plusieurs heures) avant d'être interrompue.

    Il fut testé d'utiliser le mode de compatibilité (Xp Sp2) pour lancer l'application. Le résultat n'est pas meilleurs.

    La théorie la plus probable est que le soft utilise des dll incompatibles avec du 64 bits. Mais les "plantages" semblent très aléatoire et donc difficiles à déterminer.

    Avez-vous déjà connus le même problème ? Quelles solutions peuvent-elles être envisagées pour traquer mon soucis (j'ai activé le doc watson) ?

    Une piste a explorer ? Je vous écoute. Merci pour toute information qui pourrait m'aider.





    • Modifié samus53 jeudi 15 mars 2012 09:10
    • Type modifié Ciprian Duduiala lundi 19 mars 2012 07:14 attente de feedback
    mardi 6 mars 2012 08:08

Toutes les réponses

  • Ce problème est peut-être aussi la révélation d'un bug latent.

    Faites comme si elle ne marchait pas sous Xp, au moins dans un premier temps.


    Paul Bacelar, Ex - MVP VC++

    mardi 6 mars 2012 08:31
    Modérateur
  • Quand cette application plante: que se passe-t-il ? Avez-vous vérifier si la mémoire allouée par votre application ne cesserait pas d'augmenter, ou le nombre de handle  ou le nombre de thread ? Cette application interface - t- elle du matériel ? Cette application fait-elle appel à d'anciens composants ActiveX ?

    Cet executable l'avez-vous compiler sous XP ? Avec quel compilateur ?

    Avez-vous importer les DDL associées à votre programme ? Certaines sont-elles issus d'autres composants logiciels ?


    Delphine GARRO

    mardi 6 mars 2012 09:45
  • Bonjour. Premièrement, merci pour vos questions, elles me donnent des pistes "simples" que je n'avais même pas pensé à explorer.

    L'application a été compilée avec visual c++ 6.0 (1998) sous windows Xp.

    Nous tentons de l'exporter vers un visual studio 2010 mais sans résultats pour l'instant.

    Concernant un gonflement mémoire, rien de remarqué pour l'instant. Pour les handle et Thread, faudrait pourvoir étudier cela. Il y a eu des soucis du genre, (normalement) réglés depuis, mais je ne vois pas pourquoi l'appli tourne jours et nuit sans soucis sur Xp et plante au bout de quelques heures sur un Seven.Il n'y a à ma connaissance aucun ActiveX d'utilisé.

    Je vais tacher d'examiner les dll externes utilisées.



    • Modifié samus53 mardi 6 mars 2012 10:33
    mardi 6 mars 2012 10:30
  • Je vous conseillerai d'exporter votre projet vers Visual Studio C++ 2003  (7.1) , plus proche de la version 6.0 et compatible Windows 7 avec quelques petites précautions d'utilisations ( ne pas rechercher un mot dans votre projet, quitter le compilateur pour supprimer les fichiers temporaires avant chaque nouvelle compilation): ce qui vous permettrait de débugger votre programme en toute tranquillité.

    Une grande différence entre les 2 versions de Windows : sous XP vous pouviez interfacer les périphériques comme bon vous semblait, sous 7 tous les accès systèmes (accès aux disques, à la base de registre, aux périphériques, aux données Ethernet, ...), sont ultra-protégés.

    Je ne pense pas que ce soit le fait que votre application soit 32 bits sous un Windows 64 bits: Windows 64 bits lancera votre application dans un environnement 32 bits sans que vous n'aillez rien à faire... c'est magique !


    Delphine GARRO


    mardi 6 mars 2012 10:45
  • Utilisez des outils comme AutoDumpPlus pour générer des dump lors des crash.

    Utilisez WinDbg avec les fichiers pdb à jour.

    Avec cela vous verrez à quelle ligne dans le code il y a eu crash et la valeur des variables à ce même moment.

    (Si vous ne pouvez pas utiliser une session de débugging avec VS bien sûr.)


    Paul Bacelar, Ex - MVP VC++

    mardi 6 mars 2012 12:31
    Modérateur
  • Une appli qui fonctionne sous XP mais pas sous Windows 7 c'est souvent dû à des accès en écriture qui étaient autorisés sous XP en mode administrateur, mais qui sont interdits sous Windows 7 sans élévation de privilège. Comme l'écriture d'une clé dans la base de registre sous HKLM, ou l'écriture d'un fichier dans \program files, ou \Windows. Des accès qui ne fonctionnent plus, sans vérification de code d'erreur, et ça donne vite un pointeur nul.

    Mais sinon, à part déboguer, je ne vois pas trop comment trouver.

    mardi 6 mars 2012 15:03
    Auteur de réponse
  • Bonjour,

    L'appli planterait dans une dll...

    En fait il y en a 2 de mises en cause mais la principale est msvcrt.dll lors d'un memcpy (j'ai perdu le nom de la seconde.)

    la seule écriture registre serait lors de l'installation (aucun pb).

    Je crois que l'application a été testée en mode administrateur. (Je vais vérifier cela) Je sais pas si c'est une élévation suffisante ;)

    mardi 6 mars 2012 15:44
  • Si memcpy plante c'est que ces paramètres ne sont pas bons.

    Vérifiez avec un débuggeur qu'une valeur négative en nombre 32 ne se soit pas métamorphosée en un grand nombre 64 bits.


    Paul Bacelar, Ex - MVP VC++

    mardi 6 mars 2012 16:49
    Modérateur
  • Cela pourrait être aussi bien un dépassement de mémoire: copie de données en dehors de la taille du buffer source ou du buffer destination, aussi bien que des buffers non alloués, ou alloué trop tard si exécution de plusieurs tâches dans votre application, etc ...


    Delphine GARRO

    mardi 6 mars 2012 16:54
  • Si memcpy plante c'est que ces paramètres ne sont pas bons.

    Vérifiez avec un débuggeur qu'une valeur négative en nombre 32 ne se soit pas métamorphosée en un grand nombre 64 bits.


    Paul Bacelar, Ex - MVP VC++

    Proposition étrange. Dans quels cas cela peut-il se produire ? j’admets ne pas être à l'aise avec les "soucis" pouvant survenir lors d'un passage sur un système 64 bits.
    Merci pour vos explications.

    Cela pourrait être aussi bien un dépassement de mémoire: copie de données en dehors de la taille du buffer source ou du buffer destination, aussi bien que des buffers non alloués, ou alloué trop tard si exécution de plusieurs tâches dans votre application, etc ...


    Delphine GARRO

    En effet, même si l'erreur proposée par Mr Paul Bacelar m’intéresse du point de vue technique, le dépassement mémoire fut une erreur envisagée. Seulement, ce soucis se produirait "aussi" sur Xp, non ?

    Encore merci pour vos lumières.

    • Modifié samus53 mardi 6 mars 2012 22:54
    mardi 6 mars 2012 18:49
  • Il arrive parfois que des dépassements mémoire ne plante pas une application suivant la zone où se situe ce dépassement.

    Le phénomène qui se produit sous 7 pourrait tout aussi bien un jour se produire sur XP.

    J'ai eu récemment le cas d'une mauvaise définition de tableau: allocation de 256 éléments alors que pendant 2 ans j'utilisait ce tableau avec une taille de 512 éléments. L'application ne plantait jamais, jusqu'au jour où l'application se mit à planter de façon systématique.

    Ensuite, la gestion des tâches sous 7 est meilleure que sous XP: si votre application est multitâche, il peut subsister des problèmes de synchronisations qui dépendent simplement de la vitesse d’exécution de ces tâches.


    Delphine GARRO

    mercredi 7 mars 2012 09:04
  • Faites le debugging sous système 64 bits comme d'habitude.

    Le fait que le programme soit tombé en marche sous Xp 32 bits n'a pas d'incidence sur le debugging.


    Paul Bacelar, Ex - MVP VC++

    mercredi 7 mars 2012 09:05
    Modérateur
  • Bonjour,

    merci pour vos détails. Cela devient un peu plus clair.

    Concernant le debuging, vous m'avez conseillé des outils comme : WinDbg et AutoDumpPlus. Pour le premier il n'y a pas de soucis. Concernant le second, je ne le connais pas du tout. En fouillant il un peu il semble viser IIS mais peut être orienté vers d'autres applications. Fait-il parti des outils de debug fournis par VS 2010 ? (D'ailleurs la compilation est un succès désormais pour ce dernier) Où bien doit-on le télécharger ?

    Merci pour votre écoute.

    Bonne journée.


    • Modifié samus53 mercredi 7 mars 2012 12:40
    mercredi 7 mars 2012 12:39
  • Si vous arrivez à reproduire le problème sur une machine où est installé VS2010, utilisez une session de debugging VS2010.

    Si vous arrivez à reproduire le problème sur une machine sous votre contrôle, ayant les composants de debugging à distance de VS2010, utilisez une session de debugging VS2010.

    (Après réflection, je n'ai jamais fais de debugging 64bits avec VS2010, je ne sais pas s'il y a une limitation de cet ordre. Si c'est le cas, voir le cas ci-dessous)

    Si vous n'y arrivez pas, utilisez AutoDumpPlus, fourni avec les Windows Debuging Tools, pour générer un dump. Utiliser VS2010 ou WinDbg pour analyser le Dump ainsi généré.

    AutoDumpPlus à des fonctionnalités supplémentaire pour le debugging d'applications sous IIS, mais vous n'avez pas besoin de ces fonctionnalités.

    http://support.microsoft.com/kb/286350

    Dans notre cas, ce n'est qu'une couche de configuration aux debuggeurs systèmes installé dans tous les Windows depuis WinNT3.X.


    Paul Bacelar, Ex - MVP VC++

    mercredi 7 mars 2012 18:23
    Modérateur
  • Bonjour, je ne fais que remonter l'information pour l'instant :

    Nous sommes parvenus a compiler sur un visual studio 2010.

    L'application "plante" moins fréquemment. (et à heures régulières maintenant, donc on s'oriente un peu dans notre code vers des taches gerées par l'appli).

    Cependant le soucis s'est déplacé vers ntdll.dll et l’exception ntdll!ExpInterlockedPopEntrySListFault

    Autodump n'était pas utilisé lors des derniers crashs, (nous attendons de le découvrir un peu plus avant usage). Je vous remonte les infos suivantes si nous en avons encore merci.

    lundi 12 mars 2012 12:54
  • Bonjour,

    figurez-vous que je suis bien embeté.

    nous pensions que l'application plante de facon regulière : 2 fois par jour souvent entre 3 et 6h. Cela fait quelques temps (quelques jours)désormais qu'elle tourne sans planter. Paradoxalement, nous attendons donc un plantage pour la debuger ;)

    Toujours dans le paradoxe, c'est SQlServer qui a planté une fois et a redemarré automatiquement. L'application n'a pas remarqué ce soucis et continue encore d'envoyer des requetes sans probleme.

    Alors que nous pensions qu'il y avait comme un schéma de plantage, cela s'avère en fait aléatoire. C'est un peu un comble d'attendre que son appli plante.

    Les pistes restent nombreuses : dépassement mémoire, soucis d'accès, problème de multi coeur, écriture sur pile...
    • Modifié samus53 jeudi 15 mars 2012 09:12
    jeudi 15 mars 2012 09:08
  • C'est une situation bien inconfortable mais malheureusement fréquente.

    AutoDumpPlus est l'outil qu'il faut, je trouve, pour ce type de problème.

    Vous le configurer coerectement en production, et le jour où cela se déclenche, vous aurez automatiquement un Dump avec un maximum d'information sur le problème.

    Comme vous pouvez faire cela en production, sur des machines de production avec une configuration de production etc..., vous aurez des informations sans avoir à faire des hypothèses.


    Paul Bacelar, Ex - MVP VC++

    lundi 19 mars 2012 12:28
    Modérateur
  • Bonjour, nous avons nos premiers dumps.

    Nous allons bientôt les analyser.

    Tout cela est très étrange. Les coïncidences bizarres se cumulent. (plantage dans à peu près les mêmes heures, souvent plusieurs plantages à la suite et jamais un seul isolé).

    Nous avons pu déterminer des parties de code qui "font planter", mais elles ne le font pas obligatoirement.

    mardi 20 mars 2012 10:17
  • Tant qu'on n' a pas la vraie explication, c'est toujours étrange.

    Par exemple : une application qui plantait toujours dans des plages horaires proches (très tôt le matin) mais pas systématiquement et uniquement dans certains environnements :

    Explication : code réseau non blindé et des backups de base de données qui chargent les réseaux à heures fixe.

    C'est du vécu. ;-)


    Paul Bacelar, Ex - MVP VC++

    mardi 20 mars 2012 13:24
    Modérateur
  • Bonjour,

    pour l'instant, nous n'avons pas recu le feux vert pour le placer l'application avec Adplus chez un client. Autodump se révèle en plus assez gourmand en mémoire.

    l'application tourne "très bien" sur des machines virtuelles. Nous n'avons pas à la faire planter...

    Votre soucis de charge réseau pourrait éventuellement s'appliquer à ce cas. L'application ne plante pas chez un client (en 32 bits) sur un WS2003 mais est peu sollicité d'un point de vue réseau. Chez d'autres, c'est rare, mais les plantages sont rapprochés (genre 2 ou 3 en trois heures, puis plus rien pendant toute une semaine). Ce sont des serveurs déjà plus lourds.

    bref, il me faut encore attendre.

    mercredi 21 mars 2012 10:38
  • "Autodump se révèle en plus assez gourmand en mémoire"

    ???

    Vous l'avez configuré pour utiliser quel débuggeur ?


    Paul Bacelar, Ex - MVP VC++

    mercredi 21 mars 2012 10:59
    Modérateur