विंडोज 7 में हाइबरनेशन फ़ाइल का स्थान कैसे बदलें?


45

मैं विंडोज 7 में हाइबरनेशन सक्षम नहीं कर सकता क्योंकि हाइबरनेशन फ़ाइल बनाने के लिए मेरे C: ड्राइव पर पर्याप्त जगह नहीं है। मैं विंडोज को फाइल को कहीं और कैसे रख सकता हूं?



आप नहीं कर सकते। लेकिन आप हाइबरनेशन ( powercfg.exe -h off) को अक्षम कर सकते हैं , और फिर फ़ाइल को हटा सकते हैं।
इयान बॉयड

जवाबों:


42

आप नहीं कर सकते, इसे बूट ड्राइव (आपके मामले में C: ड्राइव) की जड़ में होना चाहिए।

रेमंड चेन ने विंडोज कॉन्फिडेंशियल आर्टिकल: द फाइल सिस्टम पैराडॉक्स में इसकी वजह बताई ।

हाइबरनेशन एक समान पैटर्न का अनुसरण करता है। ऑपरेटिंग सिस्टम को हाइबरनेट करने का अर्थ है मेमोरी की पूरी सामग्री को हाइबरनेशन फ़ाइल में डंप करना; हाइबरनेशन से पुनर्स्थापित करने से उस फ़ाइल को वापस स्मृति में चूसने पर मजबूर होना पड़ता है और बहाना बन जाता है। फिर से, यह एक और चिकन और अंडे की समस्या है: हाइबरनेशन फ़ाइल को लोड करने के लिए, आपको फ़ाइल सिस्टम ड्राइवर की आवश्यकता है, लेकिन फ़ाइल सिस्टम ड्राइवर हाइबरनेशन फ़ाइल में है। यदि आप हाइबरनेशन फ़ाइल को बूट ड्राइव के रूट डायरेक्टरी में रखते हैं, तो इसके बजाय लघु फ़ाइल सिस्टम ड्राइवर का उपयोग किया जा सकता है।


14
खराब खिड़कियों के लिए यह संभाल नहीं सकता है, मैं वास्तव में अपने SSD के लिए इसकी आवश्यकता होगी। मुझे आशा है कि वे इसे भविष्य में ठीक कर लेंगे ताकि आप यह चुन सकें कि मैक ओएस एक्स में इसे कहाँ रखा जाए।
हॉल्टनर

5
यह मेरी राय में, यह एक डिजाइन दोष का एक सा है। यहां तक ​​कि अगर सिस्टम को मुख्य ड्राइव से बूट करने की आवश्यकता है, तो एक ही ड्राइव पर सभी गीगाबाइट जानकारी संग्रहीत करने का कोई कारण नहीं है- हाइबरनेशन फ़ाइल मूल बातें लोड कर सकती है (जैसे ड्राइव पहुंच) और फिर अतिरिक्त के लिए किसी अन्य ड्राइव को देखें डेटा। दुर्भाग्य से, उन्होंने इसे उस मामले को संभालने के लिए डिज़ाइन नहीं किया- जिसका अर्थ है कि वे एक नए ओएस तक नहीं करेंगे ... यदि कभी।
नेम

1
@ नेमी: यदि हाइबरनेशन फ़ाइल मूल बातें लोड कर सकती है, तो यह पहले से सीधे बूट लोडर में लिखा जा सकता है। फिर आप कीड़े के पूरे नहर खोल सकते हैं। एक और नहीं, मैं इसे एक डिजाइन दोष भी नहीं मानूंगा। यह विंडोज़ एनटी I के दिनों में वापस लिखा गया था, जिसमें गति, मेमोरी सीमा और कम सीपीयू शक्ति बड़े कारक थे, न कि छोटे एसएसडी ड्राइव। बिल्ली, कौन भविष्यवाणी करेगा कि SSD पहले स्थान पर इतने सामान्य हैं ??
सर्फस

1
यह "चिकन और अंडे" के बारे में बहुत सुंदर शब्द है जो कोई फर्क नहीं पड़ता: यदि बूट लोडर डिस्क से मेमोरी में हाइबरनेट फ़ाइल को लोड करना जानता है, तो बूट लोडर के अंदर फाइल सिस्टम ड्राइवर नहीं होने का कोई कारण नहीं है।
डेनिस बरमेनकोव

