Аварії Explorer.exe: виправляйте розширення оболонки як професіонал

February 8, 2026 • February 8, 2026 • Читання: 6 хв • Views: 0

Було корисно?

Якщо Explorer.exe аварійно завершується, у вас немає «проблеми з Windows». У вас є проблема з плагіном, поки не доведено протилежне. Explorer — це хост-процес для половини десктопного досвіду: перегляд файлів, контекстні меню правої кнопки, прев’ю, ескізи, вкладки властивостей. І кожен постачальник з «корисною» інтеграцією може прилаштувати до нього код.

Наслідок: ненадійне розширення оболонки може відключити ваш файловий менеджер так, ніби це 1999 рік, і ми всі щойно дізналися, що таке DLL. Добра новина: зазвичай це можна виправити без перевстановлення Windows, без молитов і без «просто не клацайте правою кнопкою». Потрібна дисциплінована петля тріажу: ідентифікувати помилку, ізолювати розширення, безпечно вимкнути його, а потім знову ввімкнути те, що справді потрібно.

Як Explorer.exe насправді падає (і чому розширення оболонки — головні підозрювані)

Explorer.exe одночасно інтерфейс і платформа. Він відображає папки та робочий стіл, але також завантажує зоопарк COM-об’єктів, які реалізують «розширення оболонки». Ці розширення викликаються для:

Обробників контекстного меню (пункти у меню правої кнопки)
Провайдерів ескізів (thumbnail providers) (зображення, відео, PDF, CAD‑файли, дивні пропрієтарні формати)
Обробників прев’ю (панель прев’ю праворуч)
Обробників вкладок властивостей (додаткові вкладки в властивостях файлу)
Обробників накладання значків (бейджі статусу синхронізації, як‑от галочки)
Розширень простору імен (віртуальні папки, хмарні диски, спеціальні уявлення)

Багато з цих компонентів виконуються в процесі. Тобто: Explorer завантажує DLL розширення в свій простір пам’яті. Якщо ця DLL виконує звернення до некоректної пам’яті, зависає, руйнує метадані купи або викидає необроблену виняткову ситуацію, заплатить Explorer.

Ключова ментальна модель: аварія Explorer часто — це «стороння DLL, що падає всередині Explorer». Це не виправиш SFC і молитвами. Це виправляється знаходженням модуля й контролем того, що завантажується.

Цитата, яку варто приклеїти на монітор:

Переказана ідея — «Сподівання — не стратегія.» (широко цитують в інженерії й операціях; використовуйте як нагадування, не як бібліографічне посилання)

Також майте на увазі два загальні класи збоїв:

Аварія: Explorer завершується й перезапускається (ви бачите мережу панелі завдань, вікна зникають, потім повертаються).
Зависання: Explorer перестає відповідати (крутиться курсор, повідомлення «Не відповідає», вікно файлу заморожене). Іноді він потім відновлюється; іноді його доводиться вбивати.

Аварії зазвичай простіші: ви отримуєте faulting module, код винятку й іноді дамп. Зависання теж часто пов’язані з розширеннями оболонки, але можуть бути викликані мережевими шляхами, офлайн‑дисками, поломкою синхронізації хмари або драйверами антивірусу. Ми розглянемо обидва випадки.

Швидкий план діагностики

Це порядок дій на випадок «потрібен файловий менеджер до наступної наради». Не імпровізуйте. Дотримуйтеся плану.

1) Підтвердіть тригер і звузьте область впливу

Падає при правому кліку? Підозрюйте обробники контекстного меню.
Падає при виборі файлу (один клік) або відкритті папки? Підозрюйте провайдерів ескізів/обробники прев’ю/вкладок властивостей.
Падає тільки в конкретній папці? Підозрюйте обробник, прив’язаний до типу файлу, або пошкоджений кеш ескізів, або мережеве перенаправлення.
Падає лише для одного профілю користувача? Підозрюйте реєстрацію розширення на рівні користувача, корупцію профілю або інтеграцію додатку для цього користувача.

2) Читайте докази, перш ніж «виправляти» щось

Заберіть останні записи Application Error для Explorer.exe (Переглядач подій). Ідентифікуйте Faulting module і Exception code.
Перевірте записи Windows Error Reporting (WER) на той же час аварії; вони часто конкретніше вказують модуль.

