Windows 7'de hazırda bekleme dosyasının konumu nasıl değiştirilir?


45

Windows 7'de hazırda bekletme modunu etkinleştiremiyorum çünkü C: sürücümde hazırda bekletme dosyasını oluşturmak için yeterli alan yok. Windows'un dosyayı başka bir yere koymasını nasıl sağlayabilirim?



Yapamazsın Ancak hazırda bekletme modunu ( powercfg.exe -h off) devre dışı bırakabilir ve ardından dosyayı silebilirsiniz.
Ian Boyd

Yanıtlar:


42

Yapamazsınız, önyükleme sürücüsünün kökünde olması gerekir (sizin durumunuzdaki C: sürücüsü).

Raymond Chen, bu Windows Gizli makalesinde nedenini açıkladı: Dosya Sistemi Paradoksu .

Hazırda bekletme modu benzer bir düzen izler. İşletim sistemini hazırda bekletme modu, tüm bellek içeriğini hazırda bekletme dosyasına aktarmak anlamına gelir; Hazırda bekletme modundan geri yükleme, bu dosyayı belleğe geri çekmeyi ve hiçbir şey olmamış gibi davranmayı gerektirir. Yine, başka bir tavuk-yumurta problemi: Hazırda bekleme dosyasını yüklemek için, dosya sistemi sürücüsüne ihtiyacınız var, ancak dosya sistemi sürücüsü hazırda bekleme dosyasında. Hazırda bekletme dosyasını önyükleme sürücüsünün kök dizininde tutarsanız, bunun yerine minyatür dosya sistemi sürücüsü kullanılabilir.


14
Kötü pencereler bununla başa çıkamıyor, SSD için gerçekten ihtiyacım var. Gelecekte düzelteceklerini umuyorum, böylece Mac OS X'te nereye koyacağınızı seçebilirsiniz
Hultner

5
Yah, bence biraz tasarım hatası. Sistemin ana sürücüden önyükleme yapması gerekse bile, tüm gigabayt bilgilerin tümünü aynı sürücüde depolamak zorunda değilsiniz; hazırda bekletme dosyası temel bilgileri yükleyebilir (örneğin, sürücü erişimi) ve sonra ek bir sürücü arayabilir veri. Ne yazık ki, bu davayla başa çıkmak için tasarlamadılar, bu da yeni bir işletim sistemine kadar olmayacakları anlamına geliyor.
Namey

1
@ İsim: Hazırda bekletme dosyası temel bilgileri yükleyebiliyorsa, ilk etapta doğrudan önyükleyiciye doğrudan yazılabilir. Sonra bir sürü solucan kutusu açarsın. Öte yandan, onu bir tasarım hatası olarak görmezdim. Sanırım Windows NT'nin günlerinde yazılmıştı, sanırım hız, bellek limitleri ve düşük CPU gücü, küçük SSD diskleri değil büyük faktörlerdi. Heck, kim SSD'lerin ilk etapta bu kadar yaygın olacağını tahmin eder ki?
surfasb,

1
Önemli olan "tavuk ve yumurta" hakkında güzel sözler: önyükleyici, hazırda bekletilen dosyayı diskten belleğe nasıl yükleyeceğini bilirse, önyükleyici içinde dosya sistemi sürücüsü olmamasının bir nedeni yoktur.
Denis Barmenkov

3
Bu aptalca bir microsoft bahanesi. Her iki disk de aynı denetleyicideyse - aynı sürücü kullanılıyorsa? Ya bir disk SDSD ise ve hızlı takmak istemiyorsanız?
NickSoft

6

Tamam hiberfil.sys taşımak için çözmek için 2 şey vardır

  1. Hazırda bekletme verilerini açmak / kaydetmek için C: \ -> çözülmemiş yerine D: \ hiberfil.sys dizinine açmak / kaydetmek için 'Sistem' olarak çalışan 'ntoskrnl.exe'ye bildirin!

  2. Bu fırsatı önyükleme yapılandırmasına da uygulamak için Veri dosyası (c: \ BOOT \ BCD) -> VisualBCD gibi araçlarla bu oldukça kolaydır https://www.boyans.net/DownloadVisualBCD.html -> Veya sadece regedit kullanarak ResumeLoader'ın HiberFileDrive'ı veya \ 22000002 HiberFilePath öğesi olan HKLM \ BCD00000000 \ Objects {71575733-c376-11e4-80ea-806e6f6e6963} \ Elements \ 21000001 Belki de 'BCD00000000' dalını monte etmek için 'Dosya / Yük kovanı' c: \ BOOT \ BCD kullanmanız gerekir. (İmleç HKLM’de olmalıdır, bunun yerine menü öğesinin grileşmesi gerekir) -> ntosknl.exe tarafından, değişikliklerin üzerine yazılacağından, bunu değiştirmenize gerek kalmaz.

Ancak 1 numara, bir şeyi değiştirmek için daha kötü ve daha zordur. Hmm, ntoskrnl.exe dosyasını IDA'ya yükleyelim ve /hiberfil.sys ile uğraşan işlevi bulabilir ve orada tam olarak ne olup bittiğini görmek için onu kodabilir ...

__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,
...

Kısacası yol bu şekilde kodlanmış: IoArcBootDeviceName + "\ hiberfil.sys" bazı kötü ikili dosyalar olmadan bunu değiştirmenin bir yolu yok. "Ntoskernel" 'in eklenmesi ya da Antivirüs programlarının çılgına dönmesine neden olabilecek güncellemeler gibi sorunlara neden olabilir ... Ancak IoArcBootDeviceName için referansları görelim:

IopLoadCrashdumpDriver PopDeleteHiberFile PopCreateHiberFile PopBcdSetupResumeObject PopBcdSetDefaultResumeObjectElements PopBcdSetPendingResumeObjectRegenerateResumeObject PopBcdEstablishResumeObjectRegenerateResumeObject

Wow, iyi gibi görünüyor ki değişiyor (biraz sönen tek şey IopLoadCrashdumpDriver System32 \ Drivers \ crashdmp.sys, ancak crashdump'a ihtiyacı olan - orada bir şeyleri kırmamızın önemi yok)

Bu yüzden ArcBootDeviceName'i oluşturan IopCreateArcNames'i yamalamak iyi olacak:

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 bit'ten ntkrnlmp.exe 6.1.7601.19045 kullanıyorum ve bu kodu ReactOS'a karşı kontrol ediyorum. (Ancak hazırda bekletme kısmı henüz Reactos kaynaklarına uygulanmadı) ArcBootDeviceName öğesinin şöyle olacağını unutmayın: \ Device \ Harddisk1 \ Partition0

Hmm ArcBootDeviceName (LoaderBlock + 0x78) ya ArcHalDeviceName (LoaderBlock + 0x80) ekleyelim.

Öyleyse, bootmgr yükleyici, umarım hibernate.sys dosyasının yarattığından, pencerelerden farklı bir bölümdeyse, bootmgr olur.

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

Yani ntoskrnl.exe içinde iki yerde 4C8B4B78 yerine 4C8B4B80 ile değiştirin. Daha sonra PE-Checksum'u tamir etmeyi unutmayın.


Çoğu kimsenin anlayamadığı şifreli bir cevap hakkında konuşun!
killjoy

Herhangi biri ntoskrnl.exe dosyasını bu şekilde düzeltmeye çalıştı mı? Daha sonra çalıştı mı?
PF4Public
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.