95

I have very little to go on here. I can't reproduce this locally, but when users get the error I get an automatic email exception notification:

Invalid length for a Base-64 char array.

  at System.Convert.FromBase64String(String s)
  at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)
  at System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter.Deserialize(String serializedState)
  at System.Web.UI.Util.DeserializeWithAssert(IStateFormatter formatter, String serializedState)
  at System.Web.UI.HiddenFieldPageStatePersister.Load()

I'm inclined to think there is a problem with data that is being assigned to viewstate. For example:

List<int> SelectedActionIDList = GetSelectedActionIDList();
ViewState["_SelectedActionIDList"] = SelectedActionIDList;

It's difficult to guess the source of the error without being able to reproduce the error locally.

If anyone has had any experience with this error, I would really like to know what you found out.

Michael
  • 8,362
  • 6
  • 61
  • 88
Slim
  • 5,635
  • 7
  • 31
  • 30

12 Answers12

85

After urlDecode processes the text, it replaces all '+' chars with ' ' ... thus the error. You should simply call this statement to make it base 64 compatible again:

        sEncryptedString = sEncryptedString.Replace(' ', '+');
Jalal El-Shaer
  • 14,502
  • 8
  • 45
  • 51
  • Great stuff. Thanks. I was calling an ASP.NET web service from a C++ MFC application and could have branched off in many directions trying to solve this and after having already spent a good few hours on it. You've just saved me a bunch of time. – nspire Jul 08 '12 at 10:31
  • 3
    Just hit this problem and as you said it was spaces, replacing with `+` fixed it. Hero! – Mathew Thompson Apr 16 '13 at 14:52
  • Can anyone give guidance on where to include this code? I'm dealing with this issue frequently, but from the code snippet, I can't determine where to implement the fix. – dst3p Jul 26 '19 at 15:42
  • @dst3p Use it wherever in the processing pipeline you face the error. Check your stack trace and see which method is causing the error. – Jalal El-Shaer Jul 29 '19 at 05:05
39

I've seen this error caused by the combination of good sized viewstate and over aggressive content-filtering devices/firewalls (especially when dealing with K-12 Educational institutions).

We worked around it by storing Viewstate in SQL Server. Before going that route, I would recommend trying to limit your use of viewstate by not storing anything large in it and turning it off for all controls which do not need it.

References for storing ViewState in SQL Server:
MSDN - Overview of PageStatePersister
ASP Alliance - Simple method to store viewstate in SQL Server
Code Project - ViewState Provider Model

Houda
  • 835
  • 3
  • 11
  • 17
Jimmie R. Houts
  • 7,728
  • 2
  • 31
  • 38
  • I copied the veiwstate of the page and pasted it into Word. It was over 86000 characters long. That seems like too much. – Slim May 13 '09 at 17:57
  • Yikes, I'm running into the problem now. I have turned ViewState off for all controls that I possibly can. I am using a Wizard control with several pages and lots of content. Any advice? – Mike Cole Aug 20 '09 at 14:18
  • @Mike C., this is a very frustating problem! You could break the content of each page of the wizard into user controls and load the content on demand (via ajax?). Of course, this is only a solution for that one page, if you begin to experience the problem on a consistent basis, you may want to consider storing viewstate in your database. I have updated my answer with references for storing viewstate in SQL Server. – Jimmie R. Houts Aug 22 '09 at 05:20
  • 1
    Another problem I've run into with over 86000 chars long (actually may be close to 85K I think, assuming single-byte chars) is that your .NET app may also start putting viewstate strings on the large object heap which can lead to heap fragmentation over time (and eventually OutOfMemoryException) if the app pool is not recycled. – nothingisnecessary Jul 09 '13 at 22:12
  • I got same issue, how to resolve this issue please clarify it. – Sajith Oct 09 '14 at 13:04
21

My guess is that something is either encoding or decoding too often - or that you've got text with multiple lines in.

Base64 strings have to be a multiple of 4 characters in length - every 4 characters represents 3 bytes of input data. Somehow, the view state data being passed back by ASP.NET is corrupted - the length isn't a multiple of 4.

Do you log the user agent when this occurs? I wonder whether it's a badly-behaved browser somewhere... another possibility is that there's a proxy doing naughty things. Likewise try to log the content length of the request, so you can see whether it only happens for large requests.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
15

Try this:

public string EncodeBase64(string data)
{
    string s = data.Trim().Replace(" ", "+");
    if (s.Length % 4 > 0)
        s = s.PadRight(s.Length + 4 - s.Length % 4, '=');
    return Encoding.UTF8.GetString(Convert.FromBase64String(s));
}
Petr Voborník
  • 1,249
  • 1
  • 14
  • 11
11
int len = qs.Length % 4;
            if (len > 0) qs = qs.PadRight(qs.Length + (4 - len), '=');

where qs is any base64 encoded string

Christian Specht
  • 35,843
  • 15
  • 128
  • 182
