Je ne peux pas activer l'hibernation dans Windows 7 parce qu'il n'y a pas assez de place sur mon disque C : pour créer le fichier d'hibernation. Comment puis-je faire en sorte que Windows place le fichier ailleurs ?
Réponses
Trop de publicités?
Vous ne pouvez pas, il doit être à la racine du disque de démarrage (le disque C : dans votre cas).
Raymond Chen en explique les raisons dans cet article de Windows Confidential : Le paradoxe du système de fichiers .
L'hibernation suit un schéma similaire. L'hibernation du système d'exploitation signifie décharger tout le contenu de la mémoire dans le fichier d'hibernation. de l'hibernation implique d'aspirer ce contenu dans le fichier d'hibernation. dans la mémoire et de prétendre que le système d'exploitation est en rien ne s'est passé. Encore une fois, il s'agit d'un problème de [ ] [ ] système de fichiers, mais le pilote du système de fichiers se trouve dans le fichier d'hibernation. Si vous [ ] répertoire racine du disque de démarrage, le le pilote de système de fichiers miniature peut être être utilisé à la place.
Nadu
Points
186
Ok il y a 2 choses à résoudre pour déplacer hiberfil.sys
-
Indiquer à 'ntoskrnl.exe' qui s'exécute en tant que processus 'System' d'ouvrir/enregistrer les données d'hibernation dans D:\hiberfil.sys au lieu de C:\N ->non résolu pour l'instant !
-
Pour appliquer cette chance également à la configuration de démarrage Fichier de données (c : \BOOT\BCD ) -> Ceci est relativement facile avec des outils comme VisualBCD https://www.boyans.net/DownloadVisualBCD.html -> Ou même simplement en utilisant l'édition de regedit HKLM \BCD00000000\Objects {71575733-c376-11e4-80ea-806e6f6e6963} \Elements\21000001 qui est le HiberFileDrive du ResumeLoader Or \22000002 HiberFilePath. Vous devez peut-être utiliser la fonction 'File/Load hive' c : \BOOT\BCD pour monter la branche 'BCD00000000' (le curseur doit être sur HKLM, sinon l'élément de menu est grisé). -> il semble que cela soit déjà fait par ntosknl.exe, il n'est donc pas nécessaire de le modifier puisque vos modifications seront écrasées.
Cependant, le numéro 1 est la chose la plus grave et la plus difficile à changer. Chargeons ntoskrnl.exe dans IDA et localisons la fonction qui traite de /hiberfil.sys et décompilons-la pour voir ce qui s'y passe exactement...
__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,
...En bref, le chemin est codé en dur comme ceci : IoArcBootDeviceName + " \hiberfil.sys " sans un méchant Parcheando binaire, il n'y a aucun moyen de changer cela. A part toucher le saint Graal de Windows Parcheando le "ntoskernel" peut entraîner des problèmes comme des mises à jour qui annulent le patch ou des programmes antivirus qui deviennent fous... Cependant, voyons quelles sont les références à IoArcBootDeviceName :
IopLoadCrashdumpDriver PopDeleteHiberFile PopCreateHiberFile PopBcdSetupResumeObject PopBcdSetDefaultResumeObjectElements PopBcdSetPendingResume PopBcdRegenerateResumeObject (Objet de reprise) PopBcdEstablishResumeObject (Objet de reprise) PopAllocateHiberContext IopCreateArcNames PopBcdSetupResumeObject
Waouh, changer cela semble être une bonne chose (la seule chose qui ne fonctionne pas est IopLoadCrashdumpDriver System32) \Drivers\crashdmp.sys Cependant, qui a besoin de crashdump - peu importe si nous cassons quelque chose à cet endroit)
Donc Parcheando IopCreateArcNames qui crée ArcBootDeviceName sera très 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 J'utilise ntkrnlmp.exe 6.1.7601.19045 depuis Win7 64 bit et j'ai vérifié ce code avec ReactOS. (Cependant, la partie hibernation n'est pas encore implémentée dans les sources de Reactos). Notez que ArcBootDeviceName sera quelque chose comme : \Device\Harddisk1\Partition0
Hmm, modifions ArcBootDeviceName(LoaderBlock + 0x78) en ArcHalDeviceName(LoaderBlock + 0x80).
Ainsi, si le chargeur de bootmgr se trouve sur une partition différente de celle de Windows, il faut espérer que hibernate.sys est créé là où se trouve 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 80Dans ntoskrnl.exe, remplacez donc 4C8B4B78 par 4C8B4B80 à deux endroits. N'oubliez pas de corriger le PE-Checksum par la suite.
