Windows Explored

From time to time we have often received complaints about this particular issue. I never really got a chance to troubleshoot beyond the standard “Clear IE cache” rhetoric¹ that somehow is the magical non-solution to all IE woes. Well, alas, I finally encountered the issue on the lab PC and spent some time poking around. Here is what the problem looks like:

As you can see, the left hand menus are not properly positioned in the menu column and are almost invisible. The issue can be workstation specific, user specific or a combination of both. You will see why later. To start troubleshooting, I enabled the option to show all script errors in IE from the Advanced tab. Upon refreshing the page, I saw the expected !error indicator in the IE status bar:

Double-clicking it pulls up the dialog that reveals the error details:
 
OK, this really means nothing to me. I am not a web developer, but it’s not enough to put an end to the investigation. Since I am running IE 8, maybe I can find a critical clue by opening the IE Developer Tools on the site. To do that, hit F12 or go to Tools > Developer Tools. I know enough that I need to look at the Script tab. I am not going to debug the the problem with the page but I want to at least load the script that this page is running so I click Start Debugging. The error we encounter earlier is presented in the context of the problem java script as expected:

This alone is not going to help me. I need to visit the LawDrill site from a workstation where it is working and run the developer tools and compare. This turns out to be the key; there are two different scripts being run respectively on problem workstation and the working one:

The problem workstation is being delivered ig.weblistbarIE4.js (IE4 and lower?). The working example is being delivered ig.weblistbar.js. This is important because this is telling me that the script being delivered depends on something the browser is communicating to the webserver for this page.

When you visit a web page, your browser sends information like the browser type, version, and system information in the form of a header to the webserver that hosts the content. Based on the information it receives, the webserver may deliver content to your browser for which it is specifically designed. For Internet Explorer, the information sent to the webserver is stored as several strings in various locations within the Windows registry and then sent as one combined string or header to the webserver. This information in the registry is known as the User Agent. Basically, it is there to tell the webserver about the browsers’ extensibility support. You can read about this in an earlier post, The Case of the Web page Redirects, which demonstrates how a rather innocent string can cause the wrong web page to be delivered when visiting a certain website.

To resolve the issue with the missing menu, I figured I just needed to isolate the string in UA and then delete it. As I mentioned, these strings are in several locations:

• HKLM\Software\Microsoft\Windows\Current Versions\Internet Settings\5.0\User Agent\Post Platform
• HKCU\Software\Microsoft\Windows\Current Versions\Internet Settings\5.0\User Agent\Post Platform
• HKLM\Software\Microsoft\Windows\Current Versions\Internet Settings\User Agent\Post Platform
• HKCU\Software\Microsoft\Windows\Current Versions\Internet Settings\User Agent\Post Platform

This is an example of the first path above on the problem workstation:

As with the earlier post, I followed the same logic and deleted the first string I encountered². Surprisingly, this worked and the page rendered the menus normally:

However, looking on another workstation without the problem revealed the presence of the same string. Stumped, I referred to MSDN’s Understanding User-Agent Strings, did some more reading, and came across this little tidbit of information:

Earlier versions of Internet Explorer included feature tokens defined using the Pre-Platform and Post-Platform keys part of the user-agent string during the HTTP negotiation process. Over time, this lead to overly long user-agent strings which in turn created problems for certain web servers. Problems usually appeared when user-agent strings were longer than 256 characters.

To see if this was the case, I combined all the user agent strings on the problem workstation. You can also quickly query all these strings by typing javascript:alert(navigator.userAgent) into the IE address bar. The result was:

I put this into Word and did a word count:
 
The combined string size is 259 characters (yes, spaces are counted); Knowing this, I deleted 3 characters from a random string and the web page loaded with the menus intact. I don’t know the how the logic works on the webserver, but the presence of an User Agent header in IE of more than 256 characters is telling it to deliver an IE4 script to our latter version of the IE browser.

Earlier I mentioned that this issue could be workstation specific, user specific, or both. Although I have yet to encounter UA keys with strings in HKCU³, I suppose it is not out of the question. If this were the case, a string in the UA of HKCU would roam with the user from workstation to workstation. If it were large enough, it could cause the UA to exceed 256 characters and reproduce the issue each time. On the flip side, you might logon to the same workstations to test and fail to reproduce because your roaming profile would have no UA string.

You can find an excellent blog that further discusses the uses and misuses of the UA at the IE Internals web site: http://blogs.msdn.com/b/ieinternals/archive/2009/10/08/extending-the-user-agent-string-problems-and-alternatives.aspx.

¹ I have said it a million times, in our environment we enforce cache cleaning when the browser exits. User’s have likely done this several times throughout the day so manually running it almost always never resolves anything.

² You might want to be somewhat cautious as to which UA string you delete or edit. Some sites use the UA to see what kind of extensibility is offered by your browser. In this case, removing the  AmiciLLCVersion2.5 string seems harmless. Otherwise, if you are unsure, you should be able to remove minor versions of the .NET strings, e.g. there are 3 minor versions of .NET 3.0 so delete the two earlier minor versions to reduce the UA.

³ Correction, refer to the update in the The Case of the Web page Redirects. Our web filtering software creates a unique UA hash in HKCU.