Доступ Windows 7 запрещен к исполняемым файлам .. чем?

С тех пор, как я начал использовать Windows 7, эта проблема беспокоила меня. Время от времени я вижу похожие вопросы, возникающие на разных форумах, но никогда не видел ответа. Вот два сценария, которые почти всегда воспроизводят его:

Проводник

  1. С помощью проводника перейдите в каталог, содержащий хотя бы один файл exe
  2. Немедленно перейдите на один каталог вверх
  3. Удалить каталог, только что перешедший на
  4. Доступ к диалоговому окну « Доступ к папке с доступом». Вам необходимо разрешение для выполнения этого действия. Требуется разрешение от администратора для внесения изменений в эту папку , при этом кнопки « Попробовать снова» и « Отменить»
  5. Hitting Try Again никогда не срабатывает немедленно. Ожидание минуты или около того, а затем его повторное нажатие

Примечание. Если в шаге 2 и в ожидании минуты или более перед тем, как перейти в один каталог, проблема не возникает и папка может быть удалена

Способ Visual Studio

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

Примечание. Если в шаге 2 и в ожидании минуты или больше перед повторным построением, проблема не возникает.

Некоторые спецификации

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

Очевидно, что оба сценария очень похожи и чрезвычайно воспроизводимы. Поэтому я решил, что какой-то процесс должен открыть файл по какой-то причине, и позже выпустить его позже. Однако, используя sysinternals

handle -a 

Файл exe, о котором идет речь, никогда не появляется. (Это правильный способ использования дескриптора, правильно?) Так что, хотя explorer / VS сообщают, что они не могут получить доступ к файлу, handle.exe говорит, что он нигде не используется. Это оставляет меня довольно невежественным, поэтому мне интересно, может ли кто-нибудь придумать решение: почему это происходит и как его решить?

Обновление в ответ на заданные вопросы:

  • Я не смог воспроизвести проблему в безопасном режиме
  • Устанавливается множество расширений оболочки. Из SellExView здесь относятся не-микрософт, которые являются общими для всех машин: NitroPDF, WinRAR, TortoiseGit, TortoiseSvn, NVidia. Я считаю, что черепахи наиболее подозрительны, хотя для параметра «Кэш состояния» установлено значение «Кэш состояния только для одной папки, без рекурсивных наложений», т. Е. Нет TortoiseCache.exe.
  • С проблемой проводника ProcessExplorer не показывает исполняемый файл. Однако он показывает каталог исполняемого файла, но продолжает показывать его даже после того, как он был удален, поэтому кажется, что это не связано
  • С проблемой VS это происходит с VS, даже если в целевом каталоге не открыто окно проводника. И снова ProcessExplorer не показывает исполняемый файл или каталог, в котором находится исполняемый файл. Обратите внимание, что в этом «режиме» с VS проблема возникает только при запуске исполняемого файла. Если он не работает, я могу создать его без проблем раз за разом.
  • В «режиме VS» и в окне проводника открываются в каталоге исполняемого файла (проверены только с помощью C # exe), он становится более странным: я не могу построить снова, потому что VS жалуется, что exe используется другим процессом. Однако, если я удалю exe из окна open explorer, это сработает, и, следовательно, создание будет успешным. Опять же, никаких ссылок в ProcessExplorer нет. Который, кажется, соответствует моим выводам с handle.exe (не PE и дескриптор используют тот же API в любом случае?)

Обновление 2 Это не может быть просто explorer: после убийства explorer.exe проблема VS все еще существует.

Обновление 3 Использование Process Monitor, как предлагает Asher, показывает интересные факты: для режима проводника есть 10 вызовов IRP_MJ_CREATE при открытии каталога. Однако только 9 вызовов IRP_MJ_CLEANUP. Все эти вызовы происходят из shell32.dll, поэтому это определенно не проблема с третьей стороной. И, очевидно, что отсутствует IRP_MJ_CLEANUP, который вызывает проблему: ровно через 1 минуту после открытия каталога сам процесс системы выдает вызов IRP_MJ_CLEANUP, и файл освобождается, и он будет удален.

Однако я все еще не мог понять, почему это происходит. Это ошибка исследователя, вызванная некоторыми изменениями, которые я сделал?

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

Я пробовал это на двух машинах, и все третья сторона весело работала, и все по-прежнему прекрасно.

Я не уверен, что это реальная ошибка (можно сказать, что вы ожидаете с отключением сервисов), но не совсем нормально, что проблема уходит просто, запустив службу, а затем остановив ее снова.


Bounty отправляется к любому, кто может дать более глубокое понимание этого, а также @Asher, чтобы указать мне на ProcMon, который в итоге привел меня в правильном направлении.

Я думаю, что проблема, которую вы видите, связана с файлом thumbs.db, созданным проводником Windows. Попробуйте отключить эту функцию, перезагрузите компьютер и посмотрите, воспроизводится ли проблема.

Чтобы отключить thumbs.db, откройте редактор групповой политики (gpedit.msc), перейдите в «Конфигурация пользователя» – «Панель управления»> «Административные шаблоны» – «Свойства папки»> вкладка «Компоненты Windows» – «Viev»> «Проводник Windows». Найти «Отключить кеширование эскизов в скрытых файлах thumbs.db» и включить itDo Not Cache Thumbnails.

Если это не сработает, я попробую исследовать его с помощью Sysinternals Process Monitor. Используйте его, чтобы посмотреть, кто обращается к папке, когда вы получаете отказ в доступе. Посмотрите, действительно ли это отказ в доступе или нарушение совместного доступа, что означает, что кто-то держит файл.

Вы уверены, что у вас нет каких-либо продуктов безопасности?

Сценарии, которые вы описываете, совместимы с теорией о том, что какой-либо продукт имеет доступ к любому исполняемому файлу, к которому вы обращаетесь любым возможным способом, делая исключительный доступ к нему невозможным. Это не должно быть антивирусом, это может быть, например, индекс для быстрого поиска или что-то еще (даже вирус).

Можно проверить эту теорию, загрузив ее в безопасном режиме, когда вообще не запускаются продукты, кроме Windows.

Лучшим инструментом для отслеживания доступа к файлам является Process Monitor . Еще один отличный инструмент для поиска всех продуктов для запуска и включения их снова и снова – Autoruns .

Файл или каталог можно открыть из режима ядра, затем

 handle -a 

Не покажет его, и ProcMon покажет IRP-запросы из / в Системный процесс.

Есть часть ядра Windows, которая сопоставляется всем процессам, и есть другая часть ядра Windows, которая работает в отдельном процессе. Последний называется Windows Executive.

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

Это могут быть значки для чтения Explorer и метаданные из exe.

Interesting Posts
Давайте будем гением компьютера.