Windows डिस्क में रजिस्ट्री परिवर्तन कब लिखता है?

Question

टी एल; डॉ:

मैंने देखा है कि अगर मैं रजिस्ट्री परिवर्तन करता हूं और फिर अपने विंडोज 10 सिस्टम को हार्ड-बंद करता हूं, तो रजिस्ट्री परिवर्तन रिबूट के बाद दिखाई नहीं देता है।

मैंने यह भी देखा है कि एक हाइबरनेशन फ़ाइल का विलोपन एक लिनक्स रिकवरी टूल की क्षमता को ऑफ़लाइन स्थिति में विंडोज रजिस्ट्री में परिवर्तन करने के लिए प्रभावित कर सकता है। हाइबरनेशन फ़ाइल को हटाने के बाद उपकरण लगातार परिवर्तन करने में असमर्थ लगता है। मैं नीचे विशिष्ट उदाहरण सूचीबद्ध करूंगा।

उदाहरण 1:

• मैं "HKLM \ SOFTWARE" में "1111" नामक एक कुंजी जोड़ता हूं। मैंने फिर 5 सेकंड के लिए पावर बटन पकड़कर अपने बॉक्स को हार्ड पावर डाउन किया।
• 
• जब मैं रजिस्ट्री को वापस खींचता हूं, तो वह कुंजी और उसके मान समाप्त हो जाते हैं:
• 
• (ये चित्र प्रारूपण प्रयोजनों के लिए संपादित किए गए थे)

उदाहरण 2 :

• रजिस्ट्री में बदलाव करें (regedit का उपयोग करके)
• सिस्टम को हाइबरनेट करें
• लिनक्स रिकवरी टूल में बूट करें
• डिस्क को माउंट करने के लिए हाइबरनेशन फ़ाइल को हटा दें।
• विंडो रजिस्ट्री पढ़ें (रिकवरी टूल से)
• रजिस्ट्री परिवर्तन हो गया है।

यह बॉक्स पर एक कठिन शटडाउन के बराबर लगता है।

उदाहरण 3:

मैं अजनबी व्यवहार देखता हूं जब मैं:

• बॉक्स को हाइबरनेट करें
• एक लिनक्स रिकवरी टूल को बूट करें और हाइबरनेशन फ़ाइल को हटा दें
• रजिस्ट्री में परिवर्तन करें (रिकवरी टूल से)
• बॉक्स को रिबूट करें

रजिस्ट्री में उन परिवर्तनों को प्रतिबिंबित नहीं किया गया है।

तो यहाँ क्या हो रहा है?

• विंडोज 10 डिस्क में रजिस्ट्री परिवर्तन कब लिखता है?
• हाइबरनेशन फ़ाइल (उदाहरण 3 में) को हटाने से पुनर्प्राप्ति टूल से रजिस्ट्री परिवर्तन को अगले बूट पर प्रतिबिंबित होने से कैसे रोका जाता है?

कुछ स्पष्टीकरण पाने की उम्मीद!

Comments

"वह रिबूट के बाद रजिस्ट्री परिवर्तन प्रकट नहीं होता है।" - रिबूट तक रजिस्ट्री परिवर्तन प्रभावी नहीं होता है, और आमतौर पर, केवल फ़ाइल एक्सप्लोरर को फिर से शुरू करना पड़ता है। यह सब इस बात पर निर्भर करता है कि रिबूट वास्तव में आवश्यक होने पर रजिस्ट्री परिवर्तन किस व्यवहार के लिए करना है। वास्तविक कुंजी को संशोधित किया जाता है, जब इसे संशोधित किया जाता है, जो आपके प्रश्न का उत्तर देता है।

— रामहुंड

एक कठिन शटडाउन का क्या मतलब है? पॉवर बटन को तब तक दबाए रखें जब तक वह नीचे नहीं आ जाता? यह प्रक्रिया किसी भी लंबित डिस्क कैश को लिखने से रोकती है।

