Windows Explored

In addition to local processes locking up files and preventing their usage by other processes, files can also become locked by remote processes, too. Finding the remote system that has a handle(s) on the file can be a little bit more more involved. I mean this literally: a little a bit more involved. Knowing which tools to use or where to look can make this task just as simple as isolating it to a local process as outlined in part I.

This example is a recreation of an issue I encountered while working on a workstation remotely. It manifested itself as a failure to logon as the user: “Windows cannot load the locally stored profile…”

This was followed by “Windows cannot find the local profile and is logging you on with a temporary profile…”

Normally, a reboot will resolve this issue. But that wouldn’t be any fun. Additionally, we run the User Hive Profile Cleanup service (XP workstations)* to mitigate issues where application or service processes remains hooked to user’s registry, NTUSER.DAT and UsrClass.dat, after log off so I was interested to see what was hooked to either of these files.

Process Explorer is the tool choice again and I am searching for the locked file, NTUSER.DAT:

The System process has locked the user’s registry file (this is a recreation so I am the user). Think of the System process in this case as a misnomer for a remote process. Finding who has the handle on it is a simple matter of open the process properties and going to the TCP/IP tab:

The lab workstation I tried to logon as the user (myself) has been connected to by another workstation, in this case my primary workstation. This is likely the offending remote system that has locked up the NTUSER.DAT. This is actually enough to jog my memory; I had loaded the user’s NTUSER.DAT (the offline HKCU) remotely into the registry editor via Load Hive from my workstation to examine it a few hours earlier and failed to unload it before closing regedit:

After unloading it, the connection closed a minute later (In Process Explorer, red denotes a closing connection or process):

Another SysInternals tool you can use is TCPView:

And last (but not least) Windows already has the ability to view remote opened file connections and sessions. Open the computer management console  on the workstation where the file is locked and expand Shared Folders > Open Files and Sessions:

This will show who is accessing. The Sessions will display from what IP:

You can then right-click the open file and/or session to disconnect the remote handle and unlock the file.

You can also use netstat from a command shell to see what remote systems have active connections to the workstation where the file is locked.

Finally, it’s worth mentioning some applications may be hooking files in ways that you cannot determine using the basic methods outlined in Part I or II. These problems are generally more complex to isolate. Here is an example worth reading: The Case of the Temporary Registry Profiles.

*This feature is already part of Windows Vista and 7.