ویندوز را به سه روش از کار انداختم تا بهترین ابزار عیب‌یابی را پیدا کنم؛ ابزاری که مایکروسافت همراه ویندوز عرضه نمی‌کند

وقتی رایانه‌ای ویندوزی از کار می‌افتد، تشخیص علت آن دشوار است. اغلب پای یک درایور معیوب یا سخت‌افزاری تازه‌نصب‌شده، مانند ماژول حافظه‌ای جدید یا دستگاه USB، در میان است. اما اگر مشکل از این‌ها نباشد، ابزارهای داخلی ویندوز مانند Event Viewer و Reliability Monitor همیشه قابل‌اعتماد نیستند؛ گاهی علت را پیدا می‌کنند و گاهی از شناسایی مقصر بازمی‌مانند.

شگفت‌آور اینکه ابزاری که می‌تواند علت از کار افتادن سیستم را به‌درستی مشخص کند، ساختهٔ خود مایکروسافت است؛ با این تفاوت که به‌طور پیش‌فرض روی رایانه نصب نیست. ویندوز را عمداً به سه روش از کار انداختم تا ببینم کدام ابزار داخلی بهتر می‌تواند علت را توضیح دهد و در نهایت WinDbg بهترین نتیجه را به دست آورد.

سه روش برای از کار انداختن رایانه

یک ماشین مجازی موقت و ابزار ایجاد خرابی مایکروسافت

همهٔ آزمایش‌ها را در یک ماشین مجازی Windows ۱۱ روی VirtualBox اجرا کردم تا هیچ سخت‌افزار یا دادهٔ واقعی در معرض خطر نباشد. برای ایجاد خرابی از NotMyFault استفاده کردم؛ ابزاری از مجموعهٔ ابزارهای عیب‌یابی Sysinternals مایکروسافت که برای از کار انداختن عمدی ویندوز ساخته شده است. کافی است آن را با دسترسی مدیر اجرا کنید و نوع خرابی را برگزینید تا سیستم بی‌درنگ از کار بیفتد.

سه خرابی متفاوت ایجاد کردم تا ببینم هر ابزار چگونه با آن‌ها روبه‌رو می‌شود: خطای High IRQL که نمونهٔ کلاسیک خرابی درایور است، سرریز بافر که حافظه را خراب می‌کند و تخریب پشته که پشتهٔ فراخوانی را از کار می‌اندازد. هرکدام به شیوه‌ای متفاوت رخ می‌دهند؛ بنابراین یک ابزار عیب‌یابی خوب باید بتواند همهٔ آن‌ها را شناسایی کند.

پیش از ایجاد خرابی، ویندوز را طوری تنظیم کردم که دامپ‌های کوچک حافظه را ذخیره کند و راه‌اندازی دوبارهٔ خودکار را نیز از مسیر «ویژگی‌های سیستم > پیشرفته > راه‌اندازی و بازیابی» خاموش کردم تا صفحهٔ هر خرابی آن‌قدر روی نمایشگر بماند که بتوانم آن را بخوانم. سرریز بافر به‌تنهایی سیستم را از کار نینداخت؛ ازاین‌رو گزینهٔ Special Pool در Driver Verifier را برای درایور NotMyFault فعال کردم تا خرابی به‌اجبار رخ دهد. پس از هر خرابی، چهار بخش یکسان را به همان ترتیب بررسی کردم: صفحهٔ خرابی، Reliability Monitor،‏ Event Viewer و سرانجام فایل دامپ حافظه در WinDbg.

بررسی نتایج خرابی‌ها

ابزارهای داخلی از کد توقف فراتر نرفتند

صفحهٔ خرابی نخستین چیزی بود که پس از هر بار از کار افتادن سیستم می‌دیدم و نزدیک‌ترین پاسخ واقعی در میان ابزارهای داخلی را ارائه می‌کرد. در دو مورد از سه خرابی، یعنی خطای High IRQL و سرریز بافر، درست زیر کد توقف سطری با عنوان «چه چیزی از کار افتاد» نمایش داد و myfault.sys را به‌عنوان درایور مقصر معرفی کرد. در خرابی سوم، یعنی تخریب پشته با کد توقف 0x139، تنها کد توقف را نشان داد و نامی از درایور نبرد. مشکل اینجاست که ویندوز در حالت پیش‌فرض به‌طور خودکار دوباره راه‌اندازی می‌شود؛ بنابراین بیشتر کاربران هرگز فرصت خواندن این صفحه را پیدا نمی‌کنند. پس از راه‌اندازی دوباره نیز اطلاعات نمایش‌داده‌شده در هیچ‌جا ذخیره نمی‌شود.

در گام بعد به سراغ Reliability Monitor رفتم؛ ابزاری که پیش‌تر برای عیب‌یابی کندی رایانه به آن تکیه کرده بودم، اما اینجا کمک چندانی نکرد. این ابزار همهٔ خرابی‌ها را ثبت کرد، ولی هرکدام را به سه ورودی جداگانه تقسیم کرده بود که گیج‌کننده بود. با انتخاب «نمایش جزئیات فنی»، تنها کد توقف، چهار پارامتر آن و نام فایل دامپ حافظه را دیدم؛ نه نامی از درایور بود و نه نشانی از علت.

