Today, support for Windows 2000 from Microsoft ends. Windows 2000 was released over ten years ago, on February 17, 2000. Although it may have had a shaky start as far as application compatibility goes, it is renowned as one of the most stable operating systems ever to come out of Microsoft, and it paved the way for Microsoft to merge the “home” (9x) and “business” (NT) lines of Windows with Windows XP, the following year.

Windows 2000 received its last service pack, Service Pack 4, on June 26, 2003. It has been in “extended support” since June 30, 2005, and since then it has only been receiving security updates from Microsoft. Now, all support for Windows 2000 is dropped, and security updates will no longer be issued.

Another Windows release passes on to the pile of Windows versions past. But this was a great one, so I wanted to post a small tribute to it.

If you were wondering, Windows ME was released after Windows 2000, on September 14, 2000. However, Microsoft dumped support for this operating system, the last of the “9x” line, back in 2006. The next operating system, Windows XP, is already in “extended support,” but will continue to receive security updates until April 8, 2014. By this time, Windows Vista will be in extended support (which happens in April, 2012). Only Vista Business and Vista Enterprise will be supported during the “extended support” phase, which will last until 2017, so support for the other editions (including Ultimate!) will end completely, before XP’s support runs out.

Anyway, this error popped up for me in Windows 7 the other day.  After the computer boots up, you click on your user icon, type in your password, and BAM!  “The User Profile Service service failed the logon.  User profile cannot be loaded.”  And then you are logged off, and stuck back at the user select screen.

If you’re having this problem, hopefully you have another account on the computer that you can sign in to.  To fix it…

• Sign into another Windows account.
• Run the registry editor.
• Navigate to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList.
• Look at the sub-keys here in the form of S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX.
• One of them is probably duplicated with the extension “.bak.”  Remove (or backup) the one without the .bak, and then rename the remaining one, removing the .bak extension.
• Log out and try to log in as your troublesome user.  Should be fixed now!

Now, why did this happen in the first place?  I think it has something to do with Windows Backup creating a backup copy of the profile during the backup procedure, and then being interrupted or something and not restoring things to how they used to be.  Maybe there are other scenarios that can cause this problem as well.  In any case, I hope this helps someone!

By the way, while this happened to me on Windows 7, I understand that the error can occur on Windows Vista as well.

Update: April 26, 2010

Some commenters have noted that if you only have one account on your computer, you may still be able to use this trick to fix your problem.  Try booting in safe mode (press F8 at boot).  If you can log in using safe mode, fix the registry as described above, and then reboot into normal mode and you should be all set.

Update: September 1, 2010

If you do not know how to use the registry editor, or you do not know how to start your computer in safe mode, Google up a tutorial for either of these and once you figure them out, you should be able to use this information to solve your problem.  Or, get a more experienced techy friend to look at your computer and point him or her to this article.  Explaining these is beyond the scope of this article and I won’t be posting any more detailed step-by-step in response to comments.

Update: December 1, 2010

Jon Hege reports in the comments that this problem may also be caused by a missing C:\Users\Default folder.  In this case, you may be able to copy the folder over from another machine to correct the issue.

But if you are dealing with stuff on a different machine, perhaps by Windows file sharing, there’s no way to elevate yourself.  So, if you are trying to access a shared folder that only “Administrators” are allowed to access, even if you are a member of the “Administrators” group, you will not be able to access it.

The fix for this is to disable remote UAC processing.  With this disabled, users in the “Administrators” group will be able to do what they have permission to do without elevating, if they are accessing the machine over the network.  To do this, create the following DWORD registry value (if it does not exist already):

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy

Set the value data to 0 to disable remote UAC processing and to 1 to enable it.

The reason I wanted to disable remote UAC processing is so that I can access the contents of local backups created by Windows Backup on Windows 7 remotely.  Windows automatically restricts access to the backup folder it creates to the “Administrators” group.  Even if you change the permissions, they will be reset next time the backup runs.  But I imagine that there are a number of situations where this would be helpful.

For more information, see this MSDN article.

Windows Photo Gallery stores tag information directly in the files you are tagging, when possible. For instance, when tagging JPEG files, the tags are stored in the JPEGs using XMP. Also, if you modify other information about the files (such as the date/time a photo was taken), that information is stored in the file if possible.

In some cases, the information cannot be stored in the file itself; for instance, if the file is marked “read only,” or if the file format does not support metadata (PNG, AVI, etc.). In this case, Windows Photo Gallery still allows you to do anything you could to a file that it could store the information in, only, it stores the information in its own little private database. This is transparent to the user.

If you want to move your “gallery” to a different machine, and your gallery consists only of JPEG images, you can probably just copy them all to the new machine, and Windows Photo Gallery will automatically index them and rebuild its list of tags. However, if you have other types of files in your gallery, the information will not be carried along with these files and you’ll have to re-tag them. Ugh.

I’ve been looking into migrating the Windows Photo Gallery database. There doesn’t seem to be any supported way to do this (someone please correct me if I’m wrong).

