From time to time we get issues with high memory and performance issues due to massive viewstate. I have talked about it before here, but I thought I'd show some techniques for finding out which pages have high viewstate.

If you look at a memroy dump of your process in windbg and notice that your large object heap is riddled with viewstate strings, that doesn't really tell you much, except for that you have some pages that have high viewstate, so the goose chase begings trying to find the source of these viewstate strings...

Btw, if the sentence above made no sense to you at all, you might want to check out the viewstate debugging article, to figure out how you identify that you have lots of large viewstate strings in the first place...

In this post I will show two ways of figuring out which page is generating the viewstate

1. Using the IIS logs

2. Inspecting the viewstate strings

To inspect the viewstate in the pages found in the IIS logs and the viewstate strings I am using Fritz Onion's viewstate decoder which you can download here

Getting the viewstate strings and identifying that we have large viewstate

The scenario here is usually that we have slow running pages and/or memory bloat in the asp.net process, and while looking at the memory we notice lots of large strings on the large object heap

SOS will not automatically print out the strings since this takes some time and clutters the image a bit, but we can print out all the large strings with a foreach command. 

In this example below I loop through all the strings over 85000 bytes (i.e. the ones on the large object heap), and then we print them with -nofields since we are only interested in the strings themselves.

I am just showing partial output to save some space, but what we see here is a string starting with /wEP which is typical for viewstate strings in 2.0.  In 1.1 they usually start with dDW.  Pretty much all the large strings in this dump look about the same, so from here we can tell that we have some pages emitting viewstate > 85000 bytes which means that each time the user views these pages they will have to download this data.

If the viewstate is large enough and we have enough concurrent users viewstate like this will cause both bandwidth issues and memory issues.

Identifying the pages with large viewstate in the IIS logs

The simplest way to identify which pages have large viewstate is to start logging Bytes Sent and Bytes Received in the IIS logs and go through the IIS logs to identify pages that have a lot of bytes sent (sc-bytes). 

Starting with the ones with the highest bytes sent you can then use Fitz Onion's Viewstate decoder to decode the viewstate by entering the URL, extracting the viewstate and decoding it...

In this example I have a page http://localhost/HighViewstate/Default.aspx that contains a gridview (grdProducts) and I have filled this up with 1000 rows, where each row has a product name (Product 1, Product 2, etc.)

When we decode it, we can see that my page has a viewstate of 164952 characters (~329904 bytes) which corresponds nicely to some of the strings on the LOH

Further, in the viewstate decoder (ControlState) we can see that we have one dictionary entry, grdProducts, so the viewstate seems to mostly pertain to this control... in the Viewstate box we can also see what the viewstate contains and in this case it is the different values in the datagrid (Product 443, Product 444 etc.). 

So based on this we can conclude that if we want to lower the amount of viewstate this page is emitting we would have to do something about the gridview, like removing the viewstate, filtering the data or similar.

Inspecting the viewstate strings from the dump

Inspecting the strings takes a lot longer and requires debugging, but it is also a more precise method. 

I would recommend that you start by inspecting the IIS logs, but if you already have a dump and have identified large viewstate strings, then this is the way to figure out where they came from.

For this we need to extract the whole string, plug it into the decoder and click Decode->.

If you run !do on the string, this will print out the string, but unfortunately it will only print out a part of the string so we need to figure out a way to get the full string so that we can plug it into the viewstate decoder.

Looking at this string for example

We can see that the size is 329922 bytes or 0x508c2 hex bytes, and we can print out the string using du <address> <address>+size, or to be more specific we would print it out using du <address>+0xc <address>+size because the actual string starts at an offset of 0xc.   du means dump unicode, i.e. du <start> <end> will print the contents between <start> and <end> in unicode, which is what we want.

ok, so this gives us the string, and we can copy and plug it into the viewstate decoder if it wasn't for the fact that we would have to manipulate the output, removing the first column and the double quotes which is a bit of a hassle.

To get a clean string, we can execute the same command, and encapsulate it in a .foreach so that we skip the first column by adding /pS 1 /ps 1

And now, finally we have a clean string that we can copy into the Viewstate String: textbox in the viewstate decoder. When we decode it we will get a very similar output to the one we got when decoding viewstate from an URL, and based on the contents of the viewstate (i.e. finding out that it belongs to grdProducts, and has the contents Product 1, Product 2 etc. ) we can narrow down the page that it belongs to.

And that is pretty much all there is to it...  

Laters,

Tess