При каких обстоятельствах системный процесс (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

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