Comment changer l'emplacement du fichier d'hibernation dans Windows 7?
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?
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 dans cet article de Windows Confidential: Le paradoxe du système de fichiers .
L'hibernation suit un schéma similaire. Mettre en hibernation le système d'exploitation signifie vider l'intégralité du contenu de la mémoire dans le fichier d'hibernation; restaurer en mode hibernation implique de récupérer ce fichier dans la mémoire et de prétendre que rien ne s'est passé. Encore une fois, c’est un autre problème particulier: pour charger le fichier d’hibernation, vous avez besoin du pilote du système de fichiers, mais le pilote du système de fichiers se trouve dans le fichier d’hibernation. Si vous conservez le fichier d'hibernation dans le répertoire racine du lecteur d'amorçage, vous pouvez utiliser le pilote du système de fichiers miniature.
Bon, il y a 2 choses à résoudre pour déplacer hiberfil.sys
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:\-> non encore résolu!
Pour appliquer cette chance également au fichier de données de configuration de démarrage (c:\BOOT\BCD) -> C’est relativement facile avec des outils tels que 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 Ou\2200000 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é) -> comme il semble que cela soit déjà 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,
...
En résumé, le chemin est codé en dur comme ceci: IoArcBootDeviceName + "\ hiberfil.sys" sans quelques correctifs binaires désagréables, il n’ya aucun moyen de changer cela. Bien que toucher les fenêtres sacrées du graal et appliquer des correctifs au "ntoskernel" puisse 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 celles de IoArcBootDeviceName:
IpLoadCrashdumpDriver PopDeleteHiberFile PopCreateHiberFile Popbcd
Wow changer semble bien se passer (la seule chose qui cloche un peu, c'est IopLoadCrashdumpDriver System32\Drivers\crashdmp.sys mais qui a besoin d'un crash, peu importe si nous cassons quelque chose là-bas)
Donc, appliquer un correctif IopCreateArcNames qui crée ArcBootDeviceName suffira:
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 de Win7 64 bits et a 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.