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

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

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

برای برنامه‌های بسته‌بندی‌شده در ویندوز ۱۱، به Settings > Apps > Installed apps بروید، منوی سه‌نقطه کنار برنامه را باز کنید و Advanced options را انتخاب کنید. گزینه Repair تلاش می‌کند اجزای برنامه را بدون پاک‌کردن داده‌های شخصی ترمیم کند.

اگر نتیجه نگرفتید، Reset مرحله بعدی است؛ اما این گزینه معمولاً داده محلی، نشست ورود، مجوزهای انتخاب‌شده و تنظیمات همان برنامه را به حالت اولیه برمی‌گرداند.

همه برنامه‌ها Advanced options ندارند. در نرم‌افزارهای کلاسیک، از صفحه Installed apps گزینه Modify را بررسی کنید یا در Control Panel به Programs and Features بروید و Repair یا Change را بزنید. وجود این گزینه به بسته نصب سازنده بستگی دارد.

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

اگر برنامه از Microsoft Store دریافت شده، صفحه Library فروشگاه را باز کنید و ابتدا به‌روزرسانی همان برنامه و Store را بگیرید. اجرای wsreset.exe فقط حافظه موقت Microsoft Store را پاک و فروشگاه را دوباره باز می‌کند؛ این فرمان تنظیمات یک برنامه معیوب را مستقیماً تعمیر نمی‌کند.

بنابراین زمانی مفید است که نصب یا به‌روزرسانی برنامه‌های فروشگاه گیر کرده باشد، نه هر بار که یک برنامه پیام Not Responding نشان می‌دهد.

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

پاک‌کردن دستی پوشه‌های AppData یا ProgramData را به‌عنوان مرحله عمومی انجام ندهید، چون ممکن است داده لازم برنامه دیگری یا امکان بازگشت را از بین ببرد. راهنمای خود سازنده برای پاک‌سازی کامل اولویت دارد.

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

اگر همه فایل‌ها مشکل دارند و Repair، Reset یا نصب رسمی تغییری ایجاد نمی‌کند، زمان بررسی رویدادهای ثبت‌شده و وابستگی‌های مشترک برنامه رسیده است.

پیام Not Responding فقط می‌گوید رابط برنامه در زمان مورد انتظار به پیام‌های ویندوز پاسخ نداده است؛ علت را مشخص نمی‌کند. Event Viewer می‌تواند جزئیات فنی همان لحظه را نشان دهد.

رویداد 1002 با منبع Application Hang معمولاً به هنگ مربوط است، در حالی که رویداد 1000 اغلب برای بسته‌شدن یا خطای برنامه ثبت می‌شود. این شناسه‌ها سرنخ‌اند، نه تشخیص قطعی.

برای جست‌وجوی دقیق، زمان بروز مشکل را تا حد دقیقه یادداشت کنید. سپس با Win + R فرمان eventvwr.msc را اجرا کنید، به Windows Logs > Application بروید و فهرست را تازه کنید. از Filter Current Log برای محدودکردن بازه زمانی یا شناسه‌های 1002 و 1000 کمک بگیرید.

هر خطای قرمز مرتبط نیست؛ نام فایل اجرایی، مسیر برنامه و زمان باید با نمونه‌ای که دیده‌اید منطبق باشد.

در زبانه General و نمای XML بخش Details، به نام برنامه، نسخه، مسیر، Faulting module، Exception code و اطلاعات Hang یا Fault bucket توجه کنید. همه فیلدها در هر رویداد وجود ندارند.

اگر نام یک DLL، درایور یا مؤلفه امنیتی تکرار می‌شود، آن نام جهت بررسی بعدی می‌دهد؛ با دیدن یک بار نام ماژول، آن را فوراً حذف یا جایگزین نکنید.

الگو از یک رویداد منفرد ارزشمندتر است. سه هنگ با زمان‌ها و کارهای مشابه که همگی به یک نسخه یا ماژول اشاره می‌کنند، فرضیه قوی‌تری می‌سازند. در مقابل، رویدادهای متفاوت ممکن است نشان دهند فشار منابع، فایل ورودی یا چند عامل مستقل دخیل است.