— DavidPostill

@ राम मुझे लगता है कि यह प्रभाव में नहीं जाता है, लेकिन इसे डिस्क पर क्यों नहीं लिखा गया है? मैं एडिट, हार्ड पॉवर डाउन करता हूं और फिर बदलाव नहीं होता है। स्मृति में यह लागू हुआ या नहीं, इस बात से कोई फर्क नहीं पड़ता है

— Shrout1

@ Shrout1 - मशीन को सुरक्षित रूप से बंद करने के बजाय मशीन को बंद करने के लिए आप क्यों मजबूर कर रहे हैं?

— रामहुंड

@Ramhound मैं देख रहा हूं कि अगर सिस्टम इनायत से बंद नहीं होता है तो क्या होगा। यादृच्छिक, मुझे पता है, लेकिन मुझे यह जानने की आवश्यकता है कि यह कैसे स्मृति के लिए प्रतिबद्ध है ताकि हम अपने सिस्टम पर कुछ भी न खोएं यदि इसे सही तरीके से संभाला नहीं गया है।

— Shrout1

Answer 1

TL; DR: अपने सिस्टम को ठीक से बंद करें।

---

हाइबरनेशन को बंद करने से कोई लेना-देना नहीं है, यह सस्पेंड-टू-रैम (नींद) के साथ निकटता से संबंधित है, इसके अलावा रैम की सामग्री को डिस्क में धकेल दिया जाता है ताकि इसे वापस पढ़ा जा सके और ऑपरेशन फिर से शुरू हो जाए जहां सिस्टम बंद हो गया है ।

यदि आप परिवर्तन जारी रखना चाहते हैं तो आपको हाइबरनेशन और विंडोज फास्टबूट (जो हाइबरनेशन का सबसेट है) को अक्षम करना होगा । या आप वास्तव में हाइबरनेट और पुनरारंभ करने के बजाय रिबूट कर सकते हैं ।

कारण परिवर्तनों को जारी नहीं रखा जाता है, क्योंकि वे हाइबरनेशन फ़ाइल को छोड़कर अभी तक डिस्क पर नहीं लिखे गए हैं । जिसे आप हटा रहे हैं, जिसका अर्थ है कि फाइलसिस्टम को स्वयं को ठीक करना होगा और "अंतिम ज्ञात अच्छे" स्थिति में वापस जाना होगा।

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

यदि आप एक उचित शटडाउन करते हैं, तो विंडोज डिस्क पर मेमोरी को ठीक से फ्लश कर देगा, और फिर पावर डाउन करने से पहले डिस्क को सफाई से अनमाउंट करें।

एक उचित शटडाउन मजबूर करने के लिए एक कमांड प्रॉम्प्ट खोलें और टाइप करें

shutdown /s /f /t 0

/s"शटडाउन", /fबल के लिए, और /t 0"अब" का अर्थ है (समय = 0 सेकंड)

या आप बस फास्टबूट और हाइबरनेशन को अक्षम कर सकते हैं।

HowtoGeek में और पढ़ें : शट डाउन करना पूरी तरह से बंद नहीं है विंडोज 10 (लेकिन फिर से शुरू करना)

---

आपसे संबंधित एक मुश्किल शटडाउन करने से संबंधित समस्या यह है कि विंडोज को एक ही मिलीसेकंड (या एक मिनट) डिस्क को बदलने के लिए कोई भी परिवर्तन लिखने की गारंटी नहीं है जो आप बदलाव करते हैं। यह लगभग निश्चित रूप से कुछ मिनटों के भीतर लिखा जाएगा, लेकिन वास्तव में इसे लिखे जाने की संभावना समय के साथ बढ़ जाएगी। यह तुरंत लिखे जाने की संभावना नहीं है, फिर समय के पास जब आप बदलाव करते हैं तो संभावना तेजी से बढ़ जाती है, और लगभग निश्चित रूप से एक घंटे के भीतर लिखा जाएगा।

