We came across an issue when trying to load Report Manager. We would get the following exception:
System.ArgumentException: Version string portion was too short or too long. at
System.Version..ctor(String version) at
In turn, this prevented Report Manager from loading. The exception itself is occuring within the .NET Framework, not from Reporting Services (System.Web.Configuration.HttpCapabilitiesBase.GetClrVersions). GetClrVersions is essentially parsing the UserAgent and getting the latest .NET version available on the client side.
You might be asking why would we care about the client side when I'm trying to load Report Manager which should be processed server side. If we look at the callstack, we can see that we are building the URL for the Report Builder button. Report Builder (RB) is a client side tool, hence we need to make sure that you have the proper .NET version on the client so that we can expose RB to you.
What do we do now? We knew that we were failing when trying to build out the URL, and from the callstack we know it had something to do with the UserAgent. Unfortunately, the logs don't tell me what the UserAgent was. There are many ways to tell what the UserAgent is. You could use a client side tool like Fiddler to get the HTTP Requests and Responses. A network trace would also tell you what the HTTP Header information looked like in a Request. A memory dump when the exception occurs would also show you what the UserAgent looked like as it related to the code. I decided to go with the Memory Dump route. You can do this as well by using the SOS extension that ships with the .NET Framework along with WinDBG which is part of the Debugging Tools for Windows.
When I opened the dump, I was immediately placed on the thread that caused the exception. In this case it was Thread 37. So, I dumped the Stack Objects for that thread.
From this alone, I can see what the UserAgent string is. You can also drill a little further into the string itself by Dumping the String Object. We do this by way of the !do command (do = Dump Object)
Please use caution whenever modifying the registry. I also recommend you export the key before modifying it so that you have a backup if needed.
Here is what this looks like on my machine.
You can have multiple builds for the same version. For example, I list two entries for the .NET Framework 3.5. In reality, we only need the latest version. We ultimately corrected the issue by removing the older builds and making sure we only had the latest build for each version. With the example above, we would have everything that is listed except for ".NET CLR 3.5.21022".
The reason the exception was being thrown is because the Framework call is using Regular Expressions to pull out the versions (i.e. .NET CLR 3.5, .NET CLR 3.0, .NET CLR 2.0, etc...). In the UserAgent in question, we had a entry that showed as ".NET CLR 3". This is what caused the exception.
Adam W. Saxton | Microsoft SQL Server Escalation Services