システムプロセス（PID 4）はどのような状況で開いているファイルハンドルを保持しますか？
Windowsサーバーで実行されている私のアプリケーションは、Jet/Accessデータベースを利用しています。いくつかの理由で、そのデータベースファイルはシステムプロセスによってロックされます（PID 4は修正されているようです）
いくつかのグーグルの後、私は他の何人かのユーザーがその特別なプロセスによってファイルをロックしているのを見つけましたが、（もちろん）異なるファイルです。
- システムプロセスが開いているファイルハンドルを保持する一般的な理由は何ですか？
- 私のアプリケーションがこのロック状態の原因ですか？
- すべてのハンドルは、システムプロセスによって暗黙的に開かれていますか？プロセスがクラッシュした後もハンドルが開いたままであり、システムプロセスが何らかの形でそのハンドルの所有権を取得している可能性があることを想像できます。
- アプリケーションで何かを実行して、それが発生しないようにすることはできますか？
これは、ハンドルの漏れに関するドライバーレベルの問題のように聞こえます。
ウイルス対策パッケージを実行している場合は、アップグレード、無効化（一時的に！）、または別のブランドへの切り替えを試してください。
共有を介してアクセスされるファイルは、システムプロセス（PID 4）によってロックされます。
compmgmt.msc->システムツール->共有フォルダを開いてみてください）->ファイルを開くロックされたファイルがそこにリストされているかどうかを確認する
これを複製する方法については、 sysinternalsフォーラム も参照してください。
すべてのアプリケーションが開いたときにファイルをロックするわけではありませんが、Excelはロックします。 Accessが同じことをするかどうかはわかりません...
私が見つけた別の考えられる原因は次のとおりです。
Windows 7にはバグがあり、Windows Server 2008（おそらく64ビットバージョンのみ）にバグがある可能性があります。 Application Experience サービスを無効にすると表示され、質問で説明したのと同じ問題が発生します。
このサービスを再度有効にすると、この問題が修正されました。
もう少し情報 ここ それが問題を引き起こしている理由について。
関連していると思われる他のSO質問のリスト：
リモートコンピュータから共有フォルダへの長引くセッションである可能性があります。その場合は、コマンドラインからロックを解除できます。
net session /delete
私にとっては、ハンマーで叩かなければなりませんでした。フォルダが配置されていたドライブのChkdsk/fで修正されました。注意して使用してください。
私にとっては、「Windows Defender」（アンチウイルス）でした。 VisualStudioビルドフォルダーをWindowsDefenderがチェックするフォルダーのリストから除外したところ、問題は解決しました。 （Visual StudioはEXEファイルをビルドできませんでした、PID 4はviriiをチェックするためにそれをロックしていました）
サーバーは定期的なファイルバックアップを実行するように設定されていますか？
もしそうなら、バックアップはシステムとして実行されていますか、おそらく競合が発生したときにロックされたファイルを促しますか？
各フォルダとサブフォルダのセキュリティ設定を確認してください。システムが、誰もがファイルを削除できないようにする特別なアクセス許可設定を自動的に作成しただけではないことを確認してください。どうやら奇妙な理由で、OSはファイルが削除されないように保護する奇妙な特別なアクセス許可設定を作成します。