3
यह Microsoft का एक बेवकूफ बहाना है। क्या होगा यदि दोनों डिस्क एक ही नियंत्रक पर हैं - एक ही ड्राइवर का उपयोग किया जाता है? क्या होगा अगर एक डिस्क ssd है और आप इसे जल्दी नहीं पहनना चाहते हैं?
NickSoft

6

ठीक है कि हाइबरफिल को स्थानांतरित करने के लिए 2 चीजें हैं

  1. 'Ntoskrnl.exe' को बताएं जो हाइबरनेशन डेटा को D: \ hiberfil.sys के बजाय C: \ -> को अनसॉल्व करने के लिए प्रोसेस / सिस्टम को रन करता है।

  2. इस अवसर को बूट कॉन्फ़िगरेशन डेटा फ़ाइल पर लागू करने के लिए (c: \ BOOT \ BCD) -> यह VisualBCD https://www.boyans.net/DownloadVisualBCD.html जैसे उपकरणों के साथ अपेक्षाकृत आसान है -> या केवल regedit का उपयोग करके HKLM \ BCD00000000 \ Objects का संपादन {71575733-c376-11e4-80ea-806e6f6e6963} \ Elements \ 21000001, जो कि Resumeadader का HiberFileDrive या \ 22000002 HiberFilePath है। हो सकता है कि आपको 'BCD00000000' शाखा को माउंट करने के लिए 'फ़ाइल / लोड हाइव' c: \ BOOT \ BCD का उपयोग करने की आवश्यकता हो। (कर्सर को 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" बिना कुछ बुरा बाइनरी पैचिंग के जो कि बदलने का कोई तरीका नहीं है। अच्छी तरह से "नैटोसर्कल" को छूते हुए पवित्र खिड़कियों की कब्र को छूने से बगल में पैच या एंटीवायरस प्रोग्राम के अपडेट्स जैसी समस्याएं हो सकती हैं ... हालांकि आइए देखते हैं कि IoArcBootDeviceName के क्या संदर्भ हैं:

IopLoadCrashdumpDriver PopDeleteHiberFile PopCreateHiberFile PopBcdSetupResumeObject PopBcdSetDefaultResumeObjectElements PopBcdSetPendingResume PopBcdRegenerateResumeObject PopBcdEstablishResumeObject PopAllocateHiberContext IopCreateArcNames PopBcdSetupResumeObject

वाह परिवर्तन जो ठीक प्रतीत हो रहा है (केवल एक चीज जो थोड़ी दूर जाती है वह है IopLoadCrashdumpDriver System32 \ Drivers \ crashdmp.sys हालांकि जिन्हें क्रैशडम्प की आवश्यकता है - इससे कोई फर्क नहीं पड़ता कि हम वहां कुछ तोड़ते हैं)

पैचिंग तो 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 btw मैं Win7 64 बिट के लिए ntkrnlmp.exe 6.1.7601.19045 का उपयोग कर रहा हूँ और ReactOS के खिलाफ इस कोड की जाँच की। (हालांकि हाइबरनेटिंग भाग अभी तक रिएक्टोस स्रोतों में लागू नहीं किया गया है) ध्यान दें कि ArcBootDeviceName कुछ इस तरह होगा: \ Device \ Harddisk1 \ Partition0

हम्म आइए आर्कबूटडेविसेनैम (लोडरब्लॉक + 0x78) को आर्कहेल्डिवेस्नेम (लोडरब्लॉक + 0x80) पैच करें

इसलिए अगर बूम्ग्रेड लोडर विंडोज़ के मुकाबले अलग विभाजन पर होता है, तो उम्मीद है कि हाइबरनेट। Sys बनाता है कि बूटमग्रे है।

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 में दो स्थानों पर 4C8B4B80 के साथ 4C8B4B78 को बदलें। पीई-चेकसम को बाद में ठीक करना न भूलें।


एक गूढ़ उत्तर के बारे में बात करें जो कई लोग नहीं समझ सकते हैं!
किलोज

क्या किसी ने इस तरह ntoskrnl.exe पैच करने की कोशिश की? क्या इसके बाद काम हुआ?
PF4Public
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.