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.