3) Доведіть, що це стороннє розширення, чистим переключенням

Завантажтеся в безпечному режимі (Safe Mode) або зробіть Clean Boot і подивіться, чи стабілізується Explorer.
Якщо стабільно: продовжуйте вимикати не‑Microsoft розширення оболонки і вмикати їх пакетами.
Якщо не стабільно: можлива корупція ОС, проблеми файлової системи, помилки диска або критичний компонент Windows (менш поширено, але реально).

4) Вимикайте спочатку категорії з високим ризиком

Обробники контекстного меню
Провайдери ескізів / обробники прев’ю
Обробники накладання значків (особливо клієнти синхронізації)

5) Зафіксуйте дамп процесу, якщо модуль неочевидний

Якщо Переглядач подій дає мало інформації (часто «ntdll.dll»), зніміть дамп аварійного процесу Explorer і перегляньте список завантажених модулів. Не потрібно ставати асом налагодження; потрібно ідентифікувати DLL від постачальника, яка не мала б там бути.

Цікаві факти & коротка історія (тур «чому Windows така»)

Розширення оболонки походять ще з ери Windows 95, коли Microsoft просувала shell як розширювану платформу для заохочення екосистемної інтеграції.
COM — це проводка: більшість розширень оболонки — це COM‑об’єкти, зареєстровані під конкретними ключами ShellEx у реєстрі, які Explorer інстанціює під час виконання.
Виконання в процесі було оптимізацією: завантаження DLL у Explorer уникає міжпроцесного маршалінгу, роблячи контекстні меню й ескізи «миттєвими». Але це також означає, що одна погана DLL може викопати котлован під Explorer.
Накладки значків обмежені: Windows показує лише невелику кількість накладок одночасно, і кілька клієнтів синхронізації конкурують за ці слоти, іноді в непередбачуваному порядку.
Панель прев’ю стала масовою у Vista/Windows 7, і з нею з’явилася хвиля багів обробників прев’ю від постачальників, які парсили складні формати прямо в Explorer.
Клієнти хмарної синхронізації нормалізували накладки та контекстні меню: OneDrive, Dropbox, Box, Google Drive та корпоративні інструменти всі впроваджують інтеграції — корисні, поки оновлення одного з них не зламається.
Windows Error Reporting (WER) змінила гру: після XP збір звітів про аварії став структурованішим, і журнали подій почали висвітлювати «faulting module name» у вигляді, корисному для адміністраторів.
«Faulting module: ntdll.dll» зазвичай симптом, а не причина: ntdll — це місце, куди піднімаються винятки; реальний винуватець часто — стороння DLL, яка раніше пошкодила пам’ять.
Поведінка перезапуску Explorer умисна: Windows перезапускає його, щоб робочий стіл залишався придатним до використання, що добре — поки не почнеться цикл аварій і ви не зможете нічого клацнути.

Жарт №1: Explorer завантажує розширення оболонки так само, як конференція розміщує спонсорів: один поганий стенд — і день уже зіпсовано.

Практичні завдання: команди, виводи, рішення

Нижче — практичні завдання, які можна виконати в привілейованому терміналі PowerShell (команди, показані тут, придатні у типовому середовищі Windows). Кожне завдання містить: команду, приклад виводу, що це означає і яке рішення прийняти.

Task 1: Confirm Explorer restarts and collect basic crash timing

cr0x@server:~$ tasklist /FI "IMAGENAME eq explorer.exe"
Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
explorer.exe                  6124 Console                    1     82,340 K

Що це означає: Explorer наразі працює з PID 6124. Якщо він постійно змінюється після кожної аварії — ви в циклі перезапуску.

Рішення: Якщо PID змінюється під час симптому, перейдіть одразу до завдань з Переглядачем подій/WER; не витрачайте час на «можливо, це мережа».

Task 2: Pull recent Explorer application errors from Event Log

cr0x@server:~$ wevtutil qe Application /q:"*[System[(EventID=1000)]] and *[EventData[Data='explorer.exe']]" /c:5 /f:text
Event[0]:
  Log Name: Application
  Source: Application Error
  Event ID: 1000
  Faulting application name: explorer.exe, version: 10.0.22621.1
  Faulting module name: acmecadthumbs.dll, version: 4.2.0.18
  Exception code: 0xc0000005
  Fault offset: 0x000000000001a2f0

