Starting a few months ago we started receiving System.Web.HttpException: Invalid viewstate. errors thru our websites. It started out just happening very rarely and we started getting more and more of the errors. The callstack was usually:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Web.HttpException: Invalid viewstate.at System.Web.UI.Page.DecryptString(String s)--- End of inner exception stack trace ---at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)at System.Web.Handlers.ScriptResourceHandler.DecryptString(String s)at System.Web.Handlers.ScriptResourceHandler.DecryptParameter(NameValueCollection queryString)at System.Web.Handlers.ScriptResourceHandler.ProcessRequest(HttpContext context)at System.Web.Handlers.ScriptResourceHandler.System.Web.IHttpHandler.ProcessRequest(HttpContext context)at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)   

I looked at similarities of the error and noticed that the user agent was always:

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

Also, the query string would contain HTML text in the querystring, like:

d=Q0M5xAMIxE-XI2-0ILfpxYhpmFOEVhqxB_ONfw1nSIFAoH8HCyt--97Kq_DD1JoDIf7tnu8rxs0nJzeGOz1YULX%20%20%20%20%20%20%20%20%20%20%20<table%20style=

So it seemed that IE 8 was causing the error, after research I found that I was right. IE8 was causing the problem. I found this bug report on the issue.

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=434997 

We've launched a new site, OmahaBarCard.com.

With it you can get deals from over 72 bars in Omaha, Nebraska.

We're going to be adding more later such as image galleries and event calendars.

UPDATE: There's a permanent fix at the end of the post  

After our client computers ran the update Cumulative Security Update for ActiveX Killbits (KB956391) it broke the reporting servies report viewer.

Security Advisory for 956391

If you have the update and you click the print button on the report viewer control you will recieve a message that says "Unable to load client print control"

I've looked around to see if there's anything to update, such as the servers version of Reporting services or the ReportViewer control.
On a test server I've installed the newest ReportViewer control but it didn't seem to fix the issue.

I've found that removing the hotfix fixes the issue.

From the way it sounds the killbit was set for the control because it had a vulnerability where GDI+ could allow remote code execution.

Microsoft Security Bulletin MS08-052

Edit:There's a ReportViewer SP1 but that doesn't seem to solve the issue for me, where others have stated it's solved their issue.

I've found a temporary solution, its not a very good solution cause you'll still open up the vulnerability but until microsoft comes out with a new reportviewer control there's not much of a choice.

You can turn off the killbits for the control thru the registry.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{FA91DF8D-53AB-455D-AB20-F2F023E498D3}]

"Compatibility Flags"=-

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{FA91DF8D-53AB-455D-AB20-F2F023E498D3}]

"Compatibility Flags"=-

 Then when you want to  turn them back on

 Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{FA91DF8D-53AB-455D-AB20-F2F023E498D3}]

"Compatibility Flags"=dword:00000400

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{FA91DF8D-53AB-455D-AB20-F2F023E498D3}]

"Compatibility Flags"=dword:00000400

 I will keep this updated if I find a better solution. 

UPDATE FOR PERMANENT FIX :

There's SQL server updates that fix the issue.

Install the appropriate update for your SQL server version.

for SQL version 9.00.3042-9.00.3072 get the GDR version

for SQL version 9.00.3150-9.00.3281 get the QFE Version

UPDATE 10/20:

Over the weekend I applied the patches to our SQL server and we're still getting the issue in our application. However, I'm able to print fine from the Reporting Services Reporting Manager, which didn't work before the patch.

Just briefly what we're running for servers, We've got a SQL Server 2005 SP2 with the GDR update running on Windows 2003, and a Web Server on Windows 2003.

I'm guessing that I need to update the control in our application, but I'm not sure where I would get the newer version. It doesn't seem to be part of the ReportViewer 2005 SP1 Redist.

I'll keep this blog updated if I find out anything. 

UPDATE 8-4-09

Sorry for not updating this till now.. I've figured out a solution, but its not a very good one.
After updating the SQL server to Service Pack 2 from the above links, I had to manually update gdiplus.dll on all our client computers.

I also manually updated the report viewer 2008 control.

I used the GDIplus.dll that was installed on the webserver when SQL Server SP2 was installed.

Post a comment if you have any questions.