Não consigo ativar a hibernação no Windows 7 porque não há espaço suficiente na minha unidade C: para criar o arquivo de hibernação. Como posso fazer o Windows colocar o arquivo em outro lugar?
powercfg.exe -h off
) e excluir o arquivo.
Não consigo ativar a hibernação no Windows 7 porque não há espaço suficiente na minha unidade C: para criar o arquivo de hibernação. Como posso fazer o Windows colocar o arquivo em outro lugar?
powercfg.exe -h off
) e excluir o arquivo.
Respostas:
Você não pode, ele deve estar na raiz da unidade de inicialização (a unidade C: no seu caso).
Raymond Chen explicou os motivos pelos quais, neste artigo confidencial do Windows: The Paradox do sistema de arquivos .
A hibernação segue um padrão semelhante. Hibernar o sistema operacional significa despejar todo o conteúdo da memória no arquivo de hibernação; restaurar da hibernação implica sugar esse arquivo de volta à memória e fingir que nada aconteceu. Novamente, é outro problema do ovo e da galinha: para carregar o arquivo de hibernação, você precisa do driver do sistema de arquivos, mas o driver do sistema de arquivos está no arquivo de hibernação. Se você mantiver o arquivo de hibernação no diretório raiz da unidade de inicialização, o driver do sistema de arquivos em miniatura poderá ser usado.
Ok, há duas coisas a resolver para mover o hiberfil.sys
Diga 'ntoskrnl.exe' que é executado como Processo 'Sistema' para abrir / salvar dados de hibernação em D: \ hiberfil.sys em vez de C: \ -> ainda não resolvido!
Para aplicar essa chance também ao arquivo de dados de configuração de inicialização (c: \ BOOT \ BCD) -> Isso é relativamente fácil com ferramentas como o VisualBCD https://www.boyans.net/DownloadVisualBCD.html -> Ou mesmo usando regedit editando HKLM \ BCD00000000 \ Objects {71575733-c376-11e4-80ea-806e6f6e6963} \ Elements \ 21000001 que é o HiberFileDrive do ResumeLoader Or \ 22000002 HiberFilePath. Talvez você precise usar 'File / Load hive' c: \ BOOT \ BCD para montar a ramificação 'BCD00000000'. (O cursor precisa estar no HKLM, caso contrário, o item de menu fica acinzentado) -> pois parece que isso já foi feito pelo ntosknl.exe, portanto, não há necessidade de alterar isso, pois as alterações serão substituídas.
No entanto, o número 1. é o pior e mais difícil de mudar. Hmm, vamos carregar o ntoskrnl.exe no IDA e localizamos a função que lida com o /hiberfil.sys e o descompila para ver o que exatamente está acontecendo lá ...
__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,
...
Em resumo, o caminho é codificado como este: IoArcBootDeviceName + "\ hiberfil.sys" sem alguns patches binários desagradáveis, não há como mudar isso. Bem, ao lado de tocar no holy windows grail que corrige o "ntoskernel" pode resultar em problemas como atualizações desfazer o patch ou programas antivírus podem ficar loucos ... No entanto, vamos ver quais referências são o IoArcBootDeviceName:
IopLoadCrashdumpDriver PopDeleteHiberFile PopCreateHiberFile PopBcdSetupResumeObject PopBcdSetDefaultResumeObjectElements PopBcdSetPendingResume PopBcdRegenerateResumeObject PopBcdEstablishResumeObject PopAllocateHiberContext
Nossa mudança que parece estar bem (a única coisa que sai um pouco é o IopLoadCrashdumpDriver System32 \ Drivers \ crashdmp.sys, no entanto, quem precisa do crashdump - não importa se quebrarmos algo lá)
Portanto, aplicar o patch IopCreateArcNames que cria ArcBootDeviceName ficará bem:
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 Estou usando o ntkrnlmp.exe 6.1.7601.19045 do Win7 64 bits e verifiquei esse código no ReactOS. (No entanto, a parte de hibernação ainda não foi implementada nas fontes Reactos) Observe que ArcBootDeviceName será algo como: \ Device \ Harddisk1 \ Partition0
Hmm, vamos corrigir o ArcBootDeviceName (LoaderBlock + 0x78) para ArcHalDeviceName (LoaderBlock + 0x80)
Portanto, caso o carregador do bootmgr esteja em uma partição diferente da que o Windows cria, esperamos que o hibernate.sys seja criado onde o bootmgr está.
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
Portanto, no ntoskrnl.exe, substitua 4C8B4B78 por 4C8B4B80 em dois locais. Não se esqueça de corrigir o PE-Checksum posteriormente.