¿Cómo cambiar la ubicación del archivo de hibernación en Windows 7?

No puedo habilitar la hibernación en Windows 7 porque no hay suficiente espacio en mi unidad C: para crear el archivo de hibernación. ¿Cómo puedo hacer que Windows coloque el archivo en otro lugar?

No puede, tiene que estar en la raíz de la unidad de arranque (la unidad C: en su caso).

Raymond Chen explicó las razones por las cuales en este artículo confidencial de Windows: La paradoja del sistema de archivos .

La hibernación sigue un patrón similar. Hibernar el sistema operativo significa descargar todo el contenido de la memoria en el archivo de hibernación; La restauración de la hibernación implica volver a guardar ese archivo en la memoria y fingir que no pasó nada. Nuevamente, es otro problema de huevo y gallina: para cargar el archivo de hibernación, necesita el controlador del sistema de archivos, pero el controlador del sistema de archivos está en el archivo de hibernación. Si mantiene el archivo de hibernación en el directorio raíz de la unidad de arranque, se puede utilizar el controlador del sistema de archivos en miniatura.

De acuerdo, hay 2 cosas que resolver para mover hiberfil.sys

1. ¡Indique a 'ntoskrnl.exe' que se ejecuta como Proceso 'Sistema' que abra / guarde los datos de hibernación en D: \ hiberfil.sys en lugar de C: \ -> sin resolver todavía!

2. Para aplicar esta oportunidad también al archivo de datos de configuración de arranque (c: \ BOOT \ BCD) -> Esto es relativamente fácil con herramientas como VisualBCD https://www.boyans.net/DownloadVisualBCD.html -> O incluso simplemente usando regedit editando HKLM \ BCD00000000 \ Objects {71575733-c376-11e4-80ea-806e6f6e6963} \ Elements \ 21000001 que es el HiberFileDrive del ResumeLoader o \ 22000002 HiberFilePath. Tal vez necesite usar 'Archivo / Cargar sección' c: \ BOOT \ BCD para montar la rama 'BCD00000000' (El cursor debe estar en HKLM, de lo contrario, el elemento del menú está atenuado) -> ya que parece que esto ya está hecho por ntosknl.exe, por lo que no hay necesidad de cambiar esto ya que los cambios se sobrescribirán.

Sin embargo, el número 1. es lo peor y más difícil de cambiar. Hmm, carguemos ntoskrnl.exe en IDA y localice la función que trata con /hiberfil.sys y descompílelo para ver qué está sucediendo exactamente allí ...

__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 resumen, la ruta está codificada de esta manera: IoArcBootDeviceName + "\ hiberfil.sys" sin algunos parches binarios desagradables, no hay forma de cambiar eso. Bueno, además de tocar el santo grial de Windows, parchear el "ntoskernel" podría dar lugar a problemas como actualizaciones que deshacen el parche o los programas antivirus pueden volverse locos ... Sin embargo, veamos qué referencias son a IoArcBootDeviceName:

IopLoadCrashdumpDriver PopDeleteHiberFile PopCreateHiberFile PopBcdSetupResumeObject PopBcdSetDefaultResumeObjectElements PopBcdSetPendingResume PopBcdRegenerateResumeObject PopBcdEstablishResumeObject PopAllocotear

Wow cambiar eso parece estar bien (lo único que se dispara un poco es IopLoadCrashdumpDriver System32 \ Drivers \ crashdmp.sys, sin embargo, quién necesita crashdump, no importa si rompemos algo allí)

Entonces, parchear IopCreateArcNames que crea ArcBootDeviceName estará 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 por cierto estoy usando ntkrnlmp.exe 6.1.7601.19045 de Win7 64 bit y verifiqué este código con ReactOS. (Sin embargo, la parte de hibernación aún no está implementada en las fuentes de Reactos) Tenga en cuenta que ArcBootDeviceName será algo así como: \ Device \ Harddisk1 \ Partition0

Hmm vamos a parchar ArcBootDeviceName (LoaderBlock + 0x78) a ArcHalDeviceName (LoaderBlock + 0x80)

Entonces, en caso de que el cargador bootmgr esté en una partición diferente a la de Windows, hibernate.sys se crea donde está 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

Entonces, en ntoskrnl.exe, reemplace 4C8B4B78 con 4C8B4B80 en dos ubicaciones. No olvides arreglar PE-Checksum después.