رفع خطای App Not Responding در ویندوز

وقتی برنامه‌ای بارها Not Responding می‌شود اما دلیلش مشخص نیست، Event Viewer دقیق‌ترین منبع اطلاعاتی ویندوز برای ریشه‌یابی است. کافی است در Run یا جستجوی استارت عبارت eventvwr.msc را تایپ کنید تا این ابزار باز شود.

در پنجره باز شده مسیر Windows Logs بروید و روی Application کلیک کنید. اینجا فهرستی از رخدادهای برنامه‌ها بر اساس زمان نمایش داده می‌شود که می‌توانید بر اساس ساعت وقوع هنگ، رخداد مرتبط را پیدا کنید.

دو کد رخداد (Event ID) اهمیت ویژه‌ای دارند. Event ID 1000 معمولاً به معنای کرش کامل برنامه است، در حالی که Event ID 1002 دقیقاً همان چیزی است که به آن Application Hang می‌گویند؛ یعنی برنامه پاسخگو نبوده و ویندوز آن را متوقف کرده است.

با باز کردن جزئیات هر رخداد، بخش «Faulting module name» را بررسی کنید. این فیلد نام فایل DLL یا کتابخانه‌ای را نشان می‌دهد که واقعاً باعث هنگ شده، نه صرفاً نام برنامه اصلی.

برای مثال ممکن است برنامه Outlook هنگ کند اما مقصر واقعی یک افزونه (Add-in) یا درایور چاپگر باشد که در پس‌زمینه با آن تعامل دارد.

اگر الگوی تکرارشونده‌ای می‌بینید، مثلاً همیشه یک ماژول خاص در لحظه هنگ حضور دارد، می‌توانید مستقیماً همان افزونه یا نرم‌افزار جانبی را غیرفعال یا حذف کنید. این روش بسیار دقیق‌تر از حدس زدن یا امتحان کردن راه‌حل‌های عمومی است.

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

برای کاربران حرفه‌ای‌تر، فیلتر کردن رخدادها بر اساس Event ID (با گزینه Filter Current Log) کار را سریع‌تر می‌کند و نیازی به پیمایش دستی صدها رخداد بی‌ربط نیست. این ابزار به‌ویژه زمانی ارزشمند است که هنگ‌ها نامنظم و غیرقابل پیش‌بینی رخ می‌دهند و روش‌های ساده‌تر تشخیص کافی نبوده‌اند.

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

برای شروع، در Run عبارت msconfig را وارد کنید تا پنجره System Configuration باز شود. در تب Services، ابتدا گزینه «Hide all Microsoft services» را فعال کنید تا فقط سرویس‌های شخص ثالث نمایش داده شوند، سپس روی Disable all کلیک کنید.

در مرحله بعد به تب Startup بروید که در ویندوز ۱۰ و ۱۱ شما را به Task Manager هدایت می‌کند. تمام برنامه‌های فهرست‌شده را یکی‌یکی انتخاب کرده و Disable کنید. این برنامه‌ها معمولاً همان‌هایی هستند که به‌صورت خودکار با ویندوز اجرا می‌شوند.

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

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

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

نرم‌افزارهایی که معمولاً در این نوع تداخل‌ها مقصر شناخته می‌شوند شامل آنتی‌ویروس‌های قدیمی شخص ثالث، ابزارهای Overlay مانند Discord یا نرم‌افزارهای کنترل نور RGB کارت گرافیک، و درایورهای قدیمی چاپگر یا اسکنر هستند که هنوز به‌روزرسانی نشده‌اند.

پس از پایان عیب‌یابی، فراموش نکنید از طریق همان msconfig یا Task Manager سرویس‌ها و برنامه‌های ضروری را دوباره فعال کنید، در غیر این صورت برخی قابلیت‌های سیستم مانند آنتی‌ویروس یا بروزرسانی‌های خودکار برنامه‌ها از کار می‌افتند.

حافظه مجازی یا Virtual Memory بخشی از فضای دیسک است که ویندوز آن را مانند پشتیبان RAM استفاده می‌کند. وقتی رم فیزیکی سیستم پر می‌شود، ویندوز داده‌های کم‌کاربردتر را موقتاً در همین فایل صفحه‌بندی (Pagefile) ذخیره می‌کند تا برنامه‌ها متوقف نشوند.