Що це означає: Аварія відбулася всередині acmecadthumbs.dll (провайдер ескізів). Виняток 0xc0000005 — це порушення доступу — класичний баг нативного коду.

Рішення: Спочатку вимкніть розширення провайдера ескізів/прев’ю цього постачальника. Не починайте з SFC.

Task 3: Pull Windows Error Reporting (WER) crash entries for Explorer

cr0x@server:~$ wevtutil qe "Microsoft-Windows-WER-SystemErrorReporting/Operational" /q:"*[System[(EventID=1001)]]" /c:5 /f:text
Event[0]:
  Log Name: Microsoft-Windows-WER-SystemErrorReporting/Operational
  Source: Microsoft-Windows-WER-SystemErrorReporting
  Event ID: 1001
  Fault bucket: 1234567890123456789, type 5
  Event Name: APPCRASH
  P1: explorer.exe
  P4: acmecadthumbs.dll

Що це означає: WER підтверджує ту саму проблемну бібліотеку. Коли журнали Application Error нечіткі, WER може бути яснішим.

Рішення: Якщо WER послідовно вказує одну DLL, вважайте її головним підозрюваним і ізолюйте.

Task 4: Check if the crash is tied to Preview Pane

cr0x@server:~$ reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Modules\GlobalSettings\Sizer" /v PreviewPaneSizer
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Modules\GlobalSettings\Sizer
    PreviewPaneSizer    REG_BINARY    2a000000...

Що це означає: Панель прев’ю налаштована (не доказ, що вона ввімкнена зараз), але це підказка, що користувач її використовує. Багато обробників прев’ю крихкі.

Рішення: Якщо аварії відбуваються під час виділення файлів, тимчасово вимкніть панель прев’ю і протестуйте; якщо стабільно — зосередьтеся на обробниках прев’ю для відповідних типів файлів.

Task 5: Clean boot to separate shell extensions from startup chaos

cr0x@server:~$ bcdedit /enum {current}
Windows Boot Loader
-------------------
identifier              {current}
path                    \Windows\system32\winload.efi
safeboot                Minimal

Що це означає: Система налаштована на завантаження в безпечному режимі (Minimal). (Ви зробили б це навмисно; не залишайте так надовго.)

Рішення: Якщо Explorer працює в безпечному режимі, майже напевно ви шукаєте сторонній компонент. Плануйте цикл вимкнення/увімкнення.

Task 6: Turn off Safe Mode when you’re done testing

cr0x@server:~$ bcdedit /deletevalue {current} safeboot
The operation completed successfully.

Що це означає: Наступний перезавантаження буде звичайним. Люди забувають це і дивуються, чому не запускається VPN.

Рішення: Завжди знімайте прапорець safeboot після підтвердження поведінки. Тримайте середовище тестування під контролем.

Task 7: Enumerate non-Microsoft Explorer shell extensions via PowerShell registry scan

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved' | Select-Object -First 5"
PSPath       : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved
PSChildName  : {0E5AAE11-A475-4C5B-AB00-C66DE400274E}
PSDrive      : HKLM
PSProvider   : Microsoft.PowerShell.Core\Registry

Що це означає: Цей ключ — одне з місць, де перераховані схвалені розширення оболонки (але не єдиний). Потрібно зіставити CLSID з шляхами DLL у InprocServer32, щоб ідентифікувати постачальників.

Рішення: Використовуйте це як стартовий інвентар; потім зіставте CLSID з DLL у InprocServer32 і визначте постачальника.

Task 8: Map a CLSID to its in-process DLL

cr0x@server:~$ reg query "HKCR\CLSID\{0E5AAE11-A475-4C5B-AB00-C66DE400274E}\InprocServer32" /ve
HKEY_CLASSES_ROOT\CLSID\{0E5AAE11-A475-4C5B-AB00-C66DE400274E}\InprocServer32
    (Default)    REG_SZ    C:\Program Files\AcmeCloud\acmeshellext.dll

Що це означає: Цей CLSID реалізований acmeshellext.dll з «AcmeCloud» (гіпотетично). Це стороннє розширення оболонки, яке працює всередині Explorer.

Рішення: Якщо цей постачальник корелює з тригером аварії (правий клік, накладки, прев’ю), вимкніть його наступним кроком.