हालांकि, यह बात है कि एक कठिन शटडाउन मजबूर करके आप सिस्टम को डिस्क में परिवर्तन को सुरक्षित रूप से लिखने का मौका नहीं दे रहे हैं।

अधिकांश आधुनिक फाइल सिस्टम सुरक्षित तरीके से बदलाव करने के लिए लिखे गए हैं। अतीत में उन्हें "परमाणु" के रूप में संदर्भित किया गया है, जैसा कि परिवर्तन में हुआ है या ऐसा नहीं हुआ है।

आज हम उन के रूप में जानते journalled फाइल सिस्टम क्योंकि वे उस संचालन का एक लॉग रखने होगा कि या तो वापस लौटाया जा सकता या सिस्टम विफलता और रिबूट की स्थिति में आगे लुढ़का होता है। बिजली की विफलता से स्टार्टअप पर सिस्टम जर्नल की जांच करता है और प्रत्येक लेनदेन के लिए यह जांचता है कि क्या वास्तविक फ़ाइल डेटा डिस्क पर लिखा गया है और "अच्छा" है। यदि यह तब ट्रांज़िशन रोल फ़ॉरवर्ड होता है और पूरा हो जाता है, यदि नहीं तो यह पुराने डेटा पर वापस आ जाता है।

इस आदेश का उपयोग करके डिस्क लगभग हमेशा एक आसान मरम्मत की स्थिति में है।

लेकिन आपके सिस्टम को अप्रत्याशित रूप से बिजली देने के लिए मजबूर करने से आप गारंटी नहीं दे सकते हैं कि क्या मरम्मत के बाद लेन-देन आगे बढ़ने के लिए काफी आगे बढ़ चुका है, और संभावना है कि लिनक्स जैसे ऑपरेटिंग सिस्टम लेन-देन के इतिहास के बारे में विंडोज जितना ध्यान नहीं रखेगा और अधिक होने की संभावना है न कि केवल उन बदलावों को करने के लिए जो आगे की बजाय हर चीज को पीछे की ओर रोल करते हैं।

यदि आपने विंडोज में रिबूट किया है, तो यह डिस्क को ठीक से मरम्मत करने में सक्षम हो सकता है, क्योंकि इसमें फाइल सिस्टम का अधिक अंतरंग ज्ञान है।

Comments

धन्यवाद! मैं आपकी प्रतिक्रिया की सराहना करता हूं :) मैंने हाइबरनेशन को बंद कर दिया, रिबूट किया और उसी परीक्षण को फिर से चलाया। उदाहरण 1 में एक ही परिणाम है, कोई हाइबरनेशन फ़ाइल शामिल नहीं है। ऐसा प्रतीत होता है कि रजिस्ट्री परिवर्तन केवल लॉगऑफ़ / शटडाउन के दौरान कुछ बिंदु पर लिखे गए हैं ... मैं यह भी मानता हूं कि सिस्टम टूटे हुए हाइबरनेशन से जागने पर "अंतिम अच्छे" राज्य की तलाश में हो सकता है - यह अखंडता जांच चलाने के लिए जाता है।

— Shrout1

हम्म्म ... तो मैंने sysinternals "समन्वयन" डाउनलोड किया जो लिखने के लिए कैश को डिस्क पर मजबूर करता है और उसने कुछ भी नहीं किया (अभी भी हार्ड बंद पर कुंजी / मान खो दिया है)। मैंने प्रक्रिया खोजकर्ता को भी दौड़ाया और Regedit के गुणों में डिस्क I / O को देखा। इसने I / O पढ़ा था लेकिन I / O नहीं लिखा था। यह मुझे लगता है कि यह शटडाउन की प्रतीक्षा कर सकता है ... क्या आपको किसी भी अत्यधिक शुष्क एम $ प्रलेखन के बारे में पता है जो इसे स्पष्ट रूप से बता सकता है? आपके सहयोग के लिए पुन: धन्यवाद!!

