Discussion :

[Trebly]

Bonjour,

j'ai un important souci avec la mise en veille profonde qui échoue fréquemment et conduit à un reboot. Mais comme l'arrêt à partir du mode veille souvent ne s'est pas effectué dans de bonnes conditions les logiciels ont été interrompus brutalement ce qui est source de nombreux problèmes.

Ainsi souvent mais pas toujours quand la machine doit passer en veille profonde soit à la suite d'une action définie (fermeture du couvercle de l'ordinateur par exemple) soit à la suite d'un timeout avec une transition du mode veille au mode veille profonde (Hibernate from sleep) le processus échoue sur une erreur que je rapporte ci-dessous.

Les erreurs les plus fréquentes après ce crash sont la redemande des mots de passe principaux (onedrive, google, microsoft etc...) mais aussi pour mon logiciel de gestion de presse-papiers l'impossibilité d'accès aux fichiers qu'il gère. Cet accès est ouvert tard dans le démarrage (fichiers cryptés) et nécessite souvent de fermer puis réouvrir le soft (en démarrage automatique) jusqu'à ce que l'erreur ne se produise plus.

L'analyse de la trace file "system-sleep-diagnostics.html" montre :

1- First keyboard command at 2:30 am : going in simple sleep

START TIME DURATION STATE ACTION REASON ID STATUS SUCCESSFUL
2020-11-11T02:30:15 3:00:12 Sleeping3 0 Button or Lid 1 0 1

2- 3hours later (as defined in detailed parameters normally goto Hibernate) the next item into the list is :
- Invalid

START TIME DURATION STATE ACTION REASON ID STATUS SUCCESSFUL
2020-11-11T05:30:28 0:00:00 Invalid 0 Hibernate from Sleep - Fixed Timeout 0 0 0

Il semble donc bien que le « timeout » de la transition "Hibernate from sleep" comprend des paramètres non définis. Ces données invalides conduisent au crash lors de l'exécution de la transition.
J'ai essayé d'obtenir de l'aide de la part de Microsoft (via l'aide interactive qui conduit compte tenu des questions posées à demander un chat avec l'assistance technique.
J'ai répété l'opération qui s'arrête sur « nous essayons de vous mettre en liaison avec un technicien » au moins 4 fois en quelques jours en laissant l'écran affiché pendant plus de 4 heures sans jamais que l'écran ne bouge. Nota : j'effectue d'opérations à différentes heures pour être compatible avec les heures françaises et américaines.

Est-ce que quelqu'un a des suggestions à me faire pour résoudre le problème.
Je n'ai trouvé aucune information sur le net concernant ce problème.

Cordialement,

trebly

Contexte : Windows 10 Pro - 2004

[JML19]

Bonjour

Tu sembles avoir un problème avec le fichier temporaire d'hibernation.

[Trebly]

Bonjour,

Merci,

Après vérification sur les *.sys, rien ne me permet d'imaginer une anomalie.

A noter : le passage en hibernation par la fermeture du capot semble fonctionner quand on n'est pas passé par la veille, mais
- passage par la veille auto ou manuelle suivie de l'hibernation par timeout ou par fermeture du capot (option choisie)
- mode hibernation via le panneau de commande
conduisent toujours à un reboot.
Cela milite dans le sens d'une défaillance du processus qui dépend des conditions initiales.

Le fichier hiberfil.sys de 13.727.440.896 o. a bien été écrit lors de la dernier mise en veille profonde, pourtant le réveil a généré un reboot.
Il y a 100Go libres sur le disque. Je n'ai pas le moyen simple de tester complètement le disque système (il me faudrait remettre en place un boot externe avec un outil de test de disque qui fonctionne avec le SSD).
Ma machine à 32Go de mémoire et 500Go de SSD système servis par un Core I7 6700K (en fonctionnement j'ai 40% de mémoire utilisée et 18% de CPU sauf lorsque des traitement importants au démarrage ou video par exemple interviennent.

Ce qui m'interroge, beaucoup c'est lors du redémarrage :
1- anomalies sur les identifications (connection utilisateur windows, perte des identifications onedrive, demande de re-validation des empreintes, demande de validation microsoft via le code utilisateur)
2- le fait que le logiciel de gestion du presse papier n'arrive pas à accéder à ses fichiers (erreur "accès refusé par le système") et que c'est beaucoup plus tard (peut-être 10 minutes) qu'il est possible de le relancer avec succès.

Une hypothèse est qu'il y a après des tests (effectués il y a plusieurs mois, voire un an après un crash de disque par défaillance matérielle) un problème d'ordre de démarrage de certains services (mode "auto" basculé à "forcé" ou de "différé" à "auto", celà me dit quelque chose (il y a 15mois) mais je n'ai pas de trace détaillée, depuis je suis passé de 1903 à 2004 et c'est là que la quasi totalité des anomalies sont apparues, excepté la question du reboot mais qui s'effectuait proprement. Il y-a-t-il des outils pour contrôler la "cascade" de démarrage (au moins la liste des modes obligatoires), j'ai l'impression d'une désynchronisation de processus(s) qui pourrait se manifester à la fermeture et à l'ouverture.

Cordialement,

Trebly

[JML19]

Tu as testé ton SSD, il semble avoir des problèmes d'écriture ou de lecture ?

J'ai eu le cas avec mon SSD Samsung 850 Pro, j'ai fait à un moment une restauration d'un clone fait avec CloneZilla pour supprimer ces problèmes.

Je sais qu'un SSD contient plus de cellules que celles utilisables, il doit les réattribuer en cas de problème.

Je pense qu'à cause de Windows il ne le fait pas, lors de la restauration d'un clone il peut réattribuer ces cellules qui ont un problème.

[Trebly]

Bonjour,

J'ai du arrêter mes activités pendant de longs mois.

Le problème n'a pas de solution complète et je peux toujours provoquer le crash.
Il y a semble-t-il une (ou plusieurs) incohérence dans le processus de mise en veille profonde.
La séquence dépend de la combinaison d'un très grand nombre d'évènements et d'états (capot, connection secteur, charge en cours ou terminée, entrée en veille profonde à partir de l'état d'exécution normal, d'entrée en veille à partir d'un état de veille etc...) définis par les paramètres, ainsi que le processus optionnel d'activation du mode. D'autre part la prise en compte des paramètres nécessite toujours, sans demande du système, un redémarrage à froid, sinon le moteur de processus semble commettre des erreurs cependant difficilement reproductibles.
J
J'ai observé le même problème sur une autre machine portable.

La mise en veille profonde fonctionne parfaitement dans les cas suivants :
1- A partir de l'état "normal", tel que défini, fermeture du capot, commande clavier
2- Timeout sur secteur batterie chargée ou sur batterie

Le processus plante dans les cas:
- Fermeture du capot alors que la machine est entrée en veille simple (le timer fonctionnera pour provoquer la veille profonde, mais l'interruption de veille par le capot génère un processus de début de mise en veille profonde qui s'interrompt, suivi d'un redémarrage capot fermé, ensuite on finit par un crash)
- Fermeture alors que la machine est en charge sur secteur provoque une extinction. Eviter l'incident nécessite de débrancher du secteur avant de fermer le capot
- Mise en veille profonde à partir d'une veille simple via un raccourci clavier provoque le crash du processus de mise en veille profonde au moment de l'écriture de l'enregistrement de sécurité. Solution pratique, réveiller la machine, vérifier si elle est sur secteur qu'elle n'est pas en charge, sinon débrancher, puis commander la mise en veille profonde suivant configuration du cas 1.

Nota : je n'ai pas testé le fonctionnement avec le bouton Arrêt/Démarrage.

Evidemment j'arrive à mettre en veille profonde sans incident en appliquant les règles que j'ai décrites et j'évite de provoquer des incidents qui ont toujours des conséquences sévères (enregistrement de sécurité défectueux).

Il est possible que les versions windows mises à jour aient corrigé tout ou partie de ces problèmes, mais je n'ai pas de temps à passer à faire des tests.

Cordialement

Trebly