Products

You'll have to bear with me here because this is a long one. A few months ago we ran into a problem after upgrading some of our servers to ColdFusion 8.0.1 CHF3 from CHF1. We had an application that integrates with a web service running on a remote .Net/IIS server that started throwing a "Connection Failure" message for code that worked fine pre-upgrade. It turns out that in CF 8.0.1, CHF 2/3 there was a "bug" that was fixed for cfhttp:

72744 Fix for CFHTTP making disable deflate as true by default in the header when CF sends an HTTP request, since compression is not handled by CFHTTP client.

Problem for us is that this fix actually broke code we had previously running. Here are the test cases:

Here we have a CF 8.0.1 server running CHF 3:

Execute this code, where we tell CF to pass in two headers:

Wireshark shows CF appending deflate;q=0 to the * which we told CF to pass. This is what was added in CHF 2/3.

IIS 6 gets this and decides to return the data compressed as you can see in the Content-Encoding:

This time, take out the accept-encoding header:

When you run this, notice that ColdFusion appends all sorts of stuff for the Accept-Encoding header:

The result coming back to CF is again compressed by IIS 6:

Let's try this now with CF 8.0.1 with no CHF (works the same with CHF 1):

Run the code passing in both headers:

Wireshark shows ColdFusion passing in only the accept-encoding value we specified. For the TE trailer, we pass in deflate;q=0 which is supposed to tell IIS not to return deflated (compressed data):

What you see next is what we expect to see. IIS is returning the correct data uncompressed:

Now go ahead and take out the accept-encoding like we did last time:

Notice how CF just passes along deflate, gzip, x-gzip, etc?

IIS gets this and returns the content deflated, which CFHTTP can't handle and we get our error:

One last time. Now for CF 9:

Run the code passing in both headers:

What we see in wireshark is the same thing we just saw for CF 8.0.1 up to CHF1:

Data comes back uncompressed as we expect:

Remove the accept-encoding header:

Same values passed as for CF 8.0.1:

And we get compressed data back (and the error again), as expected:

So, what this long exercise shows me is two things:

1. ColdFusion 8.0.1 up to CHF 1 and ColdFusion 9.0 have identical functionality. A hotfix that was applied in CF 8.0.1 CHF2/3 is not present in CF 9.0
2. The change that was made in CF 8.0.1 CHF 2/3 (72744) was not properly implemented. We've fixed this in our CF 8.0.1 CHF3 installs by stripping the class files from the CHF JAR that updated CFHTTP and stuff's working again. I can understand Adobe wanting to tell web servers not to compress by default, but setting deflate:q=0 needs to be done in the TE, not in the accept-encoding header. Putting it there causes the data to be returned compressed.

I filed a bug report on this and verified the problem with Adobe (there's a bug number but for some reason it isn't showing up in the bug base). They've stated they'll be releasing a fix for it in CHF4 for CF 8.0.1. Just a reminder that this issue does not affect ColdFusion 9.

Thanks go to my coworker Adam Crump for helping to troubleshoot and diagnose the issue.

Back in November I finally took the plunge and upgraded my home computer to the 64bit version of Windows Vista Ultimate via a clean install. One thing I did immediately after the install was to move the \users directory from c:\users to f:\users. I did this for two reasons. First, the drive Vista was installed on was only 250GB and I could see running out of room pretty quickly given all of the documents, pictures, videos, etc. I had on the system. The second reason for the move is that I wanted to separate my data from the operating system as much as possible to make upgrades and backups easier to manage.

Unfortunately, there's no easy way in Vista to relocate the \users directory. If you know what you're doing you can change the location during install by using an unattended install, but this can be very complicated to do and is something that's beyond most casual users. In the end I settled on moving all of c:\users over to f:\users and using symbolic links to point from c:\users to f:\users. That way programs could continue to reference c:\users but the operating system would be smart enough to know and forward all requests to f:\users. Following the directions here I was able to move the directories and files and create the required symbolic links. Everything worked well until I got back from vacation last week and my wife tried to login to her account to pay some bills and was greeted by the following error: "The User Profile Service service failed the logon. User profile cannot be loaded." This seemed odd because she had successfully logged into her account only a few weeks ago.

Searching the web for answers turned up this site, which nearly everyone else experiencing the problem linked to.

My problem boiled down to this. I could log in to vista using my (Admin) account and create as many new users as I wanted to via the User Management tools in the control panel. In the User Management tool, I could see each and every one of the new accounts. When I booted up the system or choose to Switch Users, all of the newly created accounts showed up on the log in screen. However, any attempt to log in using any of those accounts resulted in the same "The User Profile Service service failed the logon. User profile cannot be loaded" error.

The recommended solution involved making changes to a specific registry entry that had become corrupted and contained a backup entry. After looking through the recommended solutions, it was obvious to me that my problem was a little different from the majority of users posting to the site. In my case, there was no corrupt registry entry and no backup key to work with. In fact, there were no registry entries for any user accounts other than my working Admin account. I also didn't have a system restore point that went back far enough before I was convinced that the problem had started. From what I could tell, the problem started after an automated Windows update had been applied. The recommendation made to me and others on the forums with the same problem was to reinstall Vista, something I wasn't keen on doing.

At this point, it seemed to me that something must be wrong with the initial creation of a user's profile the first time they log on to Vista. When you create a new user account from the User Manager, Vista doesn't actually create the user's directories until their first log in. When a user logs in for the first time, Vista uses the contents of c:\users\default as a template for the directory/file structure for that user. In the case of the "The User Profile Service service failed the logon. User profile cannot be loaded", I was getting the new user directory (and associated registry entry) was never getting created.

A little more digging through the various Windows log files turned up something interesting. In addition to all of the errors stemming from the user not being able to log in successfully was a warning that a particular filename/extension was to long to be copied. Here it turns out that Vista ran into a problem while trying to copy the default profile during the account creation/log in process. Specifically there are two directories preventing the default profile from being created. The first is:

c:\users\default\AppData\Local\Application Data

As you can see in the following screen shot, the root Application Data folder contains a lot of recursively added \Application Data folders. My best guess is that something went wrong during one of the Windows update processes, resulting in all of the extra recursive \Application Data directories. From the research I've done this doesn't appear to be limited to a single specific Windows update as people have reported the problem as far back as 2007.

The second directory you'll need to take a look at is:

C:\users\default\Local Settings\Application Data

Again, if you look in this directory you should find several more levels of \Application Data appended to the top level \Application Data:

In both cases, what you'll need to do is to delete all of the additional occurrences of \Application Data below the root level. Once you've done this any user experiencing the "The User Profile Service service failed the logon. User profile cannot be loaded" error should be able to login.