The database itself is easy to find — it is the Pictures.pd4 file, found in AppData\Local\Microsoft\Windows Photo Gallery in your Windows profile folder. So, to migrate the database, it should be as simple as moving this file to the new machine, and making sure that the paths to all of the files in your gallery remain the same, right?

Well, after trying this and running Windows Photo Gallery, we come up with a curious dialog box.

Note that the folder it is complaining about is actually present on the machine.

Here, you have some options. If you click on “Find the folder,” and browse for it, you might end up with a duplicate of every file appearing in your gallery (and the folder is listed under “Folders” on the left twice, with no way to remove either of them). If you click on “Remove the folder,” all of the files in your gallery disappear, and your tag information is lost (even if you manually add the folder back). And if you click on “Cancel,” everything works great, all of the files appear and all of the tag information appears to have been migrated succesfully… Except, this dialog reappears every time you run Windows Photo Gallery.

In trying to figure out a way to either migrate the information without causing this dialog to appear, or to figure out why Windows Photo Gallery doesn’t seem to like the Pictures folder even though it has the same path as before, I set up two identical galleries on two separate machines and compared their Pictures.pd4 files. Skipping a lot of the details, I did eventually stumble on the key difference.

Windows Photo Gallery is checking your volume information (volume label and serial number) and storing it in its database; it is then using this to verify that the files are on the same drive that they were before. If you move the database to a different machine, the volume serial number is not the same, so it throws up the error we saw above. You can’t just edit the volume serial number in the Pictures.pd4 file to match the new one, though, Windows Photo Gallery is able to detect that the file has been tampered with (you’d have to go fix some other checksum stuff to get that to work). The easiest thing to do is just to change the volume serial number on your “destination” machine to match the one of the “source” machine. You can do that with this SysInternals utility, VolumeID.

So, migrating your Windows Photo Gallery database, step-by-step:

• Copy all of the files in your gallery to the new machine. Make sure the path to them remains the same as it was on the old machine.
• Copy the Pictures.pd4 file to the new machine.
• Change the volume ID of the C: drive (and any other drives with folders indexed by Windows Photo Gallery) on the new machine to be the same as on the old machine, using VolumeID. (Reboot for the changes to be visible, before running Windows Photo Gallery.)

Note that Windows Live Photo Gallery can be migrated similarly.

• You have 4 GB of RAM (or rather, more than 3 GB).
• You are trying to install the 64-bit version of Windows Vista.
• After the first reboot, when your computer boots off of the hard disk for the first time, Windows crashes with a BSOD with error code 0x0000007E.
• Whatever hardware swapping you do doesn’t seem to help; it still gives you the blue screen at every boot.

A friend ran into this issue earlier today. After some searching and digging through a lot of not very useful information, we found out that the solution is pretty simple.

• Remove 2 GB of RAM, or whatever it takes to only have 2 GB in the machine.
• Run the Vista install.
• Install the x64 version of the KB929777 hotfix from Microsoft.
• Put your RAM back in.

Note that this particular issue should not occur if you are using a Windows Vista SP1 (or newer) install disc, it is only an issue with the RTM version.

Hope this helps someone.

Since I’m an administrative user (and there’s only one account on my machine), there seemed to be nothing else wrong after the notification went away. The System Event Notification Service is running, even. Still, errors like this are somewhat disturbing.

Anyway, I Googled around a little and found little useful information; however, I believe I have fixed it on my machine.

If you are having this problem (errors but the service seems to be working fine), here’s what to try:

Go to regedit, and navigate to: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SENS.
Change the value of “Start” from 0×00000002 to 0×00000001. This is a trick I’ve used on services before, it pretty much makes this service start earlier, before other services that are set to start “Automatically.” This is to help make sure that the service is up and running before something else tries to connect to it and decides that its not working, and throws up this error.

Since then, I haven’t had this notification pop up; however, it’s difficult to test since it happens sporadically. I’ll update this post if I learn anything else.

Actually, the whole network connection seems to be dead. However, it’s obviously not an Internet outage, because existing connections remain open (i.e., I was still able to chat on AIM). Also, pinging and DNS lookups work, but opening up new TCP connections seems to be impossible. At first, there seems to be no way to fix it except to reboot the machine, but after reading for a while, I see that restarting the Internet Connection Sharing service will also fix it. (So will just disabling ICS.)

I did a bit of searching and found several posts on various forums where people were posting about the same problem. It seems to be a pretty glaring bug in Vista ICS. I didn’t encounter it until now because I only turned on ICS a couple of days ago. I’m not sure why the real solution is not very easy to find, but after digging through all of these forums, this particular thread lead me to the answer. Here it is (Microsoft KB article). At least, I hope that’s it, I haven’t encountered the network anomaly since I installed that hotfix.

Note that this is one of those hotfixes that you must request the update from Microsoft, it is not publicly available. Because of the frustrating nature of this bug, I am going to post links that I found earlier to download the hotfix. These may not work, they are only valid as of the time of this writing. Here’s one for the 32-bit version and one for the 64-bit version. You can also use this form to request the hotfix directly.

I hope this helps someone!

(Note: Since a hotfix is already available, I expect that this issue will be resolved in Vista SP1.)