— Shrout1

NTFS जर्नल फ़ाइल डेटा के बारे में कोई गारंटी नहीं देता है। यह केवल NTFS मेटाडेटा को सुसंगत रखने के लिए है, इसलिए आप टूटी हुई फ़ाइल सिस्टम के साथ समाप्त नहीं होते हैं । व्यक्तिगत फ़ाइलों में अभी भी आंशिक परिवर्तन हो सकते हैं, फ़ाइल को तोड़ना। नहीं है ट्रांसेक्शनल NTFS लेकिन यह सिफारिश नहीं कर रहा है और बहुत मुश्किल से ही इस्तेमाल किया। यही कारण है कि डेटाबेस इंजन डेटा संगति के लिए अपनी स्वयं की पत्रिका रखते हैं। ब्लॉगs.msdn.microsoft.com/oldnewthing/20130101-00/?p=5673

— Bob

@ Shrout1 यह मान रहा है कि रजिस्ट्री परिवर्तन राइट-बैक कैश में लंबित हैं। यह पूरी तरह से संभव है कि वे इसके बजाय अलग से प्रबंधित किए जाते हैं और इसका फाइल सिस्टम, कैशिंग या अन्यथा से कोई लेना-देना नहीं है। उदाहरण के लिए, अंतिम ज्ञात अच्छा कॉन्फ़िगरेशन केवल सफल स्टार्टअप पर अपडेट किया गया है। (जब परिवर्तन सहेजे जाते हैं, तो मुझे रजिस्ट्री इंटर्न के बारे में कुछ पता नहीं है। और फिर TxR शामिल हो सकता है।)

— बॉब

क्या कोई कारण है कि आप शटडाउन मजबूर कर रहे हैं? AFAIK जो केवल अनुप्रयोगों को बंद करने के लिए बाध्य करता है, जो कि उन अनुप्रयोगों को मारने के अलावा बहुत कुछ नहीं करता है जिन्हें आप अन्यथा बंद नहीं कर सकते हैं और यह अधिक संभावना बनाता है कि यदि आप नहीं जानते हैं कि आप कहीं न कहीं कुछ अनचाहे परिवर्तन खो देंगे। ऐसा करने या करने के बाद आप कुछ एप्लिकेशन को अपरिवर्तनीय स्थिति में रख देंगे - मैं वास्तव में "उचित" बंद नहीं कहूंगा।

— NotThatGuy

Answer 2

के लिए MSDN पृष्ठRegFlushKey पर प्रलेखित :

RegFlushKey को कॉल करना एक महंगा ऑपरेशन है जो सिस्टम-वाइड प्रदर्शन को काफी प्रभावित करता है क्योंकि यह डिस्क बैंडविड्थ की खपत करता है और रजिस्ट्री हाइव में सभी प्रक्रियाओं द्वारा संशोधनों को ब्लॉक करता है जो फ्लश ऑपरेशन पूरा होने तक फ्लश हो रहा है। RegFlushKey को केवल तभी स्पष्ट रूप से कहा जाना चाहिए जब किसी एप्लिकेशन को यह गारंटी देनी चाहिए कि संशोधन के तुरंत बाद रजिस्ट्री परिवर्तन डिस्क के लिए जारी हैं। कुंजी में किए गए सभी संशोधन डिस्क को फ्लश करने की आवश्यकता के बिना अन्य प्रक्रियाओं को दिखाई देते हैं।

वैकल्पिक रूप से, रजिस्ट्री में एक 'आलसी फ्लश' तंत्र होता है जो समय के नियमित अंतराल पर रजिस्ट्री संशोधनों को डिस्क में प्रवाहित करता है। इस नियमित फ्लश ऑपरेशन के अलावा, सिस्टम शटडाउन पर डिस्क में रजिस्ट्री परिवर्तन को भी फ्लश किया जाता है। रजिस्ट्री परिवर्तनों को फ्लश करने के लिए 'आलसी फ्लश' की अनुमति देना रजिस्ट्री को डिस्क पर रजिस्ट्री स्टोर को लिखने का सबसे प्रभावी तरीका है।

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

