Я не могу включить спящий режим в Windows 7, потому что на диске C: недостаточно места для создания файла спящего режима. Как я могу заставить Windows поместить файл куда-нибудь еще?
powercfg.exe -h off
), а затем удалить файл.
Я не могу включить спящий режим в Windows 7, потому что на диске C: недостаточно места для создания файла спящего режима. Как я могу заставить Windows поместить файл куда-нибудь еще?
powercfg.exe -h off
), а затем удалить файл.
Ответы:
Вы не можете, это должно быть в корне загрузочного диска (диск C: в вашем случае).
Рэймонд Чен объяснил причины этой секретной статьи Windows: парадокс файловой системы .
Спячка идет по аналогичной схеме. Спящий режим операционной системы означает сброс всего содержимого памяти в файл гибернации; восстановление из спящего режима влечет за собой высвобождение этого файла обратно в память и притворяется, что ничего не произошло. Опять-таки, это еще одна проблема: для загрузки файла гибернации необходим драйвер файловой системы, но драйвер файловой системы находится в файле гибернации. Если вы сохраняете файл гибернации в корневом каталоге загрузочного диска, вместо него можно использовать драйвер миниатюрной файловой системы.
Хорошо, есть 2 вещи, которые нужно решить, чтобы переместить hiberfil.sys
Скажите 'ntoskrnl.exe', который запускается как Процесс 'Система', чтобы открыть / сохранить данные гибернации в D: \ hiberfil.sys вместо C: \ -> еще не решено!
Чтобы применить этот шанс также к файлу данных конфигурации загрузки (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 впоследствии.