اگر این فضا کوچک یا نامناسب تنظیم شده باشد، به‌محض باز بودن چند برنامه سنگین همزمان، سیستم دچار هنگ و کندی شدید می‌شود، حتی اگر پردازنده مشکلی نداشته باشد. این یکی از دلایل رایج و کمتر شناخته‌شده Not Responding در سیستم‌های با رم محدود (۴ تا ۸ گیگابایت) است.

برای بررسی و تنظیم آن، به System Properties بروید (با جست‌وجوی «advanced system settings»)، سپس در تب Advanced روی Settings مربوط به Performance کلیک کنید. در پنجره جدید دوباره تب Advanced را انتخاب کرده و روی Change در بخش Virtual Memory بزنید.

به‌طور پیش‌فرض گزینه «Automatically manage paging file size for all drives» فعال است و در اغلب موارد کافی است.

اما اگر سیستم چند درایو دارد، بهتر است این گزینه را غیرفعال کرده و به‌صورت دستی فضای پیجینگ را روی درایو SSD (نه HDD) قرار دهید، چون سرعت خواندن و نوشتن SSD تاثیر مستقیمی بر عملکرد این حافظه دارد.

برای سیستم‌های با رم کم، یک قاعده کلی رایج این است که حداقل اندازه (Initial Size) را ۱.۵ برابر رم فیزیکی و حداکثر (Maximum Size) را حدود ۳ برابر آن تنظیم کنید.

برای سیستم‌های با رم ۱۶ گیگابایت یا بیشتر، معمولاً حالت خودکار کاملاً کافی است و نیازی به دخالت دستی نیست.

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

یکی از دلایلی که کمتر به آن توجه می‌شود، خرابی فیزیکی یا جزئی ماژول‌های رم است. برخلاف تصور رایج، رم معیوب همیشه منجر به صفحه آبی (BSOD) نمی‌شود؛ گاهی فقط باعث هنگ‌های تصادفی و غیرقابل پیش‌بینی در برنامه‌های مختلف می‌شود.

ویندوز ابزاری داخلی و رایگان به نام Windows Memory Diagnostic دارد که می‌توانید با جست‌وجوی همین عبارت در استارت یا اجرای دستور mdsched.exe در Run آن را باز کنید.

پس از اجرا، دو گزینه نمایش داده می‌شود: «Restart now and check for problems» و «Check for problems the next time I start my computer». برای نتیجه فوری گزینه اول را انتخاب کنید تا سیستم ری‌استارت شده و تست به‌صورت خودکار قبل از ورود به ویندوز اجرا شود.

در حین تست می‌توانید کلید F1 را بزنید تا وارد بخش تنظیمات شوید و حالت «Extended» را به‌جای «Standard» انتخاب کنید. تست Extended زمان بیشتری می‌برد اما الگوهای بیشتری را برای خطاهای پنهان بررسی می‌کند و دقت تشخیص را بالا می‌برد.

پس از پایان تست و ورود به ویندوز، نتیجه معمولاً به‌صورت یک اعلان (Notification) نمایش داده می‌شود؛ اگر آن را از دست دادید، می‌توانید نتیجه را در Event Viewer، مسیر Windows Logs > System با جست‌وجوی منبع «MemoryDiagnostics-Results» پیدا کنید.

در صورت گزارش خطا، اگر سیستم بیش از یک ماژول رم دارد، بهتر است هر ماژول را جداگانه تست کنید تا مشخص شود کدام‌یک معیوب است؛ گاهی صرفاً جاگذاری مجدد (Reseat) رم در اسلات نیز مشکلات اتصال جزئی را برطرف می‌کند.

برای بررسی عمیق‌تر و حرفه‌ای‌تر، ابزار رایگان و بوت‌شونده MemTest86 گزینه‌ای دقیق‌تر از ابزار داخلی ویندوز است.

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

