Como alterar a localização do arquivo de hibernação no Windows 7?

44

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?

    
por Phenom 19.12.2009 / 13:23

2 respostas

42

Você não pode, tem que estar na raiz da unidade de inicialização (a unidade C: no seu caso).

Raymond Chen explicou as razões pelas quais neste artigo do Windows Confidential: O Paradoxo do sistema de arquivos .

Hibernation follows a similar pattern. Hibernating the operating system means dumping the entire contents of memory into the hibernation file; restoring from hibernation entails sucking that file back into memory and pretending nothing happened. Again, it's another chicken-and-egg problem: to load the hibernation file, you need the file system driver, but the file system driver is in the hibernation file. If you keep the hibernation file in the root directory of the boot drive, the miniature file system driver can be used instead.

    
por 19.12.2009 / 14:15
6

Tudo bem, existem duas coisas para resolver para mover o hiberfil.sys

  1. Diga 'ntoskrnl.exe' que é executado como 'Sistema' de processo para abrir / salvar dados de hibernação em D: \ hiberfil.sys em vez de C: \ - > ainda não resolvido!

  2. 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 link do VisualBCD - > Ou apenas usando a edição de regedit HKLM \ BCD00000000 \ Objects {71575733-c376-11e4-80ea-806e6f6e6963} \ Elementos \ 21000001 que é o HiberFileDrive do ResumeLoader ou \ 22000002 HiberFilePath. Talvez você precise usar 'Arquivo / Carregar seção' c: \ BOOT \ BCD para montar a ramificação 'BCD00000000'. (O cursor precisa estar em HKLM, senão o item de menu está esmaecido) - > como parece, isso já é feito pelo ntosknl.exe, então não há necessidade de mudar isso, pois as alterações serão sobrescritas.

No entanto, o número 1 é 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 descompilá-lo para ver exatamente o que 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,
...

Ok, em suma, o caminho é codificado assim: IoArcBootDeviceName + "\ hiberfil.sys" sem algum patch binário desagradável, não há como mudar isso. Bem ao lado de tocar as janelas sagradas graal remendar o "ntoskernel" pode resultar em problemas como atualizações desfazer o patch ou programas antivírus pode ficar louco ... No entanto, vamos ver quais são as referências a IoArcBootDeviceName:

IopLoadCrashdumpDriver PopDeleteHiberFile PopCreateHiberFile PopBcdSetupResumeObject PopBcdSetDefaultResumeObjectElements PopBcdSetPendingResume PopBcdRegenerateResumeObject PopBcdEstablishResumeObject PopAllocateHiberContext IopCreateArcNames PopBcdSetupResumeObject

Uau mudar isso parece estar bem (A única coisa que sai um pouco é o IopLoadCrashdumpDriver System32 \ Drivers \ crashdmp.sys, mas quem precisa de um crashdump - não importa se quebramos alguma coisa lá)

Portanto, corrigir 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     }

...

link btw Estou usando o ntkrnlmp.exe 6.1.7601.19045 do Win7 64 bit e verifiquei este código com o ReactOS. (No entanto, a parte de hibernação ainda não está implementada nas fontes Reactos) Note 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 esperamos que o hibernate.sys esteja criando, o 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

Portanto, no ntoskrnl.exe, substitua 4C8B4B78 por 4C8B4B80 em dois locais. Não se esqueça de corrigir o PE-Checksum depois.

    
por 31.05.2016 / 23:13