При каких обстоятельствах системный процесс (PID 4) сохраняет дескриптор открытого файла?

В моем приложении, запущенном на сервере Windows, используется база данных Jet/Access. По некоторым причинам каждые две недели этот файл базы данных блокируется системным процессом (PID 4, кажется, исправлен)

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

Какова общая причина, по которой системный процесс поддерживает дескриптор открытого файла?
Является ли мое приложение причиной этой ситуации блокировки?
Все ли ручки, неявно открытые системным процессом? Я мог представить, что после того, как процесс разбился, дескриптор все еще может быть открытым, и процесс System каким-то образом принимает управление этим дескриптором.
Могу ли я сделать что-то в своем приложении, чтобы предотвратить его?

Ответ 1

Это звучит для меня как проблема на уровне драйвера с негерметичным дескриптором.

Если вы запускаете антивирусный пакет, попробуйте обновить, отключить (временно!) или переключиться на другой бренд.

Ответ 2

Файлы, к которым осуществляется доступ через общий ресурс, будут заблокированы системным процессом (PID 4).

Попробуйте открыть compmgmt.msc → Системные инструменты → Общие папки → Открыть файлы, чтобы увидеть, есть ли там заблокированный файл

См. также форум sysinternals, чтобы воспроизвести это.
Не все приложения блокируют файлы, когда они открываются, однако Excel делает это. Я не знаю, делает ли Access то же самое...

Ответ 3

Вот еще одна возможная причина, которую я нашел:

Есть ошибка в Windows 7 и, вероятно, в Windows Server 2008 (возможно, только для 64-битных версий). Он появляется, когда вы отключите Application Experience и вызываете те же проблемы, что и в вопросе.

Повторное включение этой службы устранило эту проблему для меня.

Немного больше здесь о том, почему это вызывает проблему.

Список других вопросов SO, которые, как представляется, связаны между собой:

Ответ 4

Это может быть затяжная сессия с удаленного компьютера в общую папку. Если это случай, его можно разблокировать из командной строки:

net session /delete

Ответ 5

Установлен ли ваш сервер для периодического резервного копирования файлов?

Если да, то резервная копия работает как система, возможно, запрашивает заблокированный файл при возникновении конфликта?

Ответ 6

Для меня это был "Защитник Windows" (антивирус). Я исключил свои папки сборки Visual Studio из списка проверяемых папок Windows Defender, и проблема исчезла. (Visual Studio не удалось создать файл EXE, PID 4 блокировал его для проверки virii)

Ответ 7

Для меня мне пришлось ударить его кувалдой. Chkdsk/f на диске, где была установлена папка. Следует использовать с осторожностью.

Ответ 8

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