Task 9: List modules loaded into Explorer (when it’s stable long enough)

cr0x@server:~$ powershell -NoProfile -Command "(Get-Process explorer).Modules | Select-Object -First 10 | Format-Table ModuleName,FileName -Auto"
ModuleName        FileName
----------        --------
explorer.exe      C:\Windows\explorer.exe
ntdll.dll         C:\Windows\SYSTEM32\ntdll.dll
shell32.dll       C:\Windows\SYSTEM32\shell32.dll
acmeshellext.dll  C:\Program Files\AcmeCloud\acmeshellext.dll

Що це означає: Ви бачите сторонні DLL, завантажені в процес. Це грубий, але ефективний підхід, коли можна зіставити «завантажений модуль» із «аварією при правому кліці».

Рішення: Якщо підозріла DLL від постачальника з’являється і відповідає тригеру, вимкніть це розширення і повторіть тест.

Task 10: Check system file integrity (only after extension triage)

cr0x@server:~$ sfc /scannow
Beginning system scan. This process will take some time.
Windows Resource Protection did not find any integrity violations.

Що це означає: Файли ОС виглядають нормально. Це не прибирає сторонні розширення; це просто означає, що Windows явно не пошкоджена.

Рішення: Якщо SFC чистий і у вас є проблемна стороння бібліотека — зупиніться. Не продовжуйте «ремонтувати Windows» без потреби.

Task 11: Repair component store (when SFC reports issues it can’t fix)

cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1
The restore operation completed successfully.
The operation completed successfully.

Що це означає: Сховище компонентів відновлено. Це допомагає, якщо Explorer падає через пошкоджені системні компоненти (рідше, ніж баги розширень оболонки, але трапляється).

Рішення: Якщо після DISM+SFC аварії тривають, поверніться до ізоляції розширень. Корупція не повинна бути вашим стандартним поясненням.

Task 12: Check the disk quickly for obvious trouble

cr0x@server:~$ chkdsk C: /scan
The type of the file system is NTFS.
Stage 1: Examining basic file system structure ...
Windows has scanned the file system and found no problems.
No further action is required.

Що це означає: Базові метадані файлової системи в порядку. Якщо тут є помилки, проблеми Explorer можуть бути побічним ефектом.

Рішення: Якщо знайдені помилки, заплануйте вікно ремонту. Не ігноруйте проблеми диска, поки шукаєте UI-демонів.

Task 13: Identify slow network dependencies that look like “Explorer is frozen”

cr0x@server:~$ net use
New connections will be remembered.

Status       Local     Remote                    Network
-------------------------------------------------------------------------------
OK           Z:        \\fileserver01\design      Microsoft Windows Network
Unavailable  Y:        \\oldnas\archive           Microsoft Windows Network

Що це означає: Маповані диски містять недоступну ціль. Explorer любить опитувати їх і тоді «таємниче зависає» при переліченні папок або в «Цьому ПК».

Рішення: Видаліть або виправте недоступні мапінги (особливо старі NAS-шляхи). Якщо симптом — зависання, а не аварія, це високоприбуткова дія.

Task 14: Remove a dead mapped drive cleanly

cr0x@server:~$ net use Y: /delete
Y: was deleted successfully.

Що це означає: Explorer перестане намагатися вирішувати цей шлях, що може усунути зависання або довгі затримки у вікнах вибору файлів.

Рішення: Якщо це покращує стабільність, ваша проблема була не в «Explorer» як такому, а в вводу/виводу й таймаутах.

Task 15: Check for third-party filter drivers (AV/DLP) that can destabilize Explorer file operations

cr0x@server:~$ fltmc
Filter Name                     Num Instances    Altitude    Frame
------------------------------  -------------    --------    -----
WdFilter                        10               328010      0
acmeavflt                        6               321900      0

Що це означає: Мінідрайвери файлової системи в стеку. Більшість з них нормальні. Деякі — ні. Вони можуть викликати зависання під час перелічення або аварії в пов’язаних інтеграціях оболонки.

Рішення: Якщо ваша аварія/зависання корелює з доступом до файлів (відкриття папок, ескізи), розгляньте тимчасове відключення стороннього продукту безпеки в контрольованому тесті — або хоча б оновіть його.

Task 16: Capture a quick “what changed” list (recent installs/updates)

