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

Question

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

Answer 1

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

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

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

Answer 2

Хорошо, есть 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Выбрать объектОбъявитьОбъявлениеПроскач

Изменения в вау, которые кажутся хорошими (единственное, что немного выходит из строя, это 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 впоследствии.