علت هنگ کردن و کرش کردن ویندوز را به کمک هوش مصنوعی پیدا کنید

کامپیوترم هر چند هفته یک بار دچار کرش شدید می‌شد و هر کاری می‌کردم به نتیجه‌ای نمی‌رسیدم. هیچ هشداری هم در کار نبود. سیستم ناگهان خاموش می‌شد و دوباره راه‌اندازی می‌شد و وقتی ویندوز بالا می‌آمد، دیگر هیچ چیزی روی صفحه وجود نداشت که نشان دهد چه اتفاقی افتاده است.

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

بنابراین، به جای اینکه با حدس و گمان جلو بروم، اطلاعات مربوط به کرش‌ها را همراه با اسکرین‌شات و فایل‌های Mini-dump مربوط به هر صفحه آبی مرگ یا BSOD در اختیار Claude گذاشتم. این کار به یکی از مفیدترین جلسات عیب‌یابی که تا به حال داشته‌ام تبدیل شد و در نهایت علت مشکلی را پیدا کرد که به‌تنهایی احتمالاً هرگز نمی‌توانستم به آن برسم.

در ادامه با گیم‌پلنت همراه باشید تا یک مثال جالب از بررسی مشکل هنگ کردن ویندوز ۱۱ به کمک هوش مصنوعی Claude را بررسی کنیم، شاید سیستم ویندوزی شما هیچ اشکال سخت‌افزاری نداشته باشد و به کمک هوش مصنوعی، مشکلات عجیب آن رفع شود.

ویندوز می‌دانست چه اتفاقی افتاده، اما من نمی‌توانستم اطلاعاتش را بخوانم

تمام شواهد از همان ابتدا روی هارد کامپیوترم وجود داشت

ویندوز از قبل اطلاعات مربوط به هر کرش را ثبت می‌کند و کامپیوتر من هم ردپای کاملی از این اتفاقات به جا گذاشته بود. Reliability Monitor یک جدول زمانی مرتب از خطاها و خرابی‌هایی که طی چند هفته گذشته اتفاق افتاده بود، نشان می‌داد.

Event Viewer هم خطاهای مربوط به هر کرش را ثبت کرده بود و فایل‌های Mini-dump موجود در مسیر C:\Windows\Minidump نیز لحظه‌ای را که سیستم دچار مشکل شده بود، ثبت کرده بودند.

مشکل اینجا بود که تفسیر این اطلاعات اصلاً ساده نبود. نمودار Reliability Monitor من طی یک ماه گذشته دائماً وضعیت بدتری پیدا کرده بود. Event Viewer هم بیش از 41 هزار ورودی داشت که باید بین آنها جست‌وجو می‌کردم. از طرف دیگر، فایل‌های خام Mini-dump بدون استفاده از یک Debugger و داشتن دانش کافی درباره چیزهایی که باید به دنبالشان بگردم، عملاً قابل‌خواندن نبودند.

من چنین تخصصی نداشتم. بنابراین از صفحه اطلاعات یک اسکرین‌شات گرفتم، همه چیز را داخل Claude قرار دادم و اجازه دادم خودش اطلاعات را بررسی کند.

در ابتدا همه چیز مقصر به نظر می‌رسید

Event Viewer پر از خطاهای ترسناکی است که لزوماً مهم نیستند

در مراحل اولیه بررسی، موارد گمراه‌کننده زیادی پیدا شد. Claude ابتدا به اورکلاک پردازنده با Intel XTU مشکوک شد که با توجه به سیستم من، حدس منطقی‌ای بود. اما بعد از بررسی اطلاعات Event Viewer، نظرش را تغییر داد و دو مورد هنگ کردن درایورهای Nvidia را مطرح کرد.

نکته جالب این بود که Claude توانست بیش از 41 هزار رویداد ثبت‌شده دیگر را که صرفاً نویز معمول ویندوز بودند، کنار بگذارد.

اگر همان‌جا متوقف می‌شدم، احتمالاً درایور قدیمی‌تر کارت گرافیک را دوباره نصب می‌کردم، احساس می‌کردم مشکل را حل کرده‌ام و دو هفته بعد دوباره با همان کرش مواجه می‌شدم.

رویدادی که بیش از همه توجهم را جلب کرده بود، Kernel-Power 41 بود و Claude کمک کرد از این سرنخ اشتباه عبور کنم. Event 41 فقط می‌گوید کامپیوتر بدون انجام فرایند صحیح خاموش شدن، از کار افتاده است؛ به همین دلیل ویندوز هنگام راه‌اندازی دوباره آن را ثبت می‌کند.

این رویداد تأیید می‌کند که سیستم دچار کرش شده، اما هیچ اطلاعاتی درباره علت اصلی آن نمی‌دهد. به گفته Claude، پاسخ واقعی را باید در BugcheckCode و فایل‌های Dump پیدا می‌کردیم. بنابراین بررسی را از همان‌جا ادامه دادیم.

حتی Claude باعث شد RAM را هم مقصر ندانم