cr0x@server:~$ wmic qfe get HotFixID,InstalledOn | more
HotFixID  InstalledOn
KB5034765 1/12/2026
KB5034204 1/28/2026

Що це означає: Показує встановлені оновлення. Не ідеально для інсталяцій додатків, але корисно при кореляції «Explorer почав падати у вівторок» з графіком оновлень.

Рішення: Якщо аварія почалася одразу після оновлення постачальницького додатку (клієнт синхронізації, архіватор, переглядач CAD), надайте пріоритет цьому розширенню, навіть якщо й Windows теж оновлювалася.

Стратегія ізоляції, яка не згаяє ваш вечір

Ось помилка, яку я бачу у реальному житті: люди вимикають одну річ, перезавантажуються, тестують, вмикають, знову перезавантажуються, тестують… поки не настане термін. Вам потрібне мислення «бінарного пошуку» і схильність до найімовірніших категорій, що викликають аварії.

Step 1: Classify the trigger

Запишіть його, як інцидент‑звіт:

Дія‑тригер: «Правий клік будь-якого файлу» vs «Відкриття Завантажень» vs «Виділення PDF»
Обсяг: «Усі папки» vs «Одна шар» vs «Один тип файлів»
Рамки користувача: «Лише я» vs «цілий відділ»
Часування: «Після інсталяції X» vs «Після оновлення Windows»

Step 2: Confirm with Safe Mode or Clean Boot

Безпечний режим — це великий молоток, але він остаточний. Якщо Explorer стабільний у Safe Mode, можна припинити сумніватися в реальності.

Жарт №2: Safe Mode — це як безкофеїновий напій: не так весело, але саме він показує, що насправді викликає нервозність.

Step 3: Disable non-Microsoft shell extensions (but do it with control)

На практиці двома поширеними інструментами є: Sysinternals Autoruns і NirSoft ShellExView. Використовуйте те, що дозволяє ваша організація. Принцип той самий:

Сортуйте за Company і приховуйте записи Microsoft.
Вимикайте пакетами (наприклад, по 5–10), потім перезапускайте Explorer (не всю машину, якщо не потрібно).
Коли стабільність повернулася, знову ввімкніть половину останнього пакету, щоб звузити коло.

Якщо ви не можете використовувати сторонні інструменти (заблоковані кінцеві точки), багато можна зробити через реєстр і видалення батьківського продукту. Але в підприємствах найшвидший шлях зазвичай такий: «спочатку вимкнути розширення, потім вирішити оновити, відкатати або видалити продукт».

Step 4: Restart Explorer safely between tests

Explorer потребує перезапуску, щоб вивантажити розширення в процесі. Можна вийти/увійти або перезапустити процес. Перезапуск швидший:

cr0x@server:~$ taskkill /F /IM explorer.exe
SUCCESS: The process "explorer.exe" with PID 6124 has been terminated.

cr0x@server:~$ start explorer.exe

Що це означає: Ви примусово виконали чисте перезавантаження Explorer і його розширень.

Рішення: Використовуйте це між кожною ітерацією вимкнення/увімкнення, щоб переконатися, що ви тестуєте новий набір розширень.

Step 5: If logs blame ntdll.dll, don’t panic—raise your observability

Коли faulting module — ntdll.dll або KERNELBASE.dll, часто це місце, куди повідомляють про аварію, а не місце, де живе баг. Потрібно зібрати більше контексту:

Подивіться WER для додаткових підказок у «P4».
Перелічіть завантажені модулі Explorer і зіставте з відомими розширеннями.
Зніміть дамп і перегляньте список модулів (часто цього достатньо без глибокого аналізу стеку).

Три корпоративні міні‑історії з практики

Міні‑історія 1: Інцидент через неправильне припущення

Служба підтримки передала «Windows зламався» від команди дизайнерів. Explorer падав щоразу, коли вони відкривали папку проекту. Не «інколи». Не «рідко». Кожен раз. Адмін на виклику зробив те, що багато з нас робили під тиском: запустив SFC, DISM, перезавантажив і готував перевстановлення системи.

Але аварія була локалізована: лише та команда, лише папки проекту, лише на машинах з конкретним набором плагінів для CAD. Неправильне припущення було підступним: «Якщо Explorer падає, то винна ОС». Це зручний наратив, бо дає дозвіл заново образити систему.

Хтось нарешті подивився запис Application Error і побачив, що faulting module — не Windows. Це був провайдер ескізів для типу CAD‑файлів. Папка проекту містила тисячі таких файлів; Explorer намагався згенерувати ескізи, як користувач клацав по папці. Бум.

Виправлення було нудним: вимкнути цей обробник ескізів і поширити оновлений плагін від постачальника. Жодних перевстановлень. Жодних простоїв. У звіті інциденту була одна важлива рядок: «Ми припустили, що хост винен, а не плагін, який в нього вбудований». Цей рядок запобіг наступним трьом інцидентам.

Міні‑історія 2: Оптимізація, що обернулася проти

Команда інженерів десктопів намагалася підвищити відчутну швидкість роботи з файловими шарами. Вони пілотували сторонній «акселератор», що додавав дії в контекстне меню, накладки та агресивне кешування. У демо виглядало чудово: правий клік для завантаження, бейджі накладок скрізь і «розумний» префетчинг.

Потім почалося: Explorer іноді не падав — він зависав. Діалоги відкриття файлу фризили періодично. Користувачі не могли прикріпити файли до листів. Постачальник акселератора наполягав, що це «мережева проблема». Мережеві інженери наполягали, що це «десктоп‑проблема». Всі були праві і одночасно не праві.

Procmon показав, що Explorer чекав на розширення акселератора, яке чекало на мережевий виклик до кінцевої точки сервісу, яка час від часу зависала. Оскільки розширення виконувалось в процесі, UI‑потік блокувався. Оптимізація робила систему швидшою, коли вона працювала, і непридатною, коли ні. Це не продуктивність — це гра у фартах.

План відкату став фіксом: вимкнули накладки і обробники контекстного меню через політику, залишивши лише основну синхронізацію. «Додаткова цінність» продукту виявилася його крихкістю. Після видалення Explorer знову став нудним — у найкращому значенні цього слова.

Міні‑історія 3: Нудна, але правильна практика, що врятувала ситуацію

Фінансовий підрозділ мав сувору практику: будь‑який десктопний застосунок, що встановлював інтеграції оболонки, повинен пройти невелике передвиробниче кільце. Нічого особливого — пара користувачів у різних командах і щотижневий перегляд метрик аварій. Практику висміювали як «церемонію», аж поки вона не врятувала від масштабного безладу.

Популярний архіватор випустив оновлення, яке додало нові обробники контекстного меню і компонент прев’ю. У пілотному кільці Explorer почав падати при правому кліку в папках з великою кількістю архівів. Журнали подій вказали на новий DLL‑обробник. Пілот помітив це до того, як оновлення розповсюдили на fleet.

Виправлення було простим: заморозити оновлення, вимкнути новий обробник через корпоративну конфігурацію і чекати патч від постачальника. Ніяких героїчних всенародних заходів. Ніяких екстрених перевстановлень. Ніяких «користуйтесь веб‑інтерфейсом тиждень».

Це та практика, яка виглядає нудною на слайді і геніальною в продакшені. Мета — не бути кмітливим. Мета — уникати передбачуваних відмов.

Поширені помилки: симптом → корінь → виправлення

Цей розділ навмисно конкретний. Якщо ви впізнаєте симптоми — пропустіть дискусії і застосуйте виправлення.

1) Right-click instantly crashes Explorer

Симптом: Explorer перезапускається одразу після правого кліку по файлу/папці/порожньому місцю.
Корінь: Поганий обробник контекстного меню (часто від архіваторів, клієнтів синхронізації, систем контролю версій, інструментів безпеки).
Виправлення: Вимикайте не‑Microsoft обробники контекстного меню пакетами; перезапускайте Explorer між тестами; оновіть або видаліть батьківський застосунок після ідентифікації.

2) Crash happens when selecting files (not opening them)

Симптом: Одноклік по файлу або переміщення виділення викликає аварію; відкриття файлу безпосередньо через додаток може бути нормальним.
Корінь: Обробник прев’ю або провайдер ескізів падає під час парсингу метаданих/вмісту файлу.
Виправлення: Вимкніть панель прев’ю; очистіть кеш ескізів; вимкніть розширення ескізів/прев’ю для типу файлу; оновіть переглядач/плагін.

3) Explorer hangs for 30–120 seconds opening “This PC” or file dialogs

Симптом: Не відповідає протягом часу, потім відновлюється. Також уповільнені діалоги вибору файлів.
Корінь: Офлайн‑підключені диски, недоступні мережеві шари, застарілі домашні диски, або розширення оболонки, що виконує мережевий ввід‑вивід на потоці UI.
Виправлення: Приберіть мертві мапінги; виправте DFS‑цілі; вимкніть оверлеї синхронізації; перевірте резолюцію імен; використайте Procmon для підтвердження блокуючого виклику.

4) Explorer crash reports blame ntdll.dll

Симптом: Переглядач подій показує faulting module ntdll.dll або KERNELBASE.dll.
Корінь: Пошкодження пам’яті раніше ін‑процесним розширенням; Windows просто повідомляє, де воно вмерло.
Виправлення: Використайте WER‑журнали; перелічіть завантажені модулі; вимкніть підозрілі сторонні розширення; зніміть дамп за потреби.

5) Crashes only in one folder

Симптом: Перехід в конкретну папку тригерить аварію; інші папки нормальні.
Корінь: Один проблемний тип файлів (ескізи/прев’ю), пошкоджений файл, або налаштування перегляду папки, що викликає певний шлях обробника.
Виправлення: Змініть вигляд папки на «Деталі» і вимкніть ескізи; розділіть файли навпіл, щоб знайти проблемний тип/файл; потім усуньте відповідальний обробник.

6) Only one user profile sees the issue

Симптом: Та сама машина, інший користувач заходить — Explorer стабільний.
Корінь: Інтеграції й конфігурація на рівні користувача, пошкоджені налаштування оболонки користувача, пер‑користувацька реєстрація COM або додатки, налаштовані на профіль.
Виправлення: Протестуйте з новим профілем; скиньте налаштування Explorer; видаліть інтеграції на рівні користувача; перевстановіть проблемний застосунок для цього користувача при потребі.

7) Explorer crashes when viewing ZIPs or archives like folders

Симптом: Клацання архівів або правий клік по них викликає аварію.
Корінь: Розширення архіватора конфліктує з вбудованою підтримкою стиснених папок Windows або з іншим архіватором.
Виправлення: Вимкніть shell‑інтеграцію одного архіватора; залиште одного «власника» контекстних меню; оновіть до стабільної версії.

Контрольні списки / покроковий план

Checklist A: One-machine triage (15–45 minutes)

Запишіть тригер (правий клік vs вибір vs відкриття vs конкретна папка).
Зберіть докази: Event ID 1000 (Application Error) + WER 1001 навколо часу аварії.
Тест у Safe Mode: підтвердьте, чи це стороннє.
Вимкніть не‑Microsoft розширення оболонки у ймовірній категорії (обробники контекстного меню першими для аварій при правому кліку).
Перезапускайте Explorer після кожної зміни набору.
Бінарний пошук при повторному ввімкненні для точного виявлення розширення.
Вирішіть ремедіацію: оновити софт постачальника, відкотити версію або видалити інтеграцію.
Перевірте всі тригери: діалоги файлів, правий клік, панель прев’ю, мережеві шари.
Документуйте винуватця: ім’я DLL, батьківський застосунок, версія та дія‑тригер.

Checklist B: Team-wide incident response (1–2 days, but controlled)

Підтвердіть масштаб: який відділ, яка версія ОС, які версії додатків.
Виберіть дві тестові машини: одна «відома добра», одна «відома погана».
Стандартизуйте відтворення: одна й та сама папка, одна дія, один час.
Централізуйте витяги журналів: ім’я та версія faulting module з кількох машин.
Швидко пом’якшіть: вимкніть розширення через корпоративні інструменти або видаліть батьківський застосунок, якщо потрібно.
Стабілізуйте: зупиніть розгортання, заблокуйте оновлення або поширьте фікс.
Запобігайте повторенню: розміщуйте застосунки з інтеграцією оболонки за пілотним кільцем і відстежуйте рівень аварій Explorer через телеметрію.

Checklist C: When you suspect storage/network, not extensions

Перевірте наявність недоступних мапованих дисків (net use).
Перевірте збої резолюції імен (DNS проблеми проявляються як «зависання Explorer»).
Ідентифікуйте фільтруючі драйвери у файловому стеку (fltmc).
Швидко перевірте стан диска (chkdsk /scan).
Якщо зависання відтворюється, трасуйте Procmon і шукайте довгі затримки на мережевих шляхах або у фільтрах безпеки.

FAQ

1) Is it safe to disable shell extensions?

Так, якщо ви вимикаєте сторонні розширення й робите це контрольовано. У найгіршому випадку ви тимчасово втрачаєте пункт у контекстному меню або значок‑накладку до повторного ввімкнення. ОС не впаде.

2) Why does a context menu extension crash the whole Explorer process?

Тому що більшість розширень оболонки — це COM DLL, що виконуються в процесі. Вони працюють у просторі пам’яті Explorer. Якщо вони падають — падає Explorer. Це швидко, коли працює, і боляче, коли ні.

3) Event Viewer says the faulting module is ntdll.dll. Does that mean Windows is broken?

Не обов’язково. ntdll — це місце, куди випливають винятки. Пошкодження пам’яті часто походить від стороннього розширення раніше. Використовуйте WER‑журнали, списки модулів та тести ізоляції.

4) What’s the fastest way to prove it’s an extension?

Safe Mode. Якщо Explorer стабільний там, майже напевно мова про сторонній код (розширення, драйвери або ін’єктовані компоненти).

5) Should I clear the thumbnail cache?

Це варто зробити, коли тригер аварії — «відкриття папки з великою кількістю медіа/CAD/PDF» або «вибір файлів викликає аварію». Але очищення кешу лікує симптом; потрібно все одно розв’язати проблему з ненадійним обробником.

6) Why do crashes only happen in one folder?

Та папка ймовірно містить файли, що запускають певний шлях обробника: ескізи для пропрієтарного формату, парсинг прев’ю або витяг властивостей. Або налаштування перегляду змушує генерувати ескізи/прев’ю.

7) Can antivirus or DLP cause Explorer crashes?

Так. Не часто як «faulting module name: antivirus.dll» (хоча може траплятись), але через фільтруючі драйвери, що підключаються до файлових операцій, плюс опційні shell‑інтеграції для дій сканування. Якщо зависання корелює з доступом до файлів, включіть фільтри до гіпотез.

8) If disabling extensions fixes it, should I uninstall the whole app?

Залежить. Якщо застосунок потрібен (клієнт синхронізації, агент DLP) — зберігайте його і вимикайте лише shell‑інтеграцію, якщо це підтримується. Якщо це опційний інструмент (додатковий архіватор) — видалення часто найчистіше тривале рішення.

9) Why do file open/save dialogs hang too?

Ці діалоги часто використовують ті самі компоненти оболонки і логіку перелічення, що й Explorer. Якщо Explorer зависає на мережевих шляхах або обробниках, діалоги відкриття/збереження теж страждають.

10) How do I prevent this from happening again in an enterprise?

Помістіть застосунки з інтеграцією оболонки за пілотним кільцем, відстежуйте частоту аварій Explorer через телеметрію подій і стандартизуйтесь на меншій кількості «помічників». Також: не дозволяйте трьом клієнтам синхронізації боротися за слоти накладок.

Висновок: практичні наступні кроки

Аварії Explorer.exe не містичні. Зазвичай це поганий гість, який живе в домі Explorer. Ваше завдання — ідентифікувати гостя (faulting module), підтвердити патерн (тригер) і вигнати його (вимкнути розширення), не виселяючи весь квартал (не перевстановлювати Windows).

Зробіть це далі:

Заберіть останні 5 подій аварій Explorer і запишіть faulting module та exception code.
Протестуйте в Safe Mode, щоб довести залучення стороннього коду.
Вимкніть не‑Microsoft розширення в категорії, що відповідає вашому тригеру (контекстне меню vs прев’ю/ескіз).
Перезапустіть Explorer, повторіть тест, потім бінарно звузьте до одного винуватця.
Оновіть/відкотіть/видаліть батьківський продукт і задокументуйте виправлення, щоб наступному адміну не довелося «ремонтувати Windows» три години.

Якщо ви керуєте цим у масштабі, ставтеся до розширень оболонки як до драйверів ядра: привілейовані, небезпечні і варті пілотного кільця. Тому що фактично ними й є. Explorer лише робить їх дружніми на вигляд.