Tuesday, June 1, 2010

The user profile service failed the login

I was trying to connect to a relatively newly imaged 2008R2 domain controller today and was getting booted each time due to the user profile service failing to create my profile, and a temp profile. I had never logged into this machine in the past, so I was curious as to what the problem was.

The application logs were showing multiple events at that time in this order:

  • Event 6004 Winlogon: The winlogon notification subscriber failed a critical notification event.
  • Event 1509 User profile general: Windows cannot copy file C:\Users\Default\ntuser.dat to location C:\Users\nlinley\ntuser.dat. This error may be caused by network problems or insufficient security rights. DETAIL - Access is denied.
  • Event 1511 User profile service: Windows cannot find the local profile and is logging you on with a temporary profile. Changes you make to this profile will be lost when you log off.
  • Event 1509 User Profile general: Windows cannot copy file C:\Users\Default\ntuser.dat to location C:\Users\TEMP\ntuser.dat. This error may be caused by network problems or insufficient security rights. DETAIL - Access is denied.
  • Event 1500 User Profile General: Windows cannot log you on because your profile cannot be loaded. Check that you are connected to the network, and that your network is functioning correctly. DETAIL - Only part of a ReadProcessMemory or WriteProcessMemory request was completed.
  • Event 6001 Winlogon: The winlogon notification subscriber failed a notification event.
  • Event 6001 Winlogon: The winlogon notification subscriber failed a notification event.
The user profile service log was not showing anything useful, just logoff events.

From here, I was looking at the security log and found a few failure audits from base filtering engine for domain controller to domain controller on standard domain controller ports. Although this was odd, it didn't seem to explain the issue and the ports did not seem to significant for this point of the login.

Checking the access issue and permissions showed normal permissions on c:\users\default folder (Everyone:read, System: full, Administrators:full, Users:read), and on ntuser.dat it was set to inherit. The odd part with this it the ACL was only showing (Admistrators:full, System:full). If it is inheriting, where was everyone and users? I manually added Everyone:read to the ACL and this solved the problem of the loading profile. Going back again to check the permissions shows that the Users group permission has also inherited and is displaying now.

Root cause: unknown

Update Nov 2015
Just for additional reference, other problems can cause profile failures, such as partially deleted profiles. User profiles consist of several components. There are the files and folders in c:\users\username, of which the ntuser.* files are the core of the profile. The user's account will need full control NTFS permissions to the folder (top level folder owner is SYSTEM but files and folders below that are usually owned by the user). In addition to this, there is a list of user profiles in the registry at HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList. This is a listing of SID values, which will also point to the profile folder in the value ProfileImagePath. This key can be access with WMI using win32_userprofile. This WMI namespace also has a delete method, which should be a safe way of clearing up unwanted profiles. This needs to be used with care, as you will want to ignore certain built in profiles. I have also noticed on at least one test case where a machine has 400+ profiles, trying to delete a profile via WMI was not working, and just seemed to hang. Another registry key that needs to be looked at is HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileGUID. This contains a guid to SID mapping for what is in the ProfileList. If you are manually deleting profiles, you need to remove the folder, and both registry keys that relate to the user. Another problem that can come up, is if a user is logged in with a temporary profile, but the profile folder doesn't get cleaned up property. The user account will be the owner of the files and the system may try to use this same temp profile folder on subsequent logons.

4 comments:

  1. I just experienced a similar problem on a Win7 system (Win7 Pro x64); came across your blog entry on a search. I've also been unable to figure out what caused it, but fixed it by just giving Everyone read rights to the entire C:\Users\Default tree, just as you did. I haven't yet decided if I'll bother going back and adding in the Deny entries for the junction point folders.

    ReplyDelete
  2. Just found an article on ServerFault that indicates that the Default profile may be corrupt. Replacing it with a known clean copy is recommended to resolve the issue.

    ReplyDelete
  3. I took some time to investigate an identical issue on a Windows 7 pc.
    Found that certain files in the default folder including ntuser.dat had permissions for only a single user. That was the reason for the error.
    I tried to change ownership throughout the "Detault" folder but it would not apply to all files for some unknown reason (didn't even show an message), although I could do it one file at a time. Since there were too many of them go through, and it seemed to be some kind of corruption, I opted to do a chkdsk. Chkdsk didn’t fix anything.
    For some reason it occurred to me to copy the “default” folder to “default copy”. Guess what? All security privileges were fixed. I continued by deleting the original default folder and renaming the copy to default. It worked like a charm.

    ReplyDelete
    Replies
    1. IP74 is the best answer. Solved my issue.

      Delete