A couple of nights ago I had a Paragon HDM backup fail whilst processing the spinning disk in my gaming rig with the message "VSS: Can't read volume data. (Source: Hard Disk Manager)". Research suggested that the disk was probably failing and it was just a matter of time. CrystalDiskInfo reported a 'Current Pending Sector Count' of 1 and further digging revealed that that too might indicate a disk on the verge of failing, at least badly enough to confuse Windows. Sadly with Paragon's backup this leaves you with a catch-22, you need an image of that disk ASAP but it won't take one whilst even a single used sector is damaged.

At this point the Internet provided the usual raft of conflicting advice and experinces, but I decided that since my system would still boot I would simply try a copy-style operation from the half full 1TB Samsung Spinpoint F3 that was showing the problems to a second 1.5TB Seagate drive that I use for onboard backups, with the OS on a 500GB SSD. I ended up using FreeFileSync to perform that mirror operation, topped up by a simple Take Command COPY to ensure that a few files that FreeFileSync wouldn't copy as the Admin user were preserved too. I then set up a Windows CHKDSK /F /R for the next boot, and just in time because not long afterwards Windows 7 locked tighter than the proverbial duck's backside and I had to use the Reset button to restart the box.

The disk check took several hours and found two damaged files, neither of which were important and both of which would be available from the last good backup so I decided that my next step would be to attempt to clone the whole disk to a newly purchased 1TB Seagate Barracuda (the only 1TB HD I could get my hands on at short notice) rather than going down the ddrescue route. Thankfully this all went smoothly, although it too took several hours, using a USB attached drive caddy to avoid disturbing the internals of the box before I'd got my drive clone.

A half of hour of fiddling around inside the innards of the PC, which included giving it a good clean out to remove a fair bit of dust, and the new drive was in situ in place of the dying one. At this point I crossed my fingers and hoped that I was home and dry, and the initial signs looked good with the machine booting to the Windows 7 log on screen with the usual six user icons displayed. Then I hit the snag identified by the title of this article - when I clicked on my ugly mug to log on I was told 'The User Profile Service failed the logon' and no joy (my day-to-day user is not an Administrator account). My immediate suspicion was that the new drive had not been assigned the same drive letter as the old one, and that I was hoist by own petard because when I first set this system up it had a much smaller 120GB SSD as the boot drive and I'd set Windows up so that all of the user profiles were on the spinning disk which was defined as the D partition (I always move the CD/DVD drive to R as early in the process as possible).

I rebooted into safe mode and logged in using the machine's Administrator account (I suspect that the latter was the key, and that I could have done this without the reboot), started Disk Management (by Windows-R and diskmgmt.msc) and immediately discovered that the new disk had not been given a drive letter at all. That was quickly rectified and another reboot took me back to the normal Windows where I was only able to log in as myself by selecting Other User and entering my username manually, which was odd but did at least enable me to get to a desktop. Not there yet though because a couple of strange error messages popped up instead of the usual UAC prompts for Process Explorer and RealTemp, both of which need to run as Administrator. Further experimenting suggested that I couldn't do anything that required Admin rights, and I immediately suspected that this was down to whatever it was that had allowed me to log in the Admin account in Safe Mode.

Back to safe mode, log on as Admin and check the environment variables to discover that the USERPROFILE was pointing at C:\WINDOWS\system32\config\systemprofile rather than the Users structure on the D partition. A bit of head scratching and back to Google to be pointed at the registry branch HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList where sundry bits of information are recorded about each user defined to the machine. A bit of digging made it apparent that the correct ProfileImagePath for the Admin user only existed in a key whose name ended in BAK (the names are all SIDs and of the form S-1-5-21-nnnnnnnnnn-nnnnnnnnnnn-nnnnnnnnnn-nnnn and therefore often disappear out of the left hand pane) whilst the key with the same name minus the .BAK contained far fewer entries than the rest.

At this point I guess I should echo the usual warnings about taking a backup before messing around in the registry, but having done that I renamed the unsuffixed key to .DUFF and removed the .BAK from the one with the correct path, saved and rebooted. Still no user pictures but having logged in via Other User things appeared to be back to normal with UAC prompts for the Run as Admin tasks in the start up and the ability to access regedit et al restored. Back to the web for the user picture issue and the advice seemed to be that incomplete entries in the ProfileList keys were a likely cause of this and thus a quick delete of my .DUFF entry later everything was apparently back to normal.

Fingers crossed that it stays that way and I have this article as a reminder of the process should I ever need to repeat it on that machine (and perhaps a lesson to be learned about finding a way of having a special Admin account with its profile on the C partition just in case).