Two issues I have seen recently:
1. A Windows 7 laptop which belonged to a developer and was being passed on to a new user. However, although you could create the new user, you could not log in as that user. The error was “User Profile Service service failed the logon. User profile cannot be loaded.”
I narrowed the problem down to an “Access denied” error when trying to create the profile, but we decided to restore Windows to factory settings (using recovery tools) since that was probably a better approach for the new user anyway – you never know what a developer may have tweaked or installed in Windows!
2. SQL Server 2014 Database Engine installation failing on Windows 8. The reported error: Could not find the Database Engine startup handle.
Annoyingly, you cannot attempt a repair install if you get this, since repair cannot run if there has not been a successful install in the first place. However this error does not rollback the installation, so you have the feature installed but not working. You have to remove the SQL Server feature using control panel, then you can retry. I got this on a couple of machines, tried a few things but failed, so used fresh VMs instead.
Others have run into this and there is a solution, which applies to both problems. They are actually the same, since SQL Server 2014 creates a new profile in the default install.
This solution means resetting the permissions on c:\users\default so that they are replaced with permissions inherited from the parent folder. This solution works; but it is not perfect, since these are the wrong permissions for the folder (too loose). Someone has done the job of finding the correct permissions for Windows 7. Applying all these is arduous though, and things may possibly have changed with updates since. In a production environment it would be better to narrow down the exact permission that is wrong, or to do a system restore.
If you are happy to risk it, navigate to c:\users in Windows Explorer and find the Default folder. This is hidden by default; you can make it visible using the View Options in Explorer; on the View tab choose Show hidden files, folders and drives. Next, right-click the c:\users\Default folder and choose Properties, then the Security tab, then Advanced, then click Change Permissions. Check the box:
Replace all child object permission entries with inheritable permission entries from this object
Click OK – it does not take long – and now new users can log in, and the SQL Server 2014 setup runs OK.
The problem seems to be common so it is likely that either an official update or a commonly-used third-party install is breaking these permissions. I would be glad to know what it is; it would also be good if Microsoft would build into Windows a feature that would restore default permissions for a system folder like this one.
Update: It may be sufficient to delete a single file. See this thread where event logs lead to a sqmdata…sqm file that, when deleted, fixed the issue. Check the Windows Application log for event 1509.