Silverlight Download URL Serves 64-bit Installer to 32-bit IE and Firefox, but Serves 32-bit Installer to Chrome - by dkleb-df

Status : 


Sign in
to vote
ID 779931 Comments
Status Active Workarounds
Type Bug Repros 0
Opened 2/25/2013 5:35:10 AM
Access Restriction Public


The Silverlight download URL, "", uses the user-agent string to determine the type of installer to serve.
If the browser is IE and the host is 64-bit Windows, it serves the 64-bit installer. It doesn't care if the browser itself is 32-bit or 64-bit.
If the browser is 32-bit Firefox running on a 64-bit host, it also serves the 64-bit installer.
But if the browser is32-bit Chrome running on a 64-bit host, it serves the 32-bit installer (it ignores the host platform).
If the 64-bit Silverlight installer was used originally, it must continue to be used thereafter. If an attempt is made to update Silverlight with a 32-bit installer, the install fails with the message "A 64-bit version of Silverlight is already installed".
Both Firefox and Chrome have implemented version checks on plugins, in order to block access to plugins that are out-of-date and potentially contain security bugs. When an out-of-date Silverlight plugin is detected, these browsers automatically go to the Microsoft web site (as above) to download the plugin. They do so without user interaction, in order to make the process as seamless as possible.
The problem is that Chrome is being handed the 32-bit installer, and this installer fails if the 64-bit plugin is already present.
The result is a horrible user experience, and since it's the Silverlight installer that's failing, it points users to a Silverlight problem. The only workaround is to use IE to download the 64-bit Silverlight plugin. It's also not clear from the error message what a user needs to do to fix the problem.
This seems to be a difficult situation, because HTTP GET that retrieves the installer doesn't tell you which version is already installed. That information may not be easily determined either (by the 32-bit browsers).
The most obvious fix is to behave the same way Firefox behaves, and serve the browser a 64-bit installer. Another is to to hand the browser an installer that works in all scenarios. A universal installer would determine what components are installed, download the updates it needs, and update them. An alternative might be to provide different installers for different browsers. As a least desirable alternative, the 32-bit installer could recognize the situtation and provide better feedback (that's a less desirable alternative since they would have unnecessarily downloaded the 32-bit installer).

Sign in to post a comment.
Posted by Microsoft on 4/29/2014 at 12:30 PM
Thank you for reporting this issue. This issue has been fixed in Visual Studio 2013. You can install a trial version of Visual Studio 2013 with the fix from:
Posted by Microsoft on 7/15/2013 at 1:22 PM
Thank you for identifying this issue. We have fixed the problem, and the change is included in Silverlight 5 GDR3, released as part of MS13-052/KB2847559. You may download this fix at We are deeply appreciative for your commitment to help us build better products, and we hope this fix improves your experience with our tools and technologies.

The Silverlight Team
Posted by dkleb-df on 6/20/2013 at 6:33 AM
Hey guys, I know you've lost that lovin feeling as far as Silverlight is concerned, but can't we get this fixed? Or at least a response?
Posted by Microsoft on 2/25/2013 at 6:41 PM
Thank you for submitting feedback on Visual Studio and .NET Framework. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by Microsoft on 2/25/2013 at 5:51 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(