Bhuvana
  • 111
  • 1
  • 2
8

As others have mentioned this can be caused when some firewalls and proxies prevent access to pages containing a large amount of ViewState data.

ASP.NET 2.0 introduced the ViewState Chunking mechanism which breaks the ViewState up into manageable chunks, allowing the ViewState to pass through the proxy / firewall without issue.

To enable this feature simply add the following line to your web.config file.

<pages maxPageStateFieldLength="4000">

This should not be used as an alternative to reducing your ViewState size but it can be an effective backstop against the "Invalid length for a Base-64 char array" error resulting from aggressive proxies and the like.

Community
  • 1
  • 1
Red Taz
  • 4,159
  • 4
  • 38
  • 60
1

Take a look at your HttpHandlers. I've been noticing some weird and completely random errors over the past few months after I implemented a compression tool (RadCompression from Telerik). I was noticing errors like:

  • System.Web.HttpException: Unable to validate data.

  • System.Web.HttpException: The client disconnected.---> System.Web.UI.ViewStateException: Invalid viewstate.

and

  • System.FormatException: Invalid length for a Base-64 char array.

  • System.Web.HttpException: The client disconnected. ---> System.Web.UI.ViewStateException: Invalid viewstate.

I wrote about this on my blog.

Michael
  • 8,362
  • 6
  • 61
  • 88
  • Your blog is down. Do you have another link or can you post the relevant info? thx – mga911 May 01 '14 at 02:16
  • 1
    http://web.archive.org/web/20111015131130/http://dot-net-sam.blogspot.com/2009/08/random-errors-invalid-length-for-base.html – csm8118 Jul 21 '14 at 20:16
1

This isn't an answer, sadly. After running into the intermittent error for some time and finally being annoyed enough to try to fix it, I have yet to find a fix. I have, however, determined a recipe for reproducing my problem, which might help others.

In my case it is SOLELY a localhost problem, on my dev machine that also has the app's DB. It's a .NET 2.0 app I'm editing with VS2005. The Win7 64 bit machine also has VS2008 and .NET 3.5 installed.

Here's what will generate the error, from a variety of forms:

  1. Load a fresh copy of the form.
  2. Enter some data, and/or postback with any of the form's controls. As long as there is no significant delay, repeat all you like, and no errors occur.
  3. Wait a little while (1 or 2 minutes maybe, not more than 5), and try another postback.

A minute or two delay "waiting for localhost" and then "Connection was reset" by the browser, and global.asax's application error trap logs:

Application_Error event: Invalid length for a Base-64 char array.
Stack Trace:
     at System.Convert.FromBase64String(String s)
     at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)
     at System.Web.UI.Util.DeserializeWithAssert(IStateFormatter formatter, String serializedState)
     at System.Web.UI.HiddenFieldPageStatePersister.Load()

In this case, it is not the SIZE of the viewstate, but something to do with page and/or viewstate caching that seems to be biting me. Setting <pages> parameters enableEventValidation="false", and viewStateEncryption="Never" in the Web.config did not change the behavior. Neither did setting the maxPageStateFieldLength to something modest.

fortboise
  • 1,002
  • 12
  • 10
0

In addition to @jalchr's solution that helped me, I found that when calling ATL::Base64Encode from a c++ application to encode the content you pass to an ASP.NET webservice, you need something else, too. In addition to

sEncryptedString = sEncryptedString.Replace(' ', '+'); 

from @jalchr's solution, you also need to ensure that you do not use the ATL_BASE64_FLAG_NOPAD flag on ATL::Base64Encode:

 BOOL bEncoded = Base64Encode(lpBuffer,
                    nBufferSizeInBytes,
                    strBase64Encoded.GetBufferSetLength(base64Length),
                    &base64Length,ATL_BASE64_FLAG_NOCRLF/*|ATL_BASE64_FLAG_NOPAD*/);
Michael
  • 8,362
  • 6
  • 61
  • 88
nspire
  • 1,567
  • 23
  • 26
0

As Jon Skeet said, the string must be multiple of 4 bytes. But I was still getting the error.

At least it got removed in debug mode. Put a break point on Convert.FromBase64String() then step through the code. Miraculously, the error disappeared for me :) It is probably related to View states and similar other issues as others have reported.

TheTechGuy
  • 16,560
  • 16
  • 115
  • 136
0

This is because of a huge view state, In my case I got lucky since I was not using the viewstate. I just added enableviewstate="false" on the form tag and view state went from 35k to 100 chars

coderman
  • 1,485
  • 1
  • 16
  • 15
0

During initial testing for Membership.ValidateUser with a SqlMembershipProvider, I use a hash (SHA1) algorithm combined with a salt, and, if I changed the salt length to a length not divisible by four, I received this error.

I have not tried any of the fixes above, but if the salt is being altered, this may help someone pinpoint that as the source of this particular error.

John
  • 434
  • 2
  • 20