Windows 7 відмовлено у виконанні файлів .. чим?

З тих пір, як я почав використовувати Windows 7, ця проблема мене турбує. Час від часу я бачу подібні запитання, що спливають на форумах різного характеру, але ніколи не бачив відповіді. Ось два сценарії, які майже завжди відтворюють його:

Дослідницький шлях

1. За допомогою програми Explorer перейдіть до каталогу, що містить принаймні один файл EXE
2. Відразу перейдіть до одного каталогу
3. Видаліть каталог, щойно перейшов до нього
4. Урожайність Folder Access Denied діалогове вікно з зазначенням потрібен дозвіл на виконання цієї дії Вам буде потрібен дозвіл від адміністраторів вносити зміни в цю папку , за допомогою кнопок спробуйте знову і Скасувати
5. Натискання спробувати знову ніколи не працює негайно. Зачекавши хвилину або близько того, а потім знову натиснути її, спрацює

Примітка. Якщо на кроці 2 і чекати хвилину або більше, перш ніж перейти до однієї директорії, проблема не виникає, і папку можна видалити

Шлях Visual Studio

1. Створіть проект, що створює файл EXE
2. запустіть виконуваний файл та закрийте його
3. Негайно побудуйте проект ще раз (наприклад, змінивши одного символу у вихідному файлі)
4. Урожайність фатальну LNK1168 про помилку: Не вдається відкрити /path/to/the.exe для запису

Примітка. Якщо на кроці 2 і чекати хвилину або більше, перш ніж знову будувати, проблема не виникає.

Деякі характеристики

• З VS2008 / 2010/2011 трапляється як у Windows 7 32, так і в 64 бітах
• Трапляється на трьох різних машинах
• У мене немає вірусного сканера
• У мене відключена купа послуг, але нічого, що не заважає нормальній роботі Windows, UAC також відключений
• Відбувається на будь-якому типі диска
• Я завжди використовую обліковий запис користувача, який знаходиться в групі Адміністратори

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

handle -a

відповідний файл EXE ніколи не з’являється. (це правильний спосіб використання ручки, правда?) Тож, як Explorer / VS звітують, вони не можуть отримати доступ до файлу, handle.exe каже, що він ніде не використовується. Це залишає мене досить зрозумілим, тому мені цікаво, чи хтось може придумати рішення: чому це відбувається, і як це вирішити?

Оновіть у відповідь на поставлені запитання:

• Я не міг відтворити проблему в безпечному режимі
• Встановлено купу розширень оболонок. Тут продаються немікрософт, які продаються на всіх машинах: NitroPDF, WinRAR, TortoiseGit, TortoiseSvn, NVidia. Я вважаю, що Tortoise є найбільш підозрілими, хоча для обох параметрів "Кеш статусу" встановлено значення "Кеш статусу лише для однієї папки, без рекурсивних накладок", тобто не працює TortoiseCache.exe.
• З проблемою Explorer, ProcessExplorer не показує виконуваний файл. Він хоча показує каталог виконуваного файлу, але продовжує показувати його навіть після того, як він був видалений, так що, здається, не дуже пов'язаний
• З проблемою VS це відбувається з VS, навіть коли в цільовому каталозі не відкрито вікна провідника. І знову: ProcessExplorer не показує виконуваний файл, а також не каталог, у якому виконується виконуваний файл. Зверніть увагу, що в цьому режимі з VS проблема виникає лише під час запуску виконуваного файлу. Якщо це не працює, я можу без проблем будувати його час від часу.
• У режимі VS та відкритому вікні провідника у каталозі виконуваного файлу (тестується лише на C # exe) воно стає більш дивакуватим: я не можу будувати заново, оскільки VS скаржиться на те, що exe використовується іншим процесом. Однак якщо я видаляю exe з відкритого вікна провідника, це працює, і, отже, створення успішно. Знову ж таки, ніяких посилань у ProcessExplorer взагалі немає. Який, здається, відповідає моїм висновкам з handle.exe (чи не PE, а ручка все одно використовувати той самий API?)

Оновлення 2 Це не може бути просто дослідником: після вбивства Explorerr.exe проблема VS все ще існує.

Оновлення 3 Використання монітора процесів, як пропонує Ашер, виявляє цікаві факти: для режиму провідника 10 дзвінків до IRP_MJ_CREATE після відкриття каталогу. Однак на IRP_MJ_CLEANUP лише 9 дзвінків. Всі ці дзвінки походять з shell32.dll, тому це точно не є проблемою встановлення сторонніх розробників. І, очевидно, той, що відсутній IRP_MJ_CLEANUP, викликає проблему: рівно через 1 хвилину після відкриття каталогу сам системний процес видає IRP_MJ_CLEANUP виклик і файл звільняється, і видаляється.

Однак я все ще не міг зрозуміти, чому це відбувається. Це помилка Explorer, яка викликана деякими змінами, які я внесла?

Рішення! Переглядаючи відключені служби, я помітив опис програми Application Experience , і я цитую: Запити кеш-сумісності додатків на процеси для програм, коли вони запускаються . Звучить знайомо. Дійсно, після запуску послуги я більше не можу відтворити жодних проблем, і вихід ProcMon стає іншим і коротшим. Дуже смішно, адже після припинення послуги знову все в порядку, а кількість випусків програми ще коротша.

Я спробував це на двох машинах, з усіма сторонніми матеріалами із задоволенням працює, і все це добре.

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

Баунті переходить до кожного, хто може глибше зрозуміти це, інакше до @Asher за вказівку мене на ProcMon, який врешті-решт привів мене в правильному напрямку.

Я думаю, що проблема, яку ви бачите, пов'язана з thumbs.db, який створює Провідник Windows. Спробуйте вимкнути це, перезавантажте та перевірте, чи відтворюється проблема.

Щоб відключити thumbs.db, відкрийте редактор групової політики (gpedit.msc), перейдіть до Конфігурація користувача - Панель керування> Параметри адміністративних шаблонів - Параметри папок> Вкладка компонентів Windows-Viev> Провідник Windows. знайдіть "Вимкнення кешування мініатюр у прихованих файлах thumbs.db" та ввімкніть його "Не кешувати ескізи".

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

Ви впевнені, що у вас немає жодного встановленого продукту безпеки?

Описані вами сценарії сумісні з теорією того, що деякий продукт отримує доступ до кожного виконуваного файлу, яким ви можете отримати доступ будь-яким можливим способом, що робить ексклюзивний доступ до нього неможливим. Це не повинно бути антивірусом, це може бути, наприклад, індексатор для швидкого пошуку або будь-якого іншого (навіть вірусу).

Можна перевірити цю теорію, завантажившись у безпечному режимі, коли взагалі не запускаються продукти, крім Windows.

Найкращим інструментом для відстеження доступу до файлів є Process Monitor . Ще один чудовий інструмент для пошуку всіх запуску продуктів та їх вимкнення та повторного використання - Autoruns .

Файл або каталог можна відкрити в режимі ядра

handle -a

не показуватиме його, і ProcMon покаже IRP запити від / до системного процесу.

Є частина ядра Windows, яка відображається у всіх процесах, є ще одна частина ядра Windows, яка працює в окремому процесі. Остання називається Windows Executive.

Таким чином, це викликано файлом або каталогом, відкритим з режиму ядра в процесі Windows Executive.

Це можуть бути піктограми, що читають Провідник, і метадані з EXE.