Win7 x64 non réactif pendant une minute environ. Le disque dur est-il défaillant?

Sur la base des nouvelles informations que vous avez fournies, je peux dire qu'en réalité il n'y a aucun problème du tout. Alors pourquoi "se mettre hors ligne" pendant quelques secondes jusqu'à trois minutes après la suspension du système d'exploitation invité? Parce que, comme vous l'avez dit, le voyant LED du disque dur reste allumé tandis que le lecteur reste non réactif car il est fortement utilisé.

Ce qui se passe, c'est que lorsque vous avez fini d'utiliser VMWare et que vous souhaitez mettre en veille le système d'exploitation invité, vous utilisez la veille ou la fonction d'hibernation au lieu de l'arrêt. Cela fait que VMWare copie le contenu de la RAM de la machine virtuelle sur le disque afin de pouvoir reprendre là où il s'était arrêté sans avoir à tout redémarrer. En fonction de la quantité de mémoire que vous avez attribuée à la machine virtuelle et de la quantité utilisée, cela signifie que VMWare peut devoir écrire beaucoup de données (gigaoctets) sur le disque.

Lorsque VMWare copie la mémoire sur le disque, le disque devient plus ou moins non réactif aux nouvelles opérations sur le disque jusqu'à ce que les opérations sur le disque en cours (écriture de la RAM dans un fichier) soient terminées. Par conséquent, lorsque vous ouvrez Poste de travail, Windows tente de rafraîchir les données mais ne peut pas lire le disque pour récupérer les données nécessaires car il y a toutes ces commandes d'écriture déjà en attente. Par conséquent, il le laisse vide et semble être hors ligne jusqu'à ce qu'il puisse réussir à insérer ces demandes de lecture (entre les opérations d'écriture de VMWare).

Si vous ouvrez le disque dans l'Explorateur, vous verrez qu'il ne l'ouvrira pas du tout pendant un certain temps, ou qu'il l'ouvrira et fera clignoter la barre d'adresse avec une barre de progression verte comme il le fait chaque fois qu'il y a une opération de fichier longue (comme la recherche de milliers de fichiers).

En résumé, il n'y a rien d'étonnant ou de mystérieux dans cette situation. Si au lieu de mettre un système d'exploitation invité VMWare en veille, vous aviez simplement copié manuellement un fichier géant sur le lecteur, les résultats seraient exactement les mêmes.

Alors que pouvez-vous faire pour régler ce problème? Mis à part passer à un disque plus rapide (ou utiliser un disque interne si D: est externe), votre meilleure option est de défragmenter le disque. Si D: est très fragmenté, alors lorsque VMWare essayera de vider la RAM sur le disque, il le fera tourbillonner beaucoup tout en écrivant des morceaux du fichier géant dans différentes zones (bien sûr, cela part du principe que ce n'est pas un SSD, car si D: est toujours une partition sur le même disque 0ST320LT007 que C:, alors ce n'est pas le cas).

Si vous défragmentez le disque (en supposant qu'il y a suffisamment d'espace libre), alors le système pourra écrire le fichier RAM avec seulement quelques opérations de fichier en grandes zones (par exemple, écrire 1 Go de données au cluster X ) au lieu de nombreuses petites opérations (écrire 1 Mo ici, écrire 245,18 Mo là, 4 Ko ici, encore 18,1 Mo ailleurs…) Ensuite, mettre le système en veille se terminera beaucoup plus rapidement et le disque sera plus réactif.

Pour découvrir exactement quel accès cause l'activité du disque et le rend occupé, vous pouvez utiliser un outil comme Process Monitor. Exécutez-le et cliquez sur les filtres de classe pour sélectionner uniquement le filtre de classe de fichier comme indiqué ci-dessous.

Maintenant, vous pouvez voir quels fichiers et dossiers sont accédés. Assurez-vous de mémoriser le raccourci clavier pour démarrer et arrêter la capture d'activité (Ctrl+E) afin de pouvoir l'arrêter une fois qu'il commence à être submergé par ce qui est probablement les opérations de disque de VMWare.