Windows 2008 R2 - Le noyau (System Process PID = 4) verrouille les fichiers et les dossiers

Question

Windows 2008 R2 - Le noyau (System Process PID = 4) verrouille les fichiers et les dossiers pendant une longue période. Par exemple lors de la suppression d'un fichier, le fichier peut rester verrouillé pendant 1 minute ou plus et seulement après cela sera supprimé. À d'autres occasions, j'ai rencontré des fichiers ou des dossiers que je ne pouvais pas supprimer. ProcMon a montré que le Processus Système tenait une poignée à ces ressources pendant quelques minutes et les a ensuite libérées Aucune des ressources que j'ai mentionnées n'étaient des ressources système, seuls les fichiers et les dossiers installés étaient gérés par mes applications.

Answer 1

Comme Dani a déjà mentionné dans le commentaire:

Il y a un bogue dans Windows 7 et probablement dans Windows Server 2008 (versions 64 bits peut-être seulement). Il apparaît lorsque vous désactivez le service Application Experience.

Ré-activer ce service a résolu ce problème pour moi.

Un peu plus d'information here pour expliquer pourquoi cela cause un problème.

Liste des autres SO questions semblent être liées:

• Visual Studio output file permissions?
• Under which circumstances does the System process (PID 4) retain an open file handle?

Answer 2

fichiers accessibles par une action sera bloquée par le processus du système (PID 4).

ouverture Try compmgmt.msc ->Outils système ->Dossiers partagés ->fichiers ouverts pour voir si le fichier verrouillé est apparaître dans la liste

Voir aussi the sysinternals forum un moyen de reproduire ce.
Toutes les applications ne verrouillent les fichiers lorsqu'ils sont ouverts, Excel fait cependant ...

Answer 3

Essayé tous ces ...

copie Même le fichier, la suppression de l'original, renommer copie nom original (tout sur le serveur) me dirait immédiatement que l'utilisateur l'avait verrouillé.

En fin de compte -

Unlocker utilisé pour effacer les verrous de fichier. Copie le fichier OFF THE SERVER sur un bureau. Suppression du fichier d'origine du serveur. Changé le nom de fichier de la copie sur le bureau. Renommez le nom d'origine sur le bureau. Remettez le fichier à l'emplacement d'origine SUR LE SERVEUR.

HTH, YMMV ... :)

Answer 4

eu ce problème tout à l'heure tout en essayant de répliquer les données vers un nouveau serveur de fichiers (les deux sources & serveurs de destination exécutant Windows 2008 R2).

PID 4 a été trouvé en verrouillant le fichier (en utilisant procexp comme ci-dessus), mais Application Experience n'a jamais été installé sur le serveur & le fichier n'a pas été affiché dans la liste des fichiers ouverts.Heureusement, nous utilisons des clichés instantanés planifiés sur ce serveur (pour permettre aux utilisateurs de servir eux-mêmes la plupart des restaurations de fichiers). Je viens d'utiliser l'option Versions précédentes (disponible via Propriétés du dossier contenant), sélectionné la copie la plus récente du fichier & l'a copié ailleurs, puis supprimé et remplacé le fichier problème.

Vous devrez peut-être supprimer le dossier contenant pour supprimer le fichier - ce qui pourrait poser problème si beaucoup de fichiers sont utilisés (ce n'était pas un problème pour moi étant donné que c'était le seul fichier du dossier).

Pour un problème unique comme celui que j'avais (un seul fichier verrouillé pour l'ensemble du serveur), cela a fonctionné sans perturber le serveur ou les utilisateurs. Étant donné que vous parlez d'un serveur & que les clichés instantanés utilisent VSS - vous devriez être en mesure de récupérer le fichier verrouillé à partir de vos sauvegardes (vous les avez probablement) si vous n'utilisez pas de clichés instantanés. Sinon, il existe des utilitaires utiles comme ShadowSpawn (https://github.com/candera/shadowspawn) qui pourraient aider.

Answer 5

Dans mon cas, il a été fixé par une simple commande dans la ligne de commande:

net session /delete 

J'espère que cela aide.

Answer 6

J'ai rencontré ce problème lors de la tentative de renommer un dossier. J'ai dû arrêter le service du serveur tout en effectuant le renommer. Le redémarrage n'a pas aidé, car le processus système a reverrouillé le dossier dès que le service du serveur a redémarré.