आप RegFlushKeyसॉफ्टवेयर में उस फंक्शन का उपयोग कर सकते हैं जो उक्त कुंजी में हेरफेर करता है, या इसके साथ एक अतिरिक्त टूल बनाने के लिए रजिस्ट्री कुंजी को डिस्क पर तुरंत लिखने के लिए मजबूर करता है, यदि यह आपके उपयोग के मामले के लिए महत्वपूर्ण है।

Comments

अरे! यदि आप निम्नलिखित MSDN लेख में एक लिंक फेंकते हैं, तो मैं आपको यह दे दूंगा: Windows 8 या Windows Server 2012 पर एप्लिकेशन रजिस्ट्री परिवर्तन सहेजना और एक संक्षिप्त अवरोध जोड़ना। आपके उत्तर ने मुझे उस लेख में खरगोश के छेद को नीचे गिरा दिया और यह मूल रूप से वही बात कहता है जो आपने किया था। बहुत बहुत धन्यवाद!

— Shrout1

लेकिन क्या कोई जानता है कि एक उपयोगकर्ता RegFlushKey को कैसे कॉल कर सकता है ?

— स्कॉट

@ सच यह प्रतीत होता है कि इसे कोड में किया जाना है ... पोस्ट में सूचीबद्ध MSDN के लेख में C ++ उदाहरण है और मैंने इसे C # कहीं और कार्यान्वित किया है। यह सुनिश्चित नहीं है कि यह कमांड लाइन से किया जा सकता है।

— Shrout1

@Scott: मैं अगर हैरान किया जाएगा sync किया फ्लश डिस्क के लिए रजिस्ट्री। यह सिर्फ कोई मतलब नहीं होगा। फ़ाइल सिस्टम कैश (जो कॉन्फ़िगरेशन प्रबंधक द्वारा उपयोग किया जाता है , अन्य तरीके से नहीं) अचानक फ़्लश करना चाहिए, कॉन्फ़िगरेशन प्रबंधक के स्वयं के कैश को फ्लश क्यों करना चाहिए ? यह भी नहीं पता है कि उच्च-स्तरीय कैश की संरचना क्या है, अगर एक भी सभी में मौजूद है।

— मेहरदाद

@Scott एक तरीका है। एपीआई पहले ही लिंक किया जा चुका है। वहाँ उपकरण हैं जो आपको मनमाने ढंग से Win32 फ़ंक्शन को कॉल करने के लिए GUI देते हैं। बात यह है ... यह एक कार्यान्वयन विस्तार है। यदि आप इसे उजागर करते हैं, तो लोग इस पर भरोसा करते हैं और फिर आप इसे बदल नहीं सकते हैं। यह भी ध्यान देने योग्य है कि सिस्टम डिस्क हटाने योग्य मीडिया के लिए पूरी तरह से अलग जानवर है। सिस्टम डिस्क का उपयोग कई चीजों के लिए किया जाता है जिनके लिए हमेशा खुले (जैसे पेज फ़ाइल) हैंडल की आवश्यकता होती है। विंडोज सिस्टम विभाजन को अनमाउंट करने का समर्थन नहीं करता है, इसलिए इस "सुविधा" की कोई आवश्यकता नहीं है। प्लस ... टिप्पणियों को तटस्थ रखने का प्रयास करें। आप विंडोज से नफरत करते हैं, हम इसे प्राप्त करते हैं।

— बेसिक

Answer 3

टीएल; डीआर: यह सही समय पर ऐसा करने के लिए बहुत सावधान है ।

इस पर प्रलेखन FSCTL_MARK_AS_SYSTEM_HIVEमें यह कहना है:

FSCTL_MARK_AS_SYSTEM_HIVEनियंत्रण कोड फाइल सिस्टम है कि निर्दिष्ट फ़ाइल रजिस्ट्री की प्रणाली छत्ता शामिल सूचित। गतिरोध से बचने के लिए और डेटा अखंडता सुनिश्चित करने के लिए फ़ाइल सिस्टम को सही समय पर डिस्क को हाइव डेटा को फ्लश करना चाहिए ।

मैं नहीं मानता कि सार्वजनिक रूप से इससे अधिक कोई विवरण उपलब्ध है।

यह ध्यान रखें कि फाइल सिस्टम को फ्लश करने से रजिस्ट्री फ्लश नहीं होती है , क्योंकि रजिस्ट्री फाइल सिस्टम के शीर्ष पर कैशिंग कर सकती है। पहले रजिस्ट्री को फ्लश करने के लिए, आपको किसी तरह से ब्याज की कुंजी पर कॉल करने NtFlushKeyया ZwFlushKeyकॉल करने की आवश्यकता होती है ।

Comments

ओह अच्छा पकड़! यह मेरा नया पसंदीदा MSDN-ism है: सिर्फ सही पल । मेरा पिछला पसंदीदा था "किसी क्वेरी, जिसमें UNION, UNION ALL, EXCEPT, या INTERSECT ऑपरेटर वाले टॉप क्लॉज को निर्दिष्ट करते समय सावधानी बरतें। अप्रत्याशित परिणाम देने वाले क्वेरी को लिखना संभव है " जो कि इस फीचर के लिए एक व्यंजना थी। बुरी तरह से टूट गया है और वह नहीं करता है जो किसी भी उचित व्यक्ति को उम्मीद होगी और इसे ठीक करने के बजाय हम इसे दस्तावेज करने जा रहे हैं "।

— द्विविदक

@davidbak: lol, MSDN के बचाव में अच्छी तरह से, मैं वास्तव में यह नहीं देखता कि वे और अधिक विवरण क्या प्रदान कर सकते हैं कि एक उपयोगकर्ता को भरोसा करना चाहिए।

— मेहरदाद

ओह, तुम सही हो; स्पष्ट रूप से यह लंबे समय से पहले यूरोपीय संघ के निपटान के नतीजे के रूप में कुछ दस्तावेज था, जहां Microsoft को सभी एपीआई का दस्तावेजीकरण करने की आवश्यकता थी - चाहे वे कितने भी आंतरिक हों। आपके द्वारा लिंक किया गया यह पृष्ठ यहां तक ​​कि "केवल कर्नेल-स्तर के घटक इस फाइलसिस्टम नियंत्रण कोड का उपयोग कर सकते हैं" जो आपके हाथों को बंद रखने के लिए एक मजबूत संकेत है। फिर भी, " सिर्फ सही क्षण " - एक दिन मैं कुछ एपीआई के साथ "इस विधि को केवल सही समय पर कॉल करता हूँ" का दस्तावेजीकरण करूँगा और देखूँगा कि क्या होता है ....

— davidbak

@davidbak: मुझे लगता है कि आप थोड़ा ... उत्साहित हैं। :-P मेरा अनुमान है कि यह फाइल सिस्टम ड्राइवरों को यह बताने के लिए प्रलेखित किया गया था कि किस फाइल में सिस्टम रजिस्ट्री हाइव है, जो इस बात में महत्वपूर्ण हो सकता है कि वे उस समय उस रजिस्ट्री में कुछ भी लिखने का प्रयास नहीं करेंगे डिस्क में फ्लश किया जा रहा है। मेरे पास हालांकि इसका कोई प्रमाण नहीं है; यह सिर्फ एक कारण है जो मुझे बोधगम्य लगता है। एक शक मुझे इसके बारे में है, हालांकि, एक डिस्क ड्राइवर को यह भी जानने की आवश्यकता नहीं होगी।

— मेहरदाद