I've ran into an issue where some servers will not release the handle on the ntuser.dat file even after a reboot. Or quite possible, after the reboot, the ntuser.dat file is getting re-loaded into memory. The user accounts are definitely not being accessed (some of them belong to users that have not been with the company in over a year). It seems to be on Windows 2003 servers, but I can't be 100% certain that there aren't some 2000 servers showing this issue as well.

When I try to use process explorer or handle.exe from sysinternals to kill the handle on these ntuser.dat files, the handle remains open and connected. Handle.exe even reports that the handle was broken while it remains in use. I've even taken ownership on the file and tried to kill the handle to no effect (windows shows I have ownership of the file, but still refuses to release the handle).

I have looked into the registry to see if I can discover where the files may be getting loaded at. Unfortunately, the username is appearing in too many places for me to be certain which one is actually loading their reg file into memory.

Any suggestions on how I can either break the handle on the files, or prevent them from getting re-loaded after a reboot?

UPDATE: Per suggestions, I've checked to see if there are any processes running under those user accounts and haven't found any. I did try deleting the user profiles through System Management and the delete option on the profile list is grayed out.

  • I'm pretty sure this is a known issue, have you tried support.microsoft.com yet? – tony roth Jun 8 '10 at 18:17
  • Surprisingly, I did not think to check there (assumed if it was known the result would have come up through a google/bing search). – Matrix Mole Jun 8 '10 at 19:04

you can use PendMove/MoveFile from http://www.sysinternals.com/ to rename/move/delete files BEFOR system boot. it is powerfull but danger!

  • This allowed me to schedule deletion of the files at the next production available reboot window. Glad to know that sysinternals has tools that help with this process. – Matrix Mole Jun 30 '11 at 2:47

Have you checked there are no process running as those users, either started at boot time by Scheduled Tasks or running as services? That would lock the user profiles.

If this is not the case, then there's some strange problem on your system, and you should investigate it more thoroughly; anyway, you can try one of these to delete the locked profiles:

  • Delete them from System Properties -> Advanced -> User Profiles.
  • Reboot the system in safe mode and delete them, manually or via the path above.
  • I'm pretty sure safe mode was ms's answer to the problem! – tony roth Jun 8 '10 at 18:30
  • Unfortunately, there's nothing running as those users. I'll update question with more info relating to your suggestions. – Matrix Mole Jun 8 '10 at 18:48
  • Then you should definitely try safe mode. – Massimo Jun 8 '10 at 19:04
  • if I remember correctly it was av software that was causing the problem! – tony roth Jun 8 '10 at 19:15
  • Since at least Windows XP (which in large parts shares a code base with 2003 Server) there is a service (User Profile Service) whose purpose it is to unload profiles of users who have logged out of a system. Additionally one can always (even remotely) inspect the keys underneath HKEY_USERS to find out which users are logged on (this is - or at least was - the method psloggedon uses/used). The SIDs (in string form) there can be resolved to user names ... – 0xC0000022L Dec 9 '19 at 10:12

Have you tried renaming the file or folder? Frequently a rename will succeede where a delete will fail. After the next reboot anything that was trying to use the file will not be able to find it and you will be able to delete the file.

  • 1
    Tried renaming folders, and get access denied. I'm guessing the access denied error is because of the file in use inside the folder. – Matrix Mole Jun 8 '10 at 18:56
  • @MatrixMole that's exactly the point Zoredache was making: renames will oftentimes succeed where a file is in use. I think this could have been better phrased, though. – 0xC0000022L Dec 9 '19 at 10:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.