Event Viewer نیز همین داستان را بازگو کرد. ورودی Event ۱۰۰۱ (BugCheck) کد توقف، پارامترها و مسیر فایل دامپ حافظهٔ هر خرابی را ثبت کرده بود، اما میان ورودی‌های عمومی Kernel-Power ۴۱ و Event ۶۰۰۸ پنهان شده بود؛ ورودی‌هایی که فقط خاموش شدن غیرمنتظرهٔ سیستم را تأیید می‌کنند. برای یافتن گزارش مرتبط باید نتایج را بر پایهٔ Event ID پالایش کنید و حتی پس از آن نیز چیزی بیش از همان اطلاعات محدود Reliability Monitor به دست نمی‌آورید.

البته انصافاً این ابزارها بی‌فایده نیستند. آن‌ها رخ دادن خرابی را تأیید می‌کنند، کد توقفی برای جست‌وجو در اینترنت در اختیارتان می‌گذارند و محل فایل دامپ حافظه روی دیسک را نشان می‌دهند؛ اما هرگز نمی‌گویند خرابی چرا رخ داده است. همهٔ گزارش‌هایی که بررسی کردم، سرانجام به یک مقصد می‌رسیدند: فایل دامپ حافظه. پاسخ کامل فقط همان‌جا نهفته بود.

WinDbg همچنان بهترین ابزار برای خواندن گزارش‌های خرابی است

WinDbg هر بار درایور مقصر را شناسایی کرد

WinDbg در هر سه خرابی، myfault.sys را به‌عنوان عامل مشکل معرفی کرد. در خرابی 0x139 که صفحهٔ خرابی و همهٔ ابزارهای داخلی دیگر هیچ سرنخی ارائه نکردند، تنها WinDbg توانست علت را توضیح دهد. سطر ERROR_CODE این مشکل را سرریز بافر مبتنی بر پشته توصیف کرد؛ دقیقاً همان کاری که گزینهٔ تخریب پشته در NotMyFault انجام می‌دهد. در هر سه آزمایش، این تنها توضیح روشن و قابل‌فهمی بود که یکی از ابزارها ارائه کرد.

می‌دانم که WinDbg ظاهراً ابزاری ویژهٔ توسعه‌دهندگان است و از نظر فنی هم همین‌طور است؛ اما کار با آن از آنچه به نظر می‌رسد ساده‌تر است. کافی است WinDbg را از مایکروسافت استور یا با winget نصب کنید، آن را با دسترسی مدیر اجرا کنید، پروندهٔ ریزدامپ را باز کنید ــ که به‌طور پیش‌فرض در C:\Windows\Minidump ذخیره می‌شود ــ و فرمان !analyze -v را اجرا کنید. سپس در خروجی به‌دنبال سه خط بگردید: BUGCHECK_CODE کد توقف را نشان می‌دهد، IMAGE_NAME مشخص می‌کند کدام درایور از کار افتاده است و ERROR_CODE، در صورت وجود، علت را با زبانی ساده توضیح می‌دهد. در آزمایش‌های من، IMAGE_NAME هر بار myfault.sys را نشان داد.

البته چند نکته و محدودیت را هم باید صادقانه در نظر گرفت:

• نخستین باری که یک پروندهٔ دامپ را در WinDbg باز می‌کنید، اتصال اینترنت لازم است؛ زیرا این برنامه نمادهای اشکال‌زدایی را از سرورهای مایکروسافت دریافت می‌کند.
• در آزمایش سرریز بافر، Driver Verifier نیز به تشخیص کمک کرد؛ این ابزار خرابی داده‌ها را همان‌جا که آغاز می‌شود به دام می‌اندازد، بنابراین با بهترین حالت ممکن روبه‌رو بودیم. در خرابی‌های واقعی، اگر Verifier فعال نباشد، ممکن است آسیب حافظه دیرتر آشکار شود و تقصیر به‌کلی به گردن درایور دیگری بیفتد.

بااین‌همه، حتی با وجود این محدودیت‌ها، WinDbg علت تک‌تک خرابی‌هایی را که برایش ایجاد کردم پیدا کرد؛ درحالی‌که ابزارهای داخلی ویندوز هر بار از کد توقف فراتر نرفتند.

یک نکتهٔ پایانی: مطمئن شوید ویندوز برای ذخیرهٔ دامپ‌های کوچک حافظه تنظیم شده است. به مسیر «ویژگی‌های سیستم > پیشرفته > راه‌اندازی و بازیابی > تنظیمات» بروید و نوع دامپ را روی «دامپ کوچک حافظه» بگذارید. بدون پروندهٔ دامپ، WinDbg چیزی برای خواندن ندارد.

بهترین سرنخ خرابی، پرونده‌ای است که ویندوز از پیش ذخیره می‌کند

اغلب برای یافتن علت خرابی و راه برطرف‌کردن آن به کدهای خطا تکیه می‌کنم: کد را جست‌وجو می‌کنید، چند راه‌حل عمومی را می‌آزمایید و امیدوار می‌مانید که یکی از آن‌ها جواب بدهد. اما ویندوز هر بار که از کار می‌افتد، پاسخ واقعی را در یک پروندهٔ دامپ ثبت می‌کند. همهٔ ابزارهای داخلی‌ای که آزمودم متوجه وقوع خرابی می‌شدند، ولی هیچ‌کدام نمی‌توانستند بگویند کدام درایور باعث آن شده است.

ذخیرهٔ دامپ‌های کوچک حافظه را فعال نگه دارید و WinDbg را نصب کنید. دفعهٔ بعد که رایانه‌تان از کار بیفتد، دقیقاً خواهید دانست چه چیزی باعث آن شده است.

منبع: این مطلب ترجمه و بومی‌سازی مقاله‌ای از MakeUseOf به قلم Tashreef Shareef است. مشاهده مقاله اصلی