برای مقایسه، نسخه برنامه، نسخه ویندوز، نوع فایل بازشده و آخرین تغییر انجام‌شده را کنار هر زمان ثبت کنید.

برای ارسال به پشتیبانی، از Copy > Copy Details as Text استفاده کنید یا رویدادهای مرتبط را در قالب EVTX ذخیره کنید. پیش از اشتراک‌گذاری، نام کاربری، مسیر پوشه شخصی، نام سند و هر داده حساس را بازبینی کنید.

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

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

یک تغییر انجام دهید، همان کار قبلی را تکرار کنید و ببینید زمان، ماژول یا نوع رویداد بعدی واقعاً عوض شده است.

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

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

برخی برنامه‌های Office حالت امن داخلی دارند. پس از بستن کامل برنامه، با Win + R می‌توان برای نمونه winword /safe، excel /safe یا outlook /safe را اجرا کرد.

اگر هنگ در این حالت تکرار نشد، از بخش Add-ins برنامه افزونه‌ها را یکی‌یکی غیرفعال و پس از هر تغییر دوباره آزمایش کنید. خاموش‌کردن همه افزونه‌ها فقط نقطه آغاز است و افزونه مقصر را مشخص نمی‌کند.

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

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

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

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

برای تعمیر پروفایل داخلی برنامه، ابتدا از نشانک‌ها، قالب‌ها، حساب‌ها، امضاها و داده محلی نسخه پشتیبان بگیرید. پوشه AppData را یکجا پاک نکنید. اگر سازنده گزینه ساخت پروفایل تازه یا Reset settings دارد، همان مسیر مستند را ترجیح دهید.

تغییر نام یک پوشه تنظیمات فقط زمانی منطقی است که محل دقیق و پیامد آن در راهنمای رسمی برنامه مشخص باشد و راه بازگشت داشته باشید.

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

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

عدد مصرف RAM به‌تنهایی نشان نمی‌دهد ویندوز با کمبود حافظه روبه‌رو است. شاخص Committed مقدار حافظه‌ای را نشان می‌دهد که برنامه‌ها درخواست کرده‌اند و ویندوز باید آن را با RAM یا فایل صفحه‌بندی پشتیبانی کند.

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

در Task Manager به Performance > Memory بروید و مقدار Committed را به شکل X/Y ببینید. عدد اول مصرف جاری و عدد دوم حد تقریبی تعهد است. آن را پیش از اجرای برنامه و هنگام بروز مشکل مقایسه کنید.

نزدیک‌شدن مداوم X به Y مهم‌تر از یک جهش کوتاه است. مرورگر با تب‌های بسیار، ماشین مجازی، ویرایشگر رسانه یا برنامه‌ای با نشت حافظه می‌تواند این فاصله را کم کند.

فایل pagefile بهتر است در بیشتر سیستم‌ها روی حالت مدیریت خودکار ویندوز بماند. توصیه قدیمی تعیین اندازه ثابت بر پایه فرمولی مانند یک‌ونیم برابر RAM برای همه رایانه‌ها مناسب نیست.

غیرفعال‌کردن pagefile نیز حتی با RAM زیاد می‌تواند سقف تعهد را کاهش دهد و ثبت بعضی فایل‌های خطای حافظه را مختل کند. افزایش بی‌حساب آن هم نشت حافظه یا نیاز واقعی برنامه را درمان نمی‌کند.

برای بازبینی تنظیم، عبارت View advanced system settings را جست‌وجو کنید؛ سپس در Performance گزینه Settings، زبانه Advanced و بخش Virtual memory را باز کنید. اگر قبلاً مقدار سفارشی گذاشته‌اید، از آن یادداشت بگیرید و گزینه Automatically manage paging file size for all drives را فعال کنید.

پس از تأیید، راه‌اندازی دوباره لازم است. pagefile را روی دیسک خارجی، ناپایدار یا تقریباً پر قرار ندهید.

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

