यदि आप पिछले ग्यारह सालों से Dedoimedo पढ़ रहे हैं, तो आप जानते हैं कि मैं सुरक्षा सॉफ्टवेयर का बहुत बड़ा प्रशंसक नहीं हूं। लेकिन मैं सुरक्षा उत्पादों का परीक्षण करता हूं, बस यह देखने के लिए कि वे चीजों के व्यापक दायरे में कैसे व्यवहार करते हैं। इस तरह का निस्वार्थ अभ्यास मुझे सॉफ्टवेयर की तुलना और न्याय करने की अनुमति भी देता है, विशेष रूप से विंडोज सुरक्षा प्रोग्राम के स्वर्ण मानक, सबसे शानदार, उपयोगी और बिना बकवास EMET के खिलाफ। वहां।
वैसे भी, कुछ महीने पहले, मैंने एक विंडोज 7 मशीन पर MalwareBytes Anti-Malware (MBAM) के साथ एक स्कैन चलाया, और स्कैन के बीच में, मुझे ब्लू स्क्रीन ऑफ डेथ (BSOD) का सामना करना पड़ा। अच्छा नहीं। रिकवरी पर, मैंने सभी जांचों की मां शुरू की। मेरे पीछे आइए।
ऑपरेशनल सेटअप, अतिरिक्त तथ्य
इससे पहले कि हम यह पता लगाना शुरू करें कि क्या हुआ, मुझे आपको कुछ और जानकारी देनी होगी। अन्यथा, यह पूरी कवायद बेकार है। सबसे पहले, BSOD। सामान्य तौर पर, विंडोज घरेलू वातावरण में बेहद स्थिर है - सर्वर एक अलग विषय हैं - और वास्तव में कोई कारण नहीं है कि आपको आंतरिक विंडोज कर्नेल बग के कारण कभी भी एक महत्वपूर्ण सिस्टम क्रैश का अनुभव करना चाहिए।
लगभग 15 वर्षों के भारी विंडोज उपयोग में, लगभग एक दर्जन अलग-अलग प्रणालियों में, मुझे BSOD केवल कुछ बार हुआ है - एक ग्राफिक्स कार्ड के ओवरहीटिंग के कारण, छोटी गाड़ी ग्राफिक्स ड्राइवरों के कारण, एक दुखद एपिसोड जिसके बारे में हमने विस्तार से बात की, और एक बार जब मैंने एक स्मार्टफोन को USB केबल के माध्यम से कनेक्ट किया। बस इतना ही।
वास्तव में, मेरे पिछले दावे पर वापस जा रहे हैं, कर्नेल क्रैश देखने का एकमात्र समय हार्डवेयर त्रुटियों या दोषपूर्ण ड्राइवरों के कारण होता है, वास्तव में, जो मेरे उपयोग इतिहास के साथ पूरी तरह से संरेखित होता है। यह मेरे लिनक्स के साथ बल्कि व्यापक कार्य अनुभव के साथ भी हाथ में हाथ डालकर चलता है, जिसे मैंने अपनी लिनक्स क्रैश बुक में प्रलेखित किया है। संक्षेप में, हार्डवेयर, खराब सिस्टम कॉल, या शुद्ध कर्नेल बग। बस इतना ही है, और अंतिम सबसे कम संभावना है।
लेकिन अब, मुझे ataport.sys ड्राइवर के साथ एक समस्या का सामना करना पड़ रहा था - जो एक माइक्रोसॉफ्ट ड्राइवर है, और जिसमें कोई बग नहीं होना चाहिए। तो, क्या हमारे हाथ में एक हार्डवेयर समस्या है? और यदि हां, तो किस तरह की? फिर भी, इससे पहले कि हम आगे बढ़ें, मैं आपका ध्यान समस्या समाधान की कला और इसे कैसे किया जाना चाहिए, धीरे-धीरे, सावधानी से, व्यवस्थित रूप से, की ओर आकर्षित करना चाहूंगा।
विश्लेषण, पहले कदम
ठीक है। आइए समझते हैं कि क्या हुआ। हम जानते हैं कि BSOD का विश्लेषण कैसे करना है, क्योंकि मैंने आपको अपने विस्तृत BSOD गाइड में दिखाया है कि यह कैसे करना है। उपलब्ध टूल्स में से एक का उपयोग करके, हम क्रैश डंप का विश्लेषण कर सकते हैं। मैंने Nirsoft के BlueScreenView प्रोग्राम का विकल्प चुना। यह पता चला कि क्रैश इसके कारण हुआ था:
ataport.SYS+1ff3c
और विशिष्ट त्रुटि है KERNEL_DATA_INPAGE_ERROR। मेमोरी कोर में उपलब्ध कुछ अन्य तर्कों की जांच करते हुए, यह एक कर्नेल ऑपरेशन के दौरान एक हार्डवेयर त्रुटि की ओर इशारा करता है, जो अनिवार्य रूप से एक सिस्टम क्रैश का कारण बना। अब तक इतना सरल।
लेकिन MBAM स्कैन के दौरान क्रैश क्यों हुआ?
यह एक दिलचस्प सवाल है? वास्तव में, अब हमें यह पता लगाने की आवश्यकता है कि क्या:
- यह समस्या केवल MBAM के लिए विशिष्ट है।
- एक अधिक सामान्य प्रणाली समस्या जो स्कैन के दौरान गलती से प्रकट हुई।
यह पता लगाने के लिए कि दावा a) या b) सही है, हमें क्रैश की परिस्थितियों को दोहराने की आवश्यकता है। यहां कुछ और विवरण हैं: एक विंडोज 7 मशीन, EMET के अलावा कोई अतिरिक्त सुरक्षा सॉफ्टवेयर नहीं, एक माउंटेड TrueCrypt कंटेनर के साथ। यह महत्वपूर्ण और प्रासंगिक है, क्योंकि यह एक और सॉफ्टवेयर है जो स्टोरेज लेयर ड्राइवर्स का उपयोग करता है और संभावित रूप से इस स्थिति के परिणाम को प्रभावित कर सकता है।
मैंने दूसरा स्कैन चलाया - लेकिन इस बार सिस्टम क्रैश नहीं हुआ, TrueCrypt कंटेनर और सभी के साथ। हालांकि, मैंने इवेंट लॉग में एक त्रुटि देखी, एक इवेंट आईडी 11 पढ़ रहा था:
ड्राइवर ने \Device\Ide\IdePort1 पर एक कंट्रोलर त्रुटि का पता लगाया।
मैंने इस प्रकार की त्रुटियों को पहले कभी नहीं देखा है, और MBAM स्कैन के साथ समय काफी दिलचस्प है। अब जब हमारे पास हाथ में अतिरिक्त जानकारी है, तो हमें अपनी जांच में अगले चरण का पता लगाना होगा।
कंट्रोलर त्रुटि का अर्थ
यदि आप इस विशिष्ट त्रुटि की खोज करते हैं, तो आपको प्रविष्टियों की एक पूरी श्रृंखला मिलेगी, लोगों से वही सवाल पूछते हुए। अंत में, यह तीन प्रमुख मुद्दों पर उबलता है - खराब SATA केबल, खराब डिस्क, या खराब चिपसेट कंट्रोलर, जो प्रभावी रूप से एक नया मदरबोर्ड है। काफी भयावह लगता है। हालांकि, यह मुद्दा केवल MBAM स्कैन के दौरान प्रकट हुआ। और इस बिंदु पर, हमें यह समझने की आवश्यकता है कि क्या हम एक अलग घटना या एक प्रणाली समस्या से निपट रहे हैं।
विश्लेषण, सिस्टम स्वास्थ्य
मैंने मशीन की स्थिति की जांच कई स्तरों पर करने का फैसला किया, जिसमें हार्डवेयर जांच शामिल है। ध्यान दें कि आप कभी भी 100% सुनिश्चित नहीं हो सकते। भले ही एक विशिष्ट जांच साफ निकले, तकनीकी रूप से, आपका हार्डवेयर अगले दिन मर सकता है। इसलिए, आप इन जांचों में सांत्वना और गारंटी नहीं ढूंढ सकते। वे आपको जो बताते हैं वह यह है कि फिलहाल, सर्वोत्तम स्थिति में, कोई लक्षण नहीं हैं जो एक व्यापक समस्या का संकेत देते हैं।
- डिस्क SMART जांच, साफ।
- WD डेटा लाइफगार्ड डायग्नोस्टिक्स जांच, साफ।
- सिस्टम ऊपर वर्णित मुद्दे के अलावा ठोस स्थिर है।
- पूरे एक हफ्ते के बाद भी कोई अन्य समस्या नहीं होती है।
भले ही मुझे कुछ करने की खुजली थी, मैंने कुछ भी न करने का फैसला किया और कंप्यूटर को पूरे एक हफ्ते तक चलने दिया, जिसमें तनावपूर्ण गतिविधियां शामिल थीं जैसे - भारी IO के साथ बहुत सारे गेम, डेटा बैकअप, सिस्टम इमेजिंग, विंडोज अपडेट, और बहुत कुछ। इन सभी संभावित परीक्षणों में, सिस्टम महीनों और वर्षों पहले की तरह अनुमानित रूप से व्यवहार करता रहा।
इस बिंदु पर, मैंने फैसला किया कि हार्डवेयर के साथ कोई आसन्न स्वास्थ्य समस्या नहीं है, कम से कम, अस्थायी आंकड़ों और अंधविश्वास को छोड़कर। इसने मुझे विश्वास दिलाया कि समस्या MBAM के कारण हुई थी। और यह मेरे अनुभव के साथ अच्छी तरह से संरेखित होता है कि यह कभी विंडोज नहीं है जो क्रैश होता है, यह हमेशा कुछ और होता है जो इसे करता है।
MBAM, अतिरिक्त जांच
अब, हम इस सुरक्षा सॉफ्टवेयर पर ध्यान केंद्रित करते हैं। फिर से, यदि आप ऑनलाइन खोजते हैं, तो आपको प्रविष्टियों की एक अंतहीन मात्रा मिलेगी, जिसमें ये प्रमुख विषय बार-बार आते हैं: a) मैलवेयर, जैसे DUH, कुछ ट्रोजन सहित जो सुरक्षा सॉफ्टवेयर को चलने से रोकता है और इस प्रकार के क्रैश का कारण बनता है b) उपयोगकर्ताओं द्वारा दावा कि MBAM 3 क्रैश का कारण बनता है जबकि MBAM 2 नहीं करता c) TrueCrypt के साथ असंगतता हो सकती है जो BSOD का कारण बन सकती है।
मैंने इन परिकल्पनाओं का परीक्षण करने और देखने का फैसला किया कि क्या वे सच हैं। पहले, c) के संबंध में, यह एक बार एक मुद्दा हो सकता है, लेकिन यह निश्चित रूप से अब नहीं है। मेरे अनुभव में, मेरे पास हमेशा TrueCrypt वॉल्यूम माउंटेड थे और उन्होंने पहले कभी क्रैश नहीं किया।
a) के संबंध में, यह बकवास है, लेकिन मैंने यह देखने के लिए कुछ त्वरित सिफारिशों का पालन करने का फैसला किया कि क्या वे जांचते हैं। बेशक वे नहीं करते। इसके अलावा, MBAM ने बिना किसी BSOD के एक बाद का स्कैन पूरा किया लेकिन प्रासंगिक कंट्रोलर त्रुटियों के साथ, जो इस मुद्दे को सॉफ्टवेयर तक सीमित करता है।
MBAM + इवेंट आईडी 11
अब, हम वास्तव में प्रासंगिक जानकारी खोज सकते हैं। आधिकारिक मंच में केवल कुछ प्रविष्टियां हैं, और उनकी कहानी मेरे जैसी ही है। कई लोगों को क्रैश हुआ था, और उन्होंने पता लगाया कि यह MBAM और इंटेल रैपिड स्टोरेज टेक्नोलॉजी (RST) ड्राइवर्स के बीच टकराव के कारण हुआ था। अहा। मैंने नवीनतम समर्थित ड्राइवर्स इंस्टॉल किए और रीबूट किया। मैंने रास्ते में कई चीजें खोजीं:
- मेरे ड्राइव अक्षर गड़बड़ हो गए थे, इसलिए मुझे उन्हें सही ढंग से पुनः असाइन करना पड़ा।
- केस पर डिस्क लाइट पहले की तुलना में कम चमकती है - यहां तक कि किसी भी SATA लिंक पावर मैनेजमेंट के बिना सक्षम - यह सिर्फ एक दृश्य चाल हो सकती है या वास्तव में, पहले की तुलना में कम डिस्क पोलिंग गतिविधि है। सिस्टम मेट्रिक्स कोई बड़ा अंतर नहीं दिखाते।
- इन नए ड्राइवर्स के कारण बहुत मामूली प्रदर्शन वृद्धि है।
और अब, मैंने एक ताजा नया MBAM स्कैन चलाया, और यह बिना किसी समस्या के पूरा हुआ। न ही इवेंट लॉग में ये कोई त्रुटियां थीं। तो यह पता चलता है कि यह तीसरे पक्ष के सॉफ्टवेयर के कारण हुई समस्या थी, और माइक्रोसॉफ्ट की गलती नहीं, न ही एक हार्डवेयर मुद्दा। P.S. अन्य MBAM लोगों ने बताया कि MBAM संस्करण अपग्रेड के बाद समस्या दूर हो गई।
मैं इसे अस्वीकार कर दूं, त्रुटियां विंडोज या अंतर्निहित प्लेटफॉर्म के कारण नहीं हैं, जहां तक आप बता सकते हैं। यह उपयोगकर्ता की उचित क्षमता के भीतर नहीं है कि इसे समझ सके। क्योंकि मेरे पुराने डेस्कटॉप पर, जैसा कि आप इस विषय पर मेरे खुश लेख में पढ़ सकते हैं, एक डिस्क जिसकी SMART डेटा शीट बेदाग थी, बिना किसी पूर्व चेतावनी के मर गई, जबकि दूसरी, एक कथित तौर पर अत्यधिक गंभीर समस्या के साथ जो आसन्न डिस्क मौत की घोषणा करनी चाहिए थी, त्रुटि दिखने के बाद कई महीनों तक खुशी से जीवित रही। आंकड़े तब तक अच्छा काम करते हैं जब तक वे आपके खिलाफ नहीं हो जाते।
लेकिन सभी व्यावहारिक उद्देश्यों के लिए, यहीं, अभी, यह 100% MBAM मुद्दा था, और हार्डवेयर से कोई लेना-देना नहीं। एक सुरक्षा स्कैनर के बीच टकराव जिसमें निम्न-स्तरीय सिस्टम विशेषाधिकार हैं और स्टोरेज ड्राइवर्स। सवाल यह है कि क्यों?
वास्तव में, क्यों?
MBAM कोड स्रोतों तक पहुंच के बिना, आप वास्तव में निश्चित रूप से नहीं जान सकते, लेकिन मेरा एक सिद्धांत है। मैलवेयर कभी-कभी डिस्क पर खुद को छिपाने की कोशिश करता है सभी प्रकार की चतुर योजनाओं का उपयोग करके। ऐसा करने का एक तरीका सिस्टम को फर्जी I/O ड्राइवर्स का उपयोग करने के लिए मजबूर करना है, ताकि वे एक साफ डिस्क की रिपोर्ट करें। इसका मतलब है कि एक मैलवेयर स्कैनर सिस्टम के कार्यों पर भरोसा करने में सक्षम नहीं हो सकता है एक सच्चा मूल्य वापस करने के लिए।
मेरा मानना है कि MBAM अपने स्वयं के डिस्क एक्सेस फंक्शन को लागू करता है, जिसमें कंट्रोलर कमांड शामिल हैं, साथ ही इसके अपने seek, read, unlink, और अन्य सिस्टम कॉल और फंक्शन। किसी कारण से, इन कमांड्स में से एक इंटेल के RST के साथ टकराया, एक I/O त्रुटि को ट्रिगर किया, जिसे सिस्टम ने एक कंट्रोलर त्रुटि के रूप में व्याख्या किया। इसलिए, BSOD या सिस्टम इवेंट। यह मेरा सिद्धांत है, और यह गलत हो सकता है, लेकिन यह समझ में आता है।
अधिक पढ़ना
चूंकि आप कभी भी निश्चित नहीं हो सकते कि आपके सिस्टम विफल नहीं होंगे, आपको वास्तव में उनकी विफलता के लिए योजना बनानी चाहिए। दूसरे शब्दों में, दर्दनाक क्षणों को गले लगाएं, जब वे होते हैं तो तैयार रहें ताकि आप न्यूनतम नुकसान के साथ जल्दी से ठीक हो सकें। उदाहरण के लिए, मेरे पास हमेशा अतिरिक्त हार्डवेयर पड़ा होता है, जिसमें कम से कम 2-3 ताजा हार्ड डिस्क शामिल हैं।
मैं डेटा का बैकअप भी लगातार लेता हूं और सिस्टम इमेज करता हूं, इसलिए यदि हार्डवेयर को बदलने की आवश्यकता है, तो मैं जल्दी से उत्पादकता पर वापस जा सकता हूं। और ऐसा होता है, कई महीने पहले, मैं था, एक अलग डेस्कटॉप पर इस अचानक डिस्क विफलता का सामना कर रहा था। कोई चिंता नहीं। मैं लगभग एक घंटे के भीतर कार्रवाई में वापस आ गया, बिना किसी डेटा या यहां तक कि सिस्टम कॉन्फ़िगरेशन के नुकसान के।
अंत में, मैंने समस्या समाधान के बारे में शेखी बघारी और इसे व्यवस्थित रूप से कैसे किया जाना चाहिए। यह समस्या निवारण का सार है, विशेष रूप से हार्डवेयर और सॉफ्टवेयर मुद्दों के लिए। यदि आप इसे सही तरीके से करते हैं, तो आप गलती करने की संभावना कम होती है, समय और पैसा बचाते हैं। चीजों को अंधाधुंध बदलने के बारे में जाना कभी भी एक अच्छा विचार नहीं है। इस पर मेरी एक पूरी किताब भी है।
निष्कर्ष
यह एक कठिन, जटिल समस्या थी, कई कारकों के वजन के साथ। एक बिंदु पर, हमारे पास कई मोर्चों पर संभावित हार्डवेयर मुद्दे थे, TrueCrypt, मैलवेयर, और सॉफ्टवेयर बग सभी ध्यान के लिए प्रतिस्पर्धा कर रहे थे। इसे हल करना आसान नहीं है। और फिर भी, धीमे, सावधानीपूर्वक काम के साथ, हम समस्या को पूरी तरह से समझने, मूल कारण को अलग करने, दावों को मान्य करने, और संभावित प्रस्तावों का परीक्षण करने में सक्षम थे। बिना किसी कठोर प्रणाली परिवर्तन के।
मेरा मानना है कि यह एक मूल्यवान सबक है। यह मेरे साथ हुआ, लेकिन मैं चाहता हूं कि आप निष्कर्षों को ले जाएं। जब भी कुछ बुरा होता है, इंटरनेट आपको कचरे से विस्फोट करेगा। हार्डवेयर, मैलवेयर, अपनी पसंद चुनें। हर किसी को आपकी समस्या होगी, और फिर भी, यह हमेशा थोड़ा अलग होगा और बिल्कुल लागू नहीं होगा। आप इस तरह पागल हो सकते हैं। वह सब करने के लिए एक मजबूत प्रलोभन है जो इन सभी लोगों ने किया। लेकिन आगे का सबसे अच्छा तरीका लक्षणों की बहुत सावधानी से जांच करना है, उनका पूरी तरह से विश्लेषण करना और सुधार लागू करना, प्रतिवर्ती, पूरी तरह से मात्रात्मक सुधार, सबसे सरल, कम से कम घुसपैठ वाले से शुरू करना।
जिस तरह से हम इस मुद्दे के बारे में गए। क्या हम जानते हैं कि क्या हुआ? क्या हम इसे पुन: पेश कर सकते हैं? क्या नई जानकारी समझ में आती है? क्या हम संभावित कारणों को मान्य कर सकते हैं? क्या हम उनमें से कुछ को अयोग्य घोषित कर सकते हैं? जिनके साथ हम बचे हैं, खोजों का एक नया दौर। नए दावे, नई परिकल्पनाएं, नई जांच। स्पष्ट, प्रतिलिपि प्रस्तुत करने योग्य परिणाम। समाधान। ज्ञान। मज़ा। मुझे आशा है कि आपने इसका आनंद लिया। याद रखें, विंडोज को दोष न दें, और अपने हार्डवेयर के बारे में इंटरनेट का क्या कहना है इसके बारे में संदेहास्पद रहें। यह सब कयामत और उदासी है। लेकिन यह ऐसा नहीं होना चाहिए। खुश कंप्यूटिंग।
चीयर्स।