برای این کار به Settings > Windows Update > Update History بروید و گزینه Uninstall updates را انتخاب کنید. فهرستی از آپدیت‌های اخیر بر اساس تاریخ نصب نمایش داده می‌شود؛ آپدیتی که تاریخ نصبش با شروع مشکل هم‌زمان است را پیدا کرده و روی Uninstall کلیک کنید.

پس از حذف، سیستم را ری‌استارت کنید و رفتار برنامه‌ها را دوباره بررسی کنید. اگر مشکل برطرف شد، برای جلوگیری از نصب خودکار مجدد همان آپدیت، از گزینه «Pause updates for 7 days» در همان صفحه استفاده کنید تا زمان کافی برای عرضه نسخه اصلاح‌شده توسط مایکروسافت داشته باشید.

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

اگر حذف مستقیم آپدیت ممکن نبود یا گزینه Uninstall برای آن فعال نبود، ابزار عیب‌یاب داخلی «Windows Update Troubleshooter» را از مسیر Settings > System > Troubleshoot > Other troubleshooters اجرا کنید.

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

در مواردی که مشکل از یک درایور به‌روزرسانی‌شده توسط Windows Update است، نه خود سیستم‌عامل، می‌توانید در Device Manager به‌صورت جداگانه همان درایور را به نسخه قبلی بازگردانید (Roll Back Driver) بدون نیاز به حذف کل آپدیت ویندوز.

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

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

این مشکل به‌ویژه در لپ‌تاپ‌ها رایج است، جایی که فضای داخلی برای خنک‌کاری محدود است. تجمع گرد و غبار روی فن‌ها و هیت‌سینک، یا خشک‌شدن خمیر حرارتی (Thermal Paste) پس از چند سال استفاده، از علل اصلی افزایش دما هستند.

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

برای بررسی دما می‌توانید از ابزارهای رایگان مانند HWMonitor یا HWiNFO64 استفاده کنید که دمای لحظه‌ای پردازنده و کارت گرافیک را نمایش می‌دهند. به‌طور کلی دمای پایدار زیر ۸۰ تا ۸۵ درجه سانتی‌گراد در بار کاری معمولی قابل قبول است؛ عبور مکرر از این محدوده هشداردهنده است.

راهکارهای ساده شامل تمیز کردن دریچه‌های خروجی هوا با هوای فشرده، استفاده از پایه خنک‌کننده (Cooling Pad) برای لپ‌تاپ، و اجتناب از استفاده روی سطوح نرم مانند تخت یا مبل است که مانع جریان هوا می‌شوند.

برای دستگاه‌های بالای سه سال، تعویض خمیر حرارتی توسط تعمیرکار می‌تواند تفاوت محسوسی در دما و پایداری سیستم ایجاد کند.

برای کاربرانی که می‌خواهند بدون سردرگمی در جزئیات فنی Event Viewer، تصویری ساده و بصری از وضعیت پایداری سیستم داشته باشند، Reliability Monitor گزینه مناسبی است. این ابزار داخلی ویندوز است و نیازی به نصب چیزی ندارد.

برای باز کردن آن کافی است عبارت «Reliability History» را در جست‌وجوی استارت وارد کنید، یا دستور perfmon /rel را در Run اجرا کنید.

صفحه اصلی این ابزار یک نمودار خطی روزانه نمایش می‌دهد که «شاخص پایداری سیستم» (Stability Index) را از ۱ تا ۱۰ در طول زمان ترسیم می‌کند. هر افت ناگهانی در این نمودار نشانه‌ی وقوع یک یا چند رخداد ناپایداری در همان روز است.

زیر نمودار، آیکون‌های رنگی برای هر روز نمایش داده می‌شوند: آیکون قرمز با علامت ضربدر نشان‌دهنده خطاهای بحرانی مانند کرش یا هنگ برنامه است، در حالی که آیکون زرد هشدار به مشکلات جزئی‌تر اشاره دارد.

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

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

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

در پایین پنجره گزینه «Save Reliability History» وجود دارد که امکان ذخیره کل گزارش را برای ارسال به پشتیبانی فنی یا بررسی دقیق‌تر بعدی فراهم می‌کند.