اگر فضای کافی وجود دارد ولی Committed پیوسته بالا می‌رود، نسخه برنامه، افزونه‌ها و اندازه پروژه را بررسی کنید، چون الگو می‌تواند به نشت حافظه اشاره کند.

Pagefile جای RAM کافی یا اصلاح نرم‌افزار معیوب را نمی‌گیرد. اگر در لحظه هنگ فاصله زیادی تا سقف Committed دارید، تنظیم حافظه مجازی را علت اصلی فرض نکنید و سراغ شواهد دیگر بروید.

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

بسیاری از برنامه‌ها همه اجزای لازم را همراه خود ندارند و از مؤلفه‌های مشترک ویندوز استفاده می‌کنند. Visual C++ Redistributable، .NET Desktop Runtime، .NET Framework و Microsoft Edge WebView2 Runtime نمونه‌های رایج‌اند.

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

ابتدا نام ماژول ثبت‌شده در رویداد خطا، صفحه نیازمندی‌های سازنده و فهرست Installed apps را بررسی کنید. بسته‌های Visual C++ با معماری x86 و x64 می‌توانند هم‌زمان لازم باشند؛ حتی در ویندوز ۶۴ بیتی، یک برنامه ۳۲ بیتی به بسته x86 نیاز دارد.

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

برای بسته Visual C++ موجود، در Installed apps گزینه Modify و سپس Repair را انتخاب کنید. اگر بسته لازم وجود ندارد یا تعمیر شکست می‌خورد، نصب‌کننده را فقط از صفحه رسمی Microsoft یا لینک رسمی سازنده برنامه بگیرید.

دانلود یک فایل DLL منفرد از سایت‌های ناشناس و کپی آن در System32 یا پوشه برنامه راه‌حل امنی نیست؛ نسخه، معماری و امضای فایل ممکن است ناسازگار یا آلوده باشد.

.NET Framework بخشی از قابلیت‌های ویندوز است، اما نسخه‌های جدید .NET و Desktop Runtime بسته‌های جداگانه و هم‌زمان‌پذیر هستند. نام مشابه آن‌ها نباید باعث شود یکی را جای دیگری نصب کنید. نیازمندی دقیق برنامه را بخوانید.

برای Framework از Windows Features و ابزارهای رسمی تعمیر استفاده کنید؛ برای .NET جدید، Runtime و معماری اعلام‌شده سازنده را از Microsoft بگیرید. نصب همه نسخه‌های موجود عیب‌یابی را مبهم می‌کند.

WebView2 رابط وب را داخل برنامه‌هایی مانند ابزارهای اداری، پیام‌رسان‌ها و صفحه‌های ورود نمایش می‌دهد. اگر بخش وب چند برنامه سفید یا بی‌پاسخ است، وجود و نسخه Microsoft Edge WebView2 Runtime را بررسی و از گزینه Repair یا نصب‌کننده رسمی استفاده کنید.

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

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

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

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

ساخت یک حساب آزمایشی راه تشخیص است؛ این کار به‌تنهایی ثابت نمی‌کند که باید حساب اصلی را کنار بگذارید.

در Settings به Accounts > Other users بروید و یک حساب جداگانه موقت بسازید. برای آزمایش اولیه، حساب استاندارد کافی است مگر برنامه واقعاً دسترسی مدیریتی بخواهد. از حساب فعلی خارج شوید و وارد حساب تازه شوید تا نشست و پردازه‌های پروفایل قبلی باقی نمانند.

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

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

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

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

کل AppData یا شاخه‌های رجیستری را کورکورانه حذف نکنید؛ این کار ممکن است چند برنامه را درگیر کند.

اگر ناچار به مهاجرت شدید، پوشه‌های شخصی مانند Documents، Pictures و Desktop را انتخابی منتقل و برنامه‌های مخصوص کاربر را دوباره نصب کنید. فایل NTUSER.DAT یا کل AppData را به پروفایل تازه کپی نکنید، زیرا همان پیکربندی خراب را منتقل می‌کند.

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

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

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