С тех пор, как я начал использовать Windows 7, эта проблема беспокоила меня. Время от времени я вижу похожие вопросы, появляющиеся на разных форумах, но никогда не вижу ответа. Вот два сценария, которые почти всегда воспроизводят его:
Путь исследователя
- С помощью проводника перейдите в каталог, содержащий хотя бы один исполняемый файл
- Перейти сразу на один каталог вверх
- Удалить каталог, на который только что перешли
- Урожайность Folder Access Denied диалоговое окно с указанием требуется разрешение на выполнение этого действия Вам потребуется разрешение от администраторов вносить изменения в эту папку, с помощью кнопок попробуйте снова и Отмена
- Удар Попытка никогда не работает немедленно. Подождите минуту или около того, а затем нажмите ее снова работает
Примечание. Если на шаге 2 и подождать минуту или более, прежде чем перейти на один каталог, проблема не возникает, и папку можно удалить.
Visual Studio способ
- Создайте проект, создающий исполняемый файл
- запустите исполняемый файл и закройте его
- Немедленно соберите проект снова (например, изменив один символ в исходном файле)
- Дает фатальную ошибку LNK1168: не могу открыть /path/to/the.exe для записи
Примечание. Если на шаге 2 подождать минуту или более перед повторной сборкой, проблема не возникает.
Некоторые характеристики
- Происходит как в Windows 7 32 и 64 бит, с VS2008/2010/2011
- Бывает на 3 разных машинах
- У меня нет какого-либо вируса
- У меня действительно отключено несколько служб, но ничего, что мешает Windows нормально работать, UAC также отключен
- Бывает на любом типе диска
- Я всегда использую учетную запись пользователя, которая находится в группе администраторов
Очевидно, что оба сценария очень похожи и чрезвычайно воспроизводимы. Поэтому я решил, что какой-то процесс должен по какой-то причине открыть файл, а потом снова его выпустить. Тем не менее, используя sysinternals
handle -a
рассматриваемый exe-файл никогда не обнаруживается. (это правильный способ использовать дескриптор, верно?) Поэтому, пока explorer/VS сообщают, что не могут получить доступ к файлу, handle.exe говорит, что он нигде не используется. Это оставляет меня довольно невежественным, поэтому мне интересно, может ли кто-нибудь придумать решение: почему это происходит и как его решить?
Обновление в ответ на заданные вопросы:
- Я не смог воспроизвести проблему в безопасном режиме
- Куча расширений оболочки установлены. С SellExView, вот не-Microsoft, которые являются общими для всех машин: NitroPDF, WinRAR, TortoiseGit, TortoiseSvn, NVidia. Я бы посчитал, что Tortoise наиболее подозрительны, хотя для параметра «Кэш состояния» установлено значение «Кэш состояния только для одной папки, без рекурсивных наложений», т.е. TortoiseCache.exe не запущен.
- С проблемой проводника ProcessExplorer не показывает исполняемый файл. Тем не менее, он показывает каталог исполняемого файла, но продолжает показывать его даже после того, как он был удален, так что кажется, что он на самом деле не связан
- С проблемой VS это происходит с VS, даже когда в целевом каталоге не открыто окно обозревателя. И снова, ProcessExplorer не показывает ни исполняемый файл, ни каталог, в котором находится исполняемый файл. Обратите внимание, что в этом «режиме» с VS проблема возникает только при запуске исполняемого файла. Если он не запущен, я могу построить его без проблем раз за разом.
- В «режиме VS» и в окне обозревателя, открытом в каталоге исполняемого файла (проверено только на C # exe), он становится более странным: я не могу собрать заново, потому что VS жалуется, что exe используется другим процессом. Однако, если я удаляю exe из открытого окна проводника, это работает, и, следовательно, сборка завершается успешно. Опять же, никаких ссылок в ProcessExplorer вообще. Что, кажется, совпадает с моими выводами с handle.exe (разве PE и handle в любом случае не используют один и тот же API?)
Обновление 2 Это не может быть просто explorer: после убийства explorer.exe проблема VS все еще существует.
Обновление 3 Использование Process Monitor, как предлагает Ашер, раскрывает интересные факты: для режима проводника существует 10 обращений к IRP_MJ_CREATE при открытии каталога. Однако только 9 звонков на IRP_MJ_CLEANUP. Все эти вызовы происходят из shell32.dll, так что это определенно не проблема сторонней установки. И, очевидно, именно эта пропущенная IRP_MJ_CLEANUP вызывает проблему: ровно через 1 минуту после открытия каталога сам системный процесс выдает вызов IRP_MJ_CLEANUP, и файл освобождается и удаляется.
Тем не менее, я до сих пор не могу понять, почему это происходит. Это ошибка проводника, вызванная некоторыми изменениями, которые я сделал?
Решение! Просматривая сервисы, которые я отключил, я заметил, что описание Application Experience говорит, и я цитирую, Обрабатывает запросы кеша совместимости приложений для приложений по мере их запуска. Звучит знакомо. И действительно, после запуска сервиса я больше не могу воспроизвести ни одной из проблем, и вывод ProcMon отличается и становится короче. Забавно, потому что после повторной остановки службы все по-прежнему в порядке, а вывод procmon все еще короче.
Я попробовал это на двух машинах, со всеми материалами сторонних производителей, работающими успешно, и все еще в порядке.
Я не уверен, что это реальная ошибка (можно сказать «что вы ожидаете с отключением сервисов»), но не совсем нормально, что проблема исчезает, просто запустив сервис, а затем остановив его снова.
Баунти обращается ко всем, кто может дать более глубокое понимание этого, к @Asher, который указал мне на ProcMon, что в конечном итоге привело меня в правильном направлении.