Windows 2008 R2 - Kernel (System Process PID = 4) está bloqueando archivos y carpetas

Question

Windows 2008 R2 - Kernel (System Process PID = 4) está bloqueando archivos y carpetas durante mucho tiempo. Por ejemplo, al eliminar un archivo, el archivo puede permanecer bloqueado durante 1 minuto o más y solo después de que se elimine. En otras ocasiones encontré archivos o carpetas que no pude eliminar. ProcMon mostró que el proceso del sistema estaba controlando esos recursos durante un par de minutos y luego los liberó Ninguno de los recursos que mencioné fueron recursos del sistema, solo los archivos y las carpetas instaladas fueron manejadas por mis aplicaciones.

Answer 1

Como Dani ya se ha mencionado en el comentario:

Se trata de un error en Windows 7 y es probable que en Windows Server 2008 (posiblemente versiones de 64 bits solamente). Sale a la superficie cuando deshabilita el servicio Application Experience.

Al volver a habilitar este servicio me ha solucionado este problema.

Un poco más información here de por qué está causando un problema.

Lista de otros SO preguntas que parecen estar relacionados con:

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

Answer 2

archivos accedidos a través de una acción será bloqueado por el proceso del sistema (PID 4).

apertura Try compmgmt.msc -> Herramientas del sistema ->carpetas compartidas -> Abrir archivos para ver si el archivo bloqueado está en la lista

Véase también the sysinternals forum una manera de replicar este.
No todas las aplicaciones se bloquean los archivos cuando son abiertos, sin embargo Excel hace ...

Answer 3

intentado todos estos ...

Incluso copiar el archivo, borrar el original, el cambio de nombre copia al nombre original (todo en el servidor) de inmediato me diría que el usuario lo tenía bloqueado.

En el fondo -

usada Unlocker para borrar los bloqueos de archivo. Copió el archivo DESACTIVADO DEL SERVIDOR a un escritorio. Se eliminó el archivo original del servidor. Se cambió el nombre de archivo de la copia en el escritorio. Lo renombré de nuevo al nombre original en el escritorio. Vuelva a colocar el archivo en la ubicación original EN EL SERVIDOR.

HTH, tu caso es distinto ... :)

Answer 4

Si este tema hace un momento al mismo tiempo tratando de replicar los datos a un nuevo servidor de archivos (tanto de origen & servidores de destino que ejecutan Windows 2008 R2).

Se encontró PID 4 bloqueando el archivo (usando procexp como se indicó anteriormente), pero la experiencia de aplicación nunca se ha instalado en ninguno de los servidores & el archivo no se muestra en la lista de archivos abiertos.

Afortunadamente utilizamos shadow copies programadas en este servidor (para permitir a los usuarios autoevaluar la mayoría de las recuperaciones de archivos). Acabo de utilizar la opción Versiones anteriores (disponible a través de Propiedades de la carpeta que contiene), seleccioné la copia más reciente del archivo & y la copié en otro sitio, luego eliminé y reemplacé el archivo problemático.

Es posible que deba eliminar la carpeta que contiene para eliminar el archivo, lo que podría ser un problema si se usan muchos archivos (esto no fue un problema para mí ya que era el único archivo en la carpeta).

Por un problema único como el que tuve (archivo único bloqueado para todo el disco del servidor), funcionó sin interrupciones para el servidor o los usuarios.

Dado que está hablando de un servidor & que Shadow Copies usa VSS, debería poder recuperar el archivo bloqueado de sus copias de seguridad (presumiblemente las tiene) si no usa Shadow Copies. De lo contrario, hay algunas utilidades útiles como ShadowSpawn (https://github.com/candera/shadowspawn) que podrían ayudar.

Answer 5

En mi caso, fue fijado por un simple comando en la línea de comandos:

net session /delete 

Espero que ayude.

Answer 6

Tuve este problema al intentar cambiar el nombre de una carpeta. Tuve que detener el servicio del servidor mientras realizaba el cambio de nombre. El solo reinicio no ayudó, ya que el proceso del sistema volvió a bloquear la carpeta tan pronto como se reinició el servicio del servidor.