The APPX session is probably still running on the server, and that's what's holding the record.

You need to do one of the following:

- Have a look at the registration usage to see if there is an orphaned session for that user. If you can find it, KILL it from the console.

- Use NTHandle on the server and find the PID that has the file. Then kill it. At the heart of it, NTHandle digs out the PIDs and the open files. You still have to parse through NTHandle, once you have it from www.sysinternals.com

- Ask everyone to log off, stop the WinAppxD and License servers, and kill any remaining APPX sessions on the server. If there are background jobs running, it might be tricky to identify the background jobs from the ghost task.

- Identify the process id's of all currently connected clients (look in the title bar if P/M client, or under the 'About' menu if Java) and kill everything but those. Again, watch out for background jobs, if you use them at your site. Also, you might want to stop the WinAppxD service while you do this to prevent new users from logging on while you try to find the ghost process.

- Download and install the BJutils package. This is Bruce Johnston's APPX utility package, and one of the utilities allows you to see who has what files open and also allows you to kill APPX sessions. This would help you identify which APPX session is holding the record. You can get this from www.cansyswest.com, under Free Stuff. You also need the NT Resource Kit to make these work.

- Reboot the server (simple, but drastic)

In addition, key file corruption can cause locking problems. It is not unlikely that externally killing an APPX process may cause key file corruption.

So you should run a 13)Verify 1)Integrity on any files that may be open when you have a record locking problem, for which you end up either killing processes, or re-IPL'ing with APPX processes still running.

If you're having record locking problems, it might also be prudent to run 13)Verify 1)Integrity on a regular schedule, perhaps monthly.