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

बाकी सब से पहले बिल्ड नंबर और इंस्टॉलेशन का समय-चिह्न एकत्र करें। दोनों लॉग के एक फ़ोल्डर को ऐसी खोज में बदल देते हैं जिसे आप वास्तव में चला सकते हैं।

तीन चरण, तीन अलग लॉग

पहला चरण स्वयं इंस्टॉलर है, जो फ़ाइलें खोलता है, अपना लॉग रखता है और 1603 जैसा सारांश कोड बताता है जो कहता है कि लेन-देन विफल हुआ पर कहाँ, यह नहीं बताता। दूसरा ड्राइवर स्टोर है, जहाँ हस्ताक्षरित पैकेज बाद के उपयोग के लिए तैयार किया जाता है, जो उसे हार्डवेयर से जोड़ने से अलग उपलब्धि है। तीसरा डिवाइस निर्माण है, जहाँ Windows एक डिवाइस इंस्टेंस बनाता है, INF लागू करता है और परिणाम setupapi लॉग में दर्ज करता है। इनमें से किन्हीं दो चरणों के बीच का शांत अंतराल उपयोगकर्ता के लिए वही वाक्य पैदा करता है।

सारांश कोड लेन-देन का है, जबकि विफल क्रिया उसी लॉग में कहीं पहले है। कोड को समझाने की कोशिश करने के बजाय कोड से पीछे की ओर खोजें।

प्रयास के आसपास setupapi.dev.log पढ़ें

हर डिवाइस इंस्टॉलेशन C:\Windows\INF\setupapi.dev.log में एक अनुभाग लिखता है, और SetupAPI लॉग मार्गदर्शिका बताती है कि वे अनुभाग और उनकी अंतिम स्थिति कैसे व्यवस्थित हैं। वह अनुभाग खोजें जिसका समय-चिह्न आपके प्रयास को घेरता है, फिर आपकी नज़र में आने वाली पहली त्रुटि पंक्ति के बजाय उसे पूरा पढ़ें। असंबंधित डिवाइसों के बारे में चेतावनियाँ लंबे लॉग में भर फैली रहती हैं और इस विफलता के बारे में कुछ नहीं बतातीं। मिलते-जुलते अनुभाग की अंतिम स्थिति वह तथ्य है जो किसी रिपोर्ट में उद्धृत करने योग्य है।

उस अनुभाग को अडैप्टर नाम, डिवाइस पहचानकर्ता और इंस्टॉलर लॉग में नामित INF पैकेज से जोड़ें। एक ही समय-चिह्न पर तीन पहचानकर्ताओं का मेल खाना ही आरोपण को सुरक्षित बनाता है।

पैकेज और डिवाइस को अलग-अलग जाँचें

तैयार पैकेज केवल यह साबित करता है कि हस्ताक्षरित INF ड्राइवर स्टोर तक पहुँचा। इस Windows पीढ़ी में, pnputil /enum-drivers तीसरे पक्ष के पैकेजों को प्रदाता, वर्ग, संस्करण और प्रकाशित नाम के अनुसार सूचीबद्ध करता है, जिससे आप oem नंबर से अनुमान लगाने के बजाय OpenVPN अडैप्टर पैकेज खोज सकते हैं। उस सूची में कुछ भी यह नहीं कहता कि कोई डिवाइस मौजूद है, शुरू हुआ है या आपके द्वारा खोजे गए पैकेज से जुड़ा है। ये अलग प्रश्न हैं और उनके अलग उत्तर हैं।

डिवाइस पक्ष का अपना दृष्टिकोण है। केवल-पढ़ने वाली अडैप्टर सूची दिखाती है कि Windows इस समय इंटरफ़ेस के बारे में क्या मानता है, और छिपी प्रविष्टियाँ उन डिवाइसों को कवर करती हैं जो मौजूद हैं पर निष्क्रिय हैं। दोनों सूचियों की तुलना आपको बताती है कि कौन-सा चरण विफल हुआ: पैकेज अनुपस्थित, डिवाइस अनुपस्थित, या डिवाइस समस्या स्थिति के साथ मौजूद।

हस्ताक्षर छूने से पहले अडैप्टर सत्यापित करें

स्थिति मशीन से पढ़ें, इंस्टॉलर के सारांश से नहीं। नीचे दिए गए कमांड तैयार ड्राइवर पैकेज, छिपी प्रविष्टियों सहित अडैप्टर सूची, और वे नेटवर्क डिवाइस सूचीबद्ध करते हैं जो OK नहीं बताते। उन्हें रीबूट के बाद चलाएँ ताकि लंबित डिवाइस संक्रियाएँ शांत हो जाएँ।

pnputil /enum-drivers
Get-NetAdapter -IncludeHidden | Select-Object Name, InterfaceDescription, Status
Get-PnpDevice -Class Net | Where-Object Status -ne 'OK'

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

हस्ताक्षर प्रवर्तन बंद करना, नेटवर्क स्टैक रीसेट करना या हर अडैप्टर हटाना सबूतों को गायब कर देता है। इन तीनों में से कोई भी उस चरण को ठीक नहीं करता जिसे आपने अभी तक पहचाना नहीं है, और हर एक वह चीज़ हटा देता है जो आपको बताती कि कौन-सा चरण था।

संबंधित लेख