We're implementing a complex web application based on force.com Sites and ran into problems with the ViewState size of one of our pages. Now on the platform I would activate Development Mode and the ViewState tab to find out what causes the trouble. But on the portal neither Development Mode nor ViewState tab can be used. What's even more problematic is the fact that the debug log for the portal user claims that the page was loaded successfully. That means the ViewState Exception is not even listed in the log. I think force.com Sites is great but without the minimum set of development tools it's getting really difficult. Any suggestions on how to debug the problem?
Debugging the view state is a tricky one, as is debugging sites or customer portal pages. Each requires different approaches.
First, to debug un-authenticated sites page the simplest approach is to just view the page internally. Since un-authenticate sites pages will behave the same (mostly) in different contexts this usually gets the job done.
Second, to debug authenticated sites or customer portal pages it helps to add a 'runAs' param to your page, that when present will be used in place of UserInfo.getUserId() in queries. This way you can see the same data as if you were logged in as a the sites/customer portal user (mostly), but still have the full suite of debugging tools at your finger tips.
The caveat to both those approaches is that the permissions when run internally will be different. In those cases you'll want to fall back to preview mode (w/sites) or debug log monitoring. And when all else fails a good old binary search can do the trick.
Finally, for view state debugging, the challenge for me has also been that once you're over the view state limit you can't see any data about what the excess was. The only strategy here is to put limits on your queries until you get just below the limit and then use the view state inspector to figure out where you can optimize your controller memory storage. And lord help you if it turns out that your failing due to a large internal view state. This housekeeping section of the view state is wholly undocumented and can be very tricky to unwind one you start hitting it.
You can log in to Salesforce itself and bring up the page as yourself via the apex URL, e.g.,
https://c.cs9.visual.force.com/apex/yourPage (credit @DanielHoechst in a similar question). That doesn't help you out if there is anything specific about the portal user causing the problem, though.
For that, you can get some information in the Developer Console. You can create a debug log for the portal user and then view it in the Developer Console. You will have to uncheck the "Show My Current Logs Only" checkbox. Once you load the debug log, in the Stack Tree pane there are Execution Tree and Performance Tree tabs and there is also an Execution Overview pane that can give you some more information.
Once in Developer Console, you can click on the Help link on the far right to get more information about how to use Developer Console, or you can go to the Developer Console docs.