Journal Mouahahahaha !

Posté par  (site web personnel) .
Étiquettes : aucune
0
9
mai
2003
Vu sur clubic : (à propos d'icsepé)

Ce bug provoque une charge d'occupation processeur de 100% lorsque vous effectuez un simple clic droit sur un fichier ou un dossier dans l'explorateur Windows. Ceci se traduit alors par des pertes de performances au niveau du réseau ou par des coupures / de la détérioration au niveau du son si vous écoutiez de la musique, ou encore par des blocages si jamais vous étiez en train de copier des fichiers.

Pour éviter ce bug qui sera corrigé par un futur patch et par le Service Pack 2 de Windows XP, voici ce que préconise Microsoft :

1ère méthode :

Rendez-vous dans le panneau de contrôle, puis dans les propriétés d'affichage. Allez ensuite dans l'onglet "apparence", cliquez sur le bouton "effets" et désactivez la première case dans la fenêtre "effets".

2ème méthode :

Le bug peut être évité si vous selectionnez (à l'aide d'un clic gauche) le fichier ou le répertoire sur lequel vous souhaitez effectuer une opération avant d'effectuer un clic droit.

C'est beau les performances...

  • # Re: Mouahahahaha !

    Posté par  . Évalué à 6.

    XP est-il prêt pour le desktop ?

  • # Re: Mouahahahaha !

    Posté par  . Évalué à 1.

    J'ai pas compris. C'est systématiquement reproductible ? C'est quoi les conditions ?

    • [^] # Re: Mouahahahaha !

      Posté par  . Évalué à 1.

      Oui c est systematiquement reproductible. Il suffit
      - d'avoir le SP1 de winXP
      - de cliquer avec le bt droit sur un fichier non selectionné ds l'explorateur
      - que la méthode 1 ne soit pas mis en place (ce qui est logique)

      et voila on a un beau chauffage ;)

      • [^] # Re: Mouahahahaha !

        Posté par  . Évalué à 1.

        Pas la peine d'avoir le SP1, je viens de le tester avec un XP Pro standard, effectivement, ça bouffe 100% des ressources CPU.

        Pour s'en rendre compte :
        1°) ouvrir une fenêtre explorer sur un disque dur, ou plusieurs dossiers/fichiers sont accessibles
        2°) ouvrir le Gestionnaire de tâches et sélectionner l'onglet "performances" (mouarf!)
        3°) s'assurer qu'aucun fichier/dossier n'est sélectionné dans la fenêtre de test (un clic sur le fond de la fenêtre suffit à déselectionner toute selection éventuelle)
        4°) cliquer avec le bouton droit de la souris sur un dossier/fichier non sélectionné, et admirer l'utilisation du CPU à 100% tant que le menu contextuel est présent à l'écran !

        Bizarrement, bien qu'il semble que 100% du CPU soit utilisé, j'ai tous les programmes qui tournent en tâche de fond qui ne sont pas ralentis, alors je ne comprends pas trop. Le bug fait-il réeellement tourner le CPU à 100% ou fait-il seulement une erreur d'affichage dans le Gestionnaire de tâches ? Et s'il fait réellement tourne le CPU à 100%, lui bloque-t'il prioritairement 100% des ressources, ou sont-elles tout de même répartie en fonction des besoins, le bug s'accaparant celles qui restent disponibles (je penche pour cette solution) ?

        En tout cas, c'est marrant, même s'il est évident qu'un tel "bug" ne risque pas vraiment de faire fondre un CPU ou chuter les performance ;)

        • [^] # Re: Mouahahahaha !

          Posté par  . Évalué à 1.

          En fait, un while(1) suffit à bouffer 100% du CPU. Tu peux essayer sur ta machine Linux, celui-ci n'en souffrira pas plus. Cela vient du fait que ce programme est une boucle très rapide qui ne contient aucun appel noyau ni section atomique. Donc interruptible à tout moment si le besoin s'en fait sentir ! Tous les programmes peuvent donc utiliser à souhait leur quantum de temps, ton while(1) bouffera le temps qu'il reste. C'est même d'ailleurs le travail et l'unique utilité du process Idle. Cela peut commencer à devenir pénalisant, lorsque tu lances plusieurs fois ce même while(1). Là, chaque processus revendiquera son quantum de temps dans son intégralité, et il faudra tous les écouler avant de pouvoir rendre à nouveau la main aux autres processus. Mais là encore, du fait de l'interruptibilité quasi-permanente de tes processi, tu n'auras pas de « retard » sur l'exécution programmée d'un autre processus. C'est ce dernier problème qui fait fait ramer une machine en général.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.