Как изменить местоположение файла гибернации в Windows 7?

Я не могу включить спящий режим в Windows 7, потому что на диске C: недостаточно места для создания файла спящего режима. Как я могу заставить Windows поместить файл куда-нибудь еще?

Вы не можете, это должно быть в корне загрузочного диска (диск C: в вашем случае).

Рэймонд Чен объяснил причины этой секретной статьи Windows: парадокс файловой системы .

Спячка идет по аналогичной схеме. Спящий режим операционной системы означает сброс всего содержимого памяти в файл гибернации; восстановление из спящего режима влечет за собой высвобождение этого файла обратно в память и притворяется, что ничего не произошло. Опять-таки, это еще одна проблема: для загрузки файла гибернации необходим драйвер файловой системы, но драйвер файловой системы находится в файле гибернации. Если вы сохраняете файл гибернации в корневом каталоге загрузочного диска, вместо него можно использовать драйвер миниатюрной файловой системы.

Хорошо, есть 2 вещи, которые нужно решить, чтобы переместить hiberfil.sys

1. Скажите 'ntoskrnl.exe', который запускается как Процесс 'Система', чтобы открыть / сохранить данные гибернации в D: \ hiberfil.sys вместо C: \ -> еще не решено!

2. Чтобы применить этот шанс также к файлу данных конфигурации загрузки (c: \ BOOT \ BCD) -> Это относительно легко с такими инструментами, как VisualBCD https://www.boyans.net/DownloadVisualBCD.html -> Или даже просто с помощью regedit. редактирование HKLM \ BCD00000000 \ Objects {71575733-c376-11e4-80ea-806e6f6e6963} \ Elements \ 21000001, который является HiberFileDrive ResumeLoader или \ 22000002 HiberFilePath. Возможно, вам нужно использовать 'File / Load hive' c: \ BOOT \ BCD, чтобы смонтировать ветвь 'BCD00000000'. (Курсор должен быть на HKLM, иначе пункт меню неактивен) -> так как кажется, что это уже сделано от ntosknl.exe, так что нет необходимости в этом изменении, так как изменения будут перезаписаны.

Однако номер 1. хуже и сложнее изменить. Хм, давайте загрузим ntoskrnl.exe в IDA и найдем функцию, которая работает с /hiberfil.sys, и декомпилируем ее, чтобы увидеть, что именно там происходит ...

__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,
...

Короче говоря, путь жестко запрограммирован так: IoArcBootDeviceName + "\ hiberfil.sys" без каких-либо неприятных бинарных исправлений, изменить это невозможно. Помимо прикосновения к исправлению святого окна, исправление «ntoskernel» может привести к таким проблемам, как обновление, отмена исправления или антивирусные программы могут стать сумасшедшими ... Однако давайте посмотрим, какие ссылки относятся к IoArcBootDeviceName:

IopLoadCrashdumpDriver PopDeleteHiberFile PopCreateHiberFile PopBcdSetupResumeObject PopBcdSetDefaultResumeObjectElements PopBcdSetPendingResume PopBcdRegenerateResume PopjectObjectObBRumeReBB

Изменения в вау, которые кажутся хорошими (единственное, что немного выходит из строя, это IopLoadCrashdumpDriver System32 \ Drivers \ crashdmp.sys, однако, кому нужен crashdump - не имеет значения, если мы что-то там сломаем)

Так что исправление IopCreateArcNames, которое создает ArcBootDeviceName, будет хорошо:

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 Кстати, я использую ntkrnlmp.exe 6.1.7601.19045 из 64-битной Win7 и проверил этот код на ReactOS. (Однако часть спящего режима еще не реализована в исходниках Reactos). Обратите внимание, что ArcBootDeviceName будет выглядеть примерно так: \ Device \ Harddisk1 \ Partition0

Хм, давайте исправим ArcBootDeviceName (LoaderBlock + 0x78) в ArcHalDeviceName (LoaderBlock + 0x80)

Таким образом, в случае, если загрузчик bootmgr находится в другом разделе, чем windows, мы надеемся, что hibernate.sys создает 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

Таким образом, в ntoskrnl.exe замените 4C8B4B78 на 4C8B4B80 в двух местах. Не забудьте исправить PE-Checksum впоследствии.