Windows 7에서 최대 절전 모드 파일의 위치를 ​​변경하는 방법은 무엇입니까?


45

C : 드라이브에 최대 절전 모드 파일을 만들 공간이 부족하여 Windows 7에서 최대 절전 모드를 사용할 수 없습니다. Windows에서 파일을 다른 곳에 두려면 어떻게해야합니까?



당신은 할 수 없습니다. 그러나 최대 절전 모드 ( powercfg.exe -h off)를 비활성화 한 다음 파일을 삭제할 수 있습니다.
Ian Boyd

답변:


42

부팅 드라이브 (귀하의 경우 C : 드라이브)의 루트에 있어야합니다.

Raymond Chen은이 Windows Confidential 기사 (파일 시스템 역설) 에서 이유를 설명했습니다 .

최대 절전 모드는 비슷한 패턴을 따릅니다. 운영 체제를 최대 절전 모드로 전환한다는 것은 메모리의 전체 내용을 최대 절전 모드 파일로 덤프하는 것을 의미합니다. 최대 절전 모드에서 복원하려면 해당 파일을 메모리에 다시 넣고 아무 일도하지 않은 척합니다. 다시 말하지만, 그것은 또 다른 닭과 계란 문제입니다 : 최대 절전 모드 파일을로드하려면 파일 시스템 드라이버가 필요하지만 파일 시스템 드라이버는 최대 절전 모드 파일에 있습니다. 최대 절전 모드 파일을 부팅 드라이브의 루트 디렉토리에 보관하면 미니어처 파일 시스템 드라이버를 대신 사용할 수 있습니다.


14
나쁜 창은 이것을 처리 할 수 ​​없으므로 SSD에 실제로 필요합니다. Mac OS X와 ​​같이 어디에 배치 할 것인지 선택할 수 있도록 향후
에이

5
예, 제 생각에는 약간의 디자인 결함입니다. 시스템이 기본 드라이브에서 부팅해야하더라도 모든 기가 바이트의 정보를 동일한 드라이브에 저장해야 할 이유가 없습니다. 최대 절전 모드 파일은 기본 사항 (예 : 드라이브 액세스)을로드 한 다음 다른 드라이브를 찾아 추가 드라이브를 찾을 수 있습니다. 데이터. 불행히도, 그들은 그 사건을 처리하기 위해 그것을 설계하지 않았습니다. 즉, 새로운 OS가 될 때까지는 아닙니다.
이름 :

1
@Namey : 최대 절전 모드 파일이 기본 사항을로드 할 수 있으면 처음에 부트 로더에 바로 쓰여질 수도 있습니다. 그런 다음 웜 캔 전체를 엽니 다. 다른 하나는 디자인 결함이라고 생각하지 않습니다. 속도, 메모리 제한 및 낮은 CPU 전력이 작은 SSD 드라이브가 아닌 큰 요인이었던 Windows NT I 시대에 쓰여졌습니다. 도대체 누가 SSD가 처음부터 그렇게 일반적 일 것이라고 예상 했습니까?
surfasb

1
중요한 것은 "치킨과 계란"에 관한 단어입니다. 부트 로더가 최대 절전 모드 파일을 디스크에서 메모리로로드하는 방법을 알고 있다면 부트 로더 내에 파일 시스템 드라이버가 없어야 할 이유가 없습니다.
Denis Barmenkov

3
그것은 Microsoft의 어리석은 변명입니다. 두 디스크가 모두 같은 컨트롤러에있는 경우 동일한 드라이버가 사용됩니까? 하나의 디스크가 ssd이고 빨리 착용하지 않으려면 어떻게해야합니까?
NickSoft

6

이제 hiberfil.sys 이동을 위해 해결해야 할 2 가지가 있습니다.

  1. 프로세스 '시스템'으로 실행되는 'ntoskrnl.exe'에게 최대 절전 모드 데이터를 C : \-> unsolved yet 대신 D : \ hiberfil.sys에 열기 / 저장하도록 지시하십시오!

  2. 이 기회를 부팅 구성 데이터 파일 (c : \ BOOT \ BCD) 에도 적용 하려면 -> VisualBCD와 같은 도구를 사용하면 비교적 쉽습니다. https://www.boyans.net/DownloadVisualBCD.html- > 또는 심지어 regedit ResumeLoader의 HiberFileDrive 또는 \ 22000002 HiberFilePath 인 HKLM \ BCD00000000 \ Objects {71575733-c376-11e4-80ea-806e6f6e6963} \ Elements \ 21000001 편집 '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 PopBcdRegenerateResumeObject PopBcdEstablishResumeObject PopAllocateHiberContext IopCreateArcNames PopBcdSetupResumeObject

와우를 변경하는 것이 괜찮은 것처럼 보입니다 (약간 사라지는 것은 IopLoadCrashdumpDriver System32 \ Drivers \ crashdmp.sys이지만 크래시 덤프가 필요한 사람은 무언가를 깨뜨려도 문제가되지 않습니다)

따라서 ArcBootDeviceName 을 생성하는 IopCreateArcNames를 패치 하면 괜찮습니다.

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 Win7 64 비트의 ntkrnlmp.exe 6.1.7601.19045를 사용하고 있으며이 코드를 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을 수정하는 것을 잊지 마십시오.


많은 사람들이 이해할 수없는 비밀스러운 대답에 대해 이야기하십시오!
killjoy

이 방법으로 ntoskrnl.exe를 패치하려고 했습니까? 나중에 작동 했습니까?
PF4Public
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.