پروفایل XMP سیستم من کاملاً مشکوک به نظر می‌رسید

یکی از فایل‌های Dump شامل خطای PAGE_FAULT_IN_NONPAGED_AREA بود. این خطا را جدی گرفتم، چون هر کسی که با صفحه آبی مرگ سر و کله زده باشد، می‌داند چنین خطایی معمولاً یکی از مظنون‌های اصلی مشکلات RAM است. ضمن اینکه سیستم من از یک پروفایل XMP هم استفاده می‌کند.

اما Claude نه بی‌دلیل این احتمال را رد کرد و نه روی آن پافشاری کرد. گفت اگر فقط همین خطا را در نظر بگیریم، بله، حافظه RAM واقعاً باید در ابتدای فهرست مظنون‌ها قرار بگیرد.

با این حال، RAM خراب معمولاً باعث خطاهای تصادفی در فرایندهای مختلف می‌شود؛ یعنی خرابی می‌تواند هر بار در جایی اتفاق بیفتد که سلول معیوب حافظه در آن مورد استفاده قرار گرفته است. اما اینکه دقیقاً یک مسیر کد مشخص، سه بار طی دو ماه با همان شکل مشکل مواجه شود، چندان با خرابی RAM مطابقت ندارد.

با این حال، Claude پیشنهاد کرد برای اطمینان، تست MemTest را یک شب کامل اجرا کنم. چون این تست رایگان است و کنار گذاشتن کامل احتمال خرابی سخت‌افزار بدون آزمایش، بیش از حد خوش‌بینانه خواهد بود.

صادقانه بگویم، همین رویکرد محتاطانه برای من حتی از خود تشخیص نهایی هم ارزشمندتر بود.

سه فایل Crash Dump و یک نام مشترک

مقصر برنامه‌ای بود که تقریباً به آن فکر نمی‌کردم

خروجی Debugger مربوط به سه کرش را که طی دو ماه اتفاق افتاده بودند، در اختیار Claude گذاشتم و اینجا بود که ماجرا واقعاً جالب شد.

در نگاه اول، این کرش‌ها هیچ ارتباطی با یکدیگر نداشتند. کدهای Bugcheck متفاوت بودند و هر بار یک درایور متفاوت به عنوان عامل خطا معرفی می‌شد. در یکی از آنها فیلتر فایل‌های ابری OneDrive مقصر شناخته شده بود و در دیگری یک درایور کاملاً متفاوت مربوط به سیستم فایل.

این الگوی پراکنده معمولاً می‌تواند نشانه خرابی سخت‌افزار باشد. اما دو چیز در تمام این کرش‌ها ثابت بود و Claude هر دو را پیدا کرد.

هر کرش در نهایت به یک فرایند مشترک به نام CrossDeviceSer مربوط می‌شد. این فرایند درواقع سرویس مورد استفاده Windows Phone Link است. از طرف دیگر، در تمام کرش‌ها یک جست‌وجوی مشابه برای ویژگی‌های فایل از طریق همان مجموعه فیلترهای سیستمی انجام شده بود.

دلیل اینکه هر بار یک درایور متفاوت مقصر شناخته می‌شد، این بود که درخواست از چند فیلتر مختلف عبور می‌کرد و هر بار یک فیلتر متفاوت با حافظه خراب مواجه می‌شد.

در نتیجه، مقصر اصلی چیزی بود که شاید کمتر کسی به آن شک کند: Phone Link بی‌سروصدا باعث کرش سیستم من می‌شد و فایل‌های Placeholder مربوط به فضای ابری OneDrive هم مشکل را بدتر می‌کردند.

راه حل هیچ هزینه‌ای نداشت و کرش‌ها متوقف شدند

بعد از تمام این بررسی‌ها، راه حل تقریباً ناامیدکننده ساده بود.

OneDrive را حذف کردم تا عامل مربوط به فایل‌های Placeholder از بین برود، Phone Link را از طریق Microsoft Store به‌روزرسانی کردم و به‌روزرسانی معلق ویندوز را هم نصب کردم. این به‌روزرسانی دقیقاً شامل اصلاح درایورهایی بود که در Stack مربوط به کرش‌های سیستم من دیده می‌شدند.

همین.

RAM، منبع تغذیه و اورکلاک سیستم همگی از اتهام تبرئه شدند؛ یعنی دقیقاً همان قطعاتی که اگر به حدس زدن ادامه می‌دادم، احتمالاً پولم را صرف تعویض آنها می‌کردم.

بیش از یک ماه از آن زمان گذشته و نمودار Reliability Monitor که هفته‌ها روند نزولی داشت، بالاخره ثابت شده است. از آن زمان حتی یک مورد Event 41 هم ثبت نشده است.

من در ابتدا انتظار داشتم مجبور شوم برای خرید RAM یا منبع تغذیه جدید هزینه کنم، اما در نهایت فقط یک برنامه را حذف کردم و یک برنامه دیگر را به‌روزرسانی کردم.

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

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

گیم پلنت