Comment changer l'emplacement du fichier d'hibernation dans Windows 7?

43

Je ne parviens pas à activer l'hibernation sous Windows 7, car le lecteur C: ne dispose pas de suffisamment de place pour créer le fichier d'hibernation. Comment faire en sorte que Windows mette le fichier ailleurs?

windows-7 hibernate Phenom
la source
Double possible de Puis-je définir hiberfil.sys sur un autre lecteur?
PJTraill
Tu ne peux pas. Mais vous pouvez désactiver l'hibernation ( powercfg.exe -h off ), puis supprimez le fichier.
Ian Boyd

Réponses:

41

Vous ne pouvez pas, il doit être à la racine du lecteur de démarrage (le lecteur C: dans votre cas).

Raymond Chen a expliqué les raisons pour lesquelles cet article de Windows Confidential: Le paradoxe du système de fichiers .

L'hibernation suit un schéma similaire.   Hibernation des moyens du système d'exploitation   vider tout le contenu de la mémoire   dans le fichier d'hibernation; la restauration   de l'hibernation implique sucer que   déposer en mémoire et faire semblant   rien ne s'est passé. Encore une fois, c'est un autre   problème de la poule et de l'œuf: charger le   fichier d'hibernation, vous avez besoin du fichier   pilote système, mais le système de fichiers   le pilote est dans le fichier d'hibernation. Si   vous gardez le fichier d'hibernation dans le   répertoire racine du lecteur de démarrage, le   pilote de système de fichiers miniature peut être   utilisé à la place.

Snark
la source
14
Pour les mauvaises fenêtres ne peuvent pas gérer ça, j'en aurais vraiment besoin pour mon SSD. J'espère qu'ils le corrigeront à l'avenir afin que vous puissiez choisir où le mettre comme dans Mac OS X.
Hultner
5
Yah, à mon avis, c'est un peu un défaut de conception. Même si le système doit démarrer à partir du lecteur principal, il n’ya aucune raison de stocker tous les giga-octets d’informations sur le même lecteur: le fichier de mise en veille prolongée peut charger les éléments de base (accès au lecteur, par exemple), puis rechercher un lecteur supplémentaire. Les données. Malheureusement, ils ne l'ont pas conçu pour gérer ce cas, ce qui signifie qu'ils ne le seront pas avant un nouveau système d'exploitation ... si jamais.
Namey
1
@Namey: Si le fichier d'hibernation peut charger les bases, il peut tout aussi bien être écrit directement dans le chargeur de démarrage. Ensuite, vous ouvrez toute une boîte de Pandore. Sur un autre pas, je ne considérerais pas cela comme un défaut de conception non plus. Je suppose que cela a été écrit à l’époque de Windows NT, où la vitesse, les limites de la mémoire et la faible puissance du processeur étaient les principaux facteurs, et non les petits disques SSD. Heck, qui aurait prédit que les SSD étaient si communs en premier lieu ??
surfasb
1
Ce sont juste de jolis mots à propos de "poule et oeufs" qui importent peu: si le chargeur de démarrage sait comment charger un fichier en veille prolongée d'un disque à l'autre, il n'y a aucune raison de ne pas avoir de pilote de système de fichiers dans le chargeur de démarrage.
Denis Barmenkov
2
C'est une excuse stupide de Microsoft. Et si les deux disques sont sur le même contrôleur - le même pilote est utilisé? Et si un disque est en SSD et que vous ne voulez pas le porter rapidement?
NickSoft
6

Bon, il y a 2 choses à résoudre pour déplacer hiberfil.sys

  1. Indiquez à 'ntoskrnl.exe' qui s'exécute en tant que processus 'System' d'ouvrir / enregistrer les données d'hibernation sur D: \ hiberfil.sys au lieu de C: \ - & gt; pas encore résolu!

  2. Pour appliquer cette chance également au fichier de données de configuration de démarrage (c: \ BOOT \ BCD) - & gt; C'est relativement facile avec des outils comme le VisualBCD https://www.boyans.net/DownloadVisualBCD.html - & gt; Ou même simplement en utilisant l'édition de regedit HKLM \ BCD00000000 \ Objects {71575733-c376-11e4-80ea-806e6f6e6963} \ Elements \ 21000001 c'est-à-dire le HiberFileDrive du ResumeLoader ou \ 22000002 HiberFilePath. Vous devez peut-être utiliser "Fichier / Charger la ruche" c: \ BOOT \ BCD pour monter la branche "BCD00000000" (le curseur doit être sur HKLM, sinon l'élément de menu est grisé). - & gt; comme il semble que cela ait déjà été fait par ntosknl.exe, il n’est donc pas inutile de la changer car de telles modifications seront écrasées.

Cependant, le numéro 1 est la chose la plus difficile et la plus difficile à changer. Hmm, chargeons ntoskrnl.exe dans IDA et localisons la fonction traitant de /hiberfil.sys et décompilons-la pour voir ce qui se passe exactement là-bas ... 

__int64 __fastcall PopCreateHiberFile(LARGE_INTEGER *a1)
{
...
 RtlInitUnicodeString(&Source, L"\\hiberfil.sys");
...
  RtlAppendUnicodeStringToString(&Destination, &IoArcBootDeviceName);
  RtlAppendUnicodeStringToString(&Destination, &Source);
...
  ObjectAttributes.RootDirectory = 0i64;
  ObjectAttributes.Attributes = 576;
  ObjectAttributes.ObjectName = &Destination;
  ObjectAttributes.SecurityDescriptor = v5;
  ObjectAttributes.SecurityQualityOfService = 0i64;
  ret_2 = IoCreateFile(
            &FileHandle,
            0x100003u,
            &ObjectAttributes,
...

Bon bref le chemin est codé en dur comme ceci: IoArcBootDeviceName + "\ hiberfil.sys" sans quelques correctifs binaires, il n’ya aucun moyen de changer cela. Bien à côté de toucher les saintes fenêtres graal appliquer des correctifs au "ntoskernel" peut entraîner des problèmes tels que des mises à jour annulant le correctif ou des programmes antivirus pouvant devenir fous ... Cependant, voyons quelles références sont les références à IoArcBootDeviceName:

IopLoadCrashdumpDriver PopDeleteHiberFile PopCreateHiberFile PopBcdSetupResumeObject PopBcdSetDefaultResumeObjectElements PopBcdSetPendingResume PopBcdRegenerateResumeObject PopBcdEstablishResumeObject PopAllocateHiberContext IopCreateArcNames PopBcdSetupResumeObject

Wow changer cela semble être bien (La seule chose qui cloche un peu, c'est IopLoadCrashdumpDriver System32 \ Drivers \ crashdmp.sys, mais qui a besoin d'un crash-vidage - peu importe si nous cassons quelque chose là-bas)

Donc patcher IopCreateArcNames qui crée ArcBootDeviceName sera bien: 

NTSTATUS INIT_FUNCTION NTAPI IopCreateArcNames  (   IN PLOADER_PARAMETER_BLOCK  LoaderBlock )   
...
   /* Create the global system partition name */
   63     sprintf(Buffer, "\\ArcName\\%s", LoaderBlock->ArcBootDeviceName);
   64     RtlInitAnsiString(&ArcString, Buffer);
   65     RtlAnsiStringToUnicodeString(&IoArcBootDeviceName, &ArcString, TRUE);
   66 
   67     /* Allocate memory for the string */
   68     Length = strlen(LoaderBlock->ArcBootDeviceName) + sizeof(ANSI_NULL);
   69     IoLoaderArcBootDeviceName = ExAllocatePoolWithTag(PagedPool,
   70                                                       Length,
   71                                                       TAG_IO);
   72     if (IoLoaderArcBootDeviceName)
   73     {
   74         /* Copy the name */
   75         RtlCopyMemory(IoLoaderArcBootDeviceName,
   76                       LoaderBlock->ArcBootDeviceName,
   77                       Length);
   78     }

...

https://doxygen.reactos.org/d3/d82/ntoskrnl_2io_2iomgr_2arcname_8c.html btw J'utilise ntkrnlmp.exe 6.1.7601.19045 à partir de Win7 64 bits et vérifié ce code contre ReactOS. (Cependant, la partie en hibernation n'est pas encore implémentée dans les sources Reactos) Notez que ArcBootDeviceName sera quelque chose comme: \ Device \ Harddisk1 \ Partition0

Hmm, corrigeons ArcBootDeviceName (LoaderBlock + 0x78) en ArcHalDeviceName (LoaderBlock + 0x80)

Donc, dans le cas où le chargeur bootmgr est sur une partition différente de celle de Windows, nous espérons que hibernate.sys est créé par bootmgr. 

1405A9C15 4C 8B 4B 78                    mov     r9, [rbx+78h]
Patch #1           80

1405A9C19 4C 8D 05 30 06+                lea     r8, aArcnameS   ; "\\ArcName\\%s"
1405A9C20 48 8D 4C 24 40                 lea     rcx, [rsp+0D8h+pszDest] ; pszDest
1405A9C25 48 8B D7                       mov     rdx, rdi        ; cchDest
1405A9C28 E8 E3 AE B6 FF                 call    RtlStringCchPrintfA

...
1405A9C41 48 8D 0D C0 E7+                lea     rcx, IoArcBootDeviceName ; DestinationString
1405A9C48 41 B0 01                       mov     r8b, 1          ; AllocateDestinationString
1405A9C4B E8 60 13 DB FF                 call    RtlAnsiStringToUnicodeString
1405A9C50 48 8B 7B 78                    mov     rdi, [rbx+78h]
Patch #2           80

Donc, dans ntoskrnl.exe, remplacez 4C8B4B78 par 4C8B4B80 à deux endroits. N'oubliez pas de corriger PE-Checksum après.

Nadu
la source
Tu parles d'une réponse cryptée que peu de gens peuvent comprendre!
killjoy