انسٹالر کہتا ہے کہ 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 حصہ بتاتا ہے کہ کیوں۔ ڈیوائس موجود ہے مگر خرابی کی حالت میں ہے، تو یہ ڈرائیور یا اس کے دستخط کی طرف اشارہ کرتا ہے، جو گمشدہ ڈیوائس سے مختلف بات ہے۔ موجود ہو کر منقطع ہونے کی اطلاع دینے والا ایڈاپٹر فعال سرنگ کے بغیر کام کرنے والی ڈیوائس ہے، ناکام انسٹالیشن نہیں۔ مرمت کا مرحلہ چننے سے پہلے تینوں نتائج ایک ساتھ پڑھیں۔

دستخطوں کا نفاذ بند کرنا، نیٹ ورک اسٹیک ری سیٹ کرنا یا ہر ایڈاپٹر حذف کرنا ثبوت غائب کر دیتا ہے۔ ان تینوں میں سے کوئی بھی ایسے مرحلے کی مرمت نہیں کرتا جو آپ نے ابھی شناخت نہیں کیا، اور ہر ایک وہ چیز ہٹا دیتا ہے جو بتاتی کہ کون سا مرحلہ تھا۔

متعلقہ مضامین