С тех пор, как я начал использовать 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, что в итоге привело меня в правильном направлении.
источник
Ответы:
Я думаю, что проблема, которую вы видите, связана с thumbs.db, который создает проводник Windows. Попробуйте отключить это, перезагрузиться и посмотреть, воспроизводится ли проблема.
Чтобы отключить thumbs.db, откройте редактор групповой политики (gpedit.msc), перейдите в Конфигурация пользователя - Панель управления> Административные шаблоны - Параметры папки> Компоненты Windows - вкладка Viev> Проводник Windows. найдите «Отключить кэширование миниатюр в скрытых файлах thumbs.db» и включите его «Не кэшировать миниатюры».
Если это не сработает, я попробую исследовать его с помощью Sysinternals Process Monitor. используйте его, чтобы посмотреть, кто обращается к папке, когда вам отказано в доступе. посмотрите, является ли это отказом в доступе или нарушением совместного доступа, что означает, что кто-то держит файл.
источник
%userprofile%\AppData\Local\Microsoft\Windows\Explorer\thumbcache_*.db), за исключением случаев, когда ресурс является удаленным (как в общем сетевом ресурсе), и в этот момент он будет использовать данные,thumbs.dbхранящиеся в удаленном расположении (это может быть отключено GP).Вы уверены, что у вас не установлен какой-либо продукт безопасности?
Описанные вами сценарии совместимы с теорией, согласно которой какой-либо продукт получает доступ к каждому исполняемому файлу, к которому вы обращаетесь любым возможным способом, что делает исключительный доступ к нему невозможным. Это не обязательно должен быть антивирус, это может быть, например, индексатор для быстрого поиска или что-то еще (даже вирус).
Можно проверить эту теорию, загрузившись в безопасном режиме, где вообще не запускаются никакие продукты, кроме Windows.
Лучший инструмент для отслеживания доступа к файлам - Process Monitor . Еще один отличный инструмент для поиска всех продуктов запуска и выключая их и снова Autoruns .
источник
Файл или каталог можно открыть из режима ядра, затем
не будет отображаться, и ProcMon будет показывать запросы IRP от / к процессу системы.
Есть часть ядра Windows, которая отображается на все процессы, и есть другая часть ядра Windows, которая работает в отдельном процессе. Последний называется Windows Executive.
Это вызвано тем, что файл или каталог открыты из режима ядра в процессе Windows Executive.
источник
Это может быть Explorer, читающий значки и метаданные из exe.
источник