IsPostBack wrongly returning false

[Guest]

I've been debugging an issue we have in an asp.net 2.0 application for
several days.

The initial report of the bug was that, after waiting for some minutes with
an open page, entering a number in a search box and clicking the
corresponding button, the page came empty.
Entering the data again and clicking the button always gives results.

I wrote a "request sniffer" module that writes a log for all requests that
includes the time, method, url, IsPostBack, referer, server ip and body
contents (I'm willing to share it - just ask)
Using it, I was able to determine that IsPostBack is returning false when
this happens, regardless of the Request.Form collection having post data.

Some more information:
- This happens in a web farm. My initial analysis showed that the error
happened when a different server answered. But later I reproduced it with the
same server
- We're using SiteMinder, a SSO agent implemented in ISAPI. However, this
appears not to be the cause
- The site is located in a network share. This required changes to the .NET
security policies. Also, besides having supposedly configured the machineKey
in all the boxes, I had to disable viewStateEncryption and enableViewStateMac
some time ago
- The error appears in a completely erratic way; I haven't found a
reproduction pattern yet. I have another development server (not a web farm)
where the error hasn't been reproduced

All help with this will be greatly appreciated.
When suggesting things to test, keep in mind that I'm NOT the server
administrator (I only have file share access to the website root). The web
farm runs several corporate sites and it can't be happily restarted or have
its global configuration changed without a good reason.

 

[offwhite]

It sounds like somewhere you are losing your current state. Check the
following areas.

- Very low session timeout (or prematurely kicked out of application
pool)
- Sticky sessions failing on load balancer for web farm
- The page is interfering with the Javascript firing the PostBack
- The affected clients have cookies disabled (fix with autodetect)

Once you can repeat the problem you may be able use Firefox with the
Javascript console to monitor errors in the Javascript.

Once you have looked at these areas, you may want to explore using
Control State to better ensure you keep your necessary state.

Control State vs View State
http://msdn2.microsoft.com/en-us/library/1whwt1k7.aspx

 

[Steven Cheng[MSFT]]

Hey Diego,

As for the strange postback behavior, is it specific to a particular page?
Based on my experience, there is some empty page issue related to
smartnavigation and response.redirect, however, that's in ASP.NET 1.X
application. For your scenario, I still think it is possibly the page's
ViewState is corrupted which cause the postback behavior incorrect. BTW,
since you have limited permission on the production server, it'll be
helpful if we can generate a reproduce environment on a test machine.

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.



Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Guest]

Thanks for your answer. I forgot to say sessionState is Off. I'm not using
sessions at all.
Besides, I'm not losing the state of ONE control. All the page is lost
because of IsPostBack returning false, even though all the information is in
the form body.
Cookies are enabled, and since this happens erratically (in the same browser
session), the only thing left would be the javascript... but the logged
request appears to be fine (see the log in my reply to Steven)

 

[Guest]

Steve,

Thanks for your answer.
My comments will be mixed with your text, old style

As for the strange postback behavior, is it specific to a particular page?

I have only one page (Default.aspx), as this is a small application (It has
a lot of nested control, though)

Based on my experience, there is some empty page issue related to
smartnavigation and response.redirect, however, that's in ASP.NET 1.X
application.

I'm not using smartnavigation (deprecated), although I AM using
maintainScrollPositionOnPostBack. I'm not using redirects of any kind.

For your scenario, I still think it is possibly the page's
ViewState is corrupted which cause the postback behavior incorrect. BTW,
since you have limited permission on the production server, it'll be
helpful if we can generate a reproduce environment on a test machine.

The problem is, it doesn't reproduce at all on my test machine :-(

Now, if the ViewState was corrupted, shouldn't I get an exception?
I'm sending examples of "good" and "buggy" requests.
Good one (IsPostBack=true):

2006-05-26 08:23:54Z POST /Default.aspx
IsPostBack: True
Referer: http://tps-t2-test.*****.com/Default.aspx
User: *****
Server: ***.***.***.132
Body:
__EVENTTARGET:
__EVENTARGUMENT:
__LASTFOCUS:
__VIEWSTATE: (...snip...)
ctl00$Content$SearchExpander$StateKeeper: True
ctl00$Content$OrderNumberTextBox: 4578097
ctl00$Content$GetOrderButton: Get

ctl00$Content$VersionSelector$OrderVersionFormView$OrderVersionDropDownList: 2
ctl00$Content$TelephoneNumberTextBox:

ctl00$Content$OrderView$OrderFormView$OrderInformationSection$SectionExpander$StateKeeper: False

ctl00$Content$OrderView$OrderFormView$TaskStatusSection$SectionExpander$StateKeeper: True

ctl00$Content$OrderView$OrderFormView$AuditTrailSection$SectionExpander$StateKeeper: True

ctl00$Content$OrderView$OrderFormView$DetailsSection$SectionExpander$StateKeeper: False

ctl00$Content$OrderView$OrderFormView$WorkPackageSection$SectionExpander$StateKeeper: False

ctl00$Content$OrderView$OrderFormView$WorkPackageSection$WorkPackageBlock$WPRepeater$ctl01$CommandExpander$StateKeeper: True

ctl00$Content$OrderView$OrderFormView$WorkPackageSection$WorkPackageBlock$WPRepeater$ctl01$DueDateTextBox: Apr/21/2006 15:44:45

ctl00$Content$OrderView$OrderFormView$WorkPackageSection$WorkPackageBlock$WPRepeater$ctl01$CSDLBlock$CSDLRepeater$ctl01$CSDLExpander$StateKeeper: True

ctl00$Content$OrderView$OrderFormView$WorkPackageSection$WorkPackageBlock$WPRepeater$ctl01$CSDLBlock$CSDLRepeater$ctl02$CSDLExpander$StateKeeper: True
__SCROLLPOSITIONX: 0
__SCROLLPOSITIONY: 0
__PREVIOUSPAGE: OhNCDIkOEWrq3LZu42rczg2
__EVENTVALIDATION: (...snip...)


And this is a "bad" request (IsPostBack=false), performed 30 minutes later:

2006-05-26 09:10:32Z POST /Default.aspx
IsPostBack: False
Referer: http://tps-t2-test.*****.com/Default.aspx
User: *****
Server: ***.***.***.131
Body:
__EVENTTARGET:
__EVENTARGUMENT:
__LASTFOCUS:
__VIEWSTATE: (...snip...)
ctl00$Content$SearchExpander$StateKeeper: True
ctl00$Content$OrderNumberTextBox: 1001827
ctl00$Content$GetOrderButton: Get

ctl00$Content$VersionSelector$OrderVersionFormView$OrderVersionDropDownList: 2
ctl00$Content$TelephoneNumberTextBox:

ctl00$Content$OrderView$OrderFormView$OrderInformationSection$SectionExpander$StateKeeper: False

ctl00$Content$OrderView$OrderFormView$TaskStatusSection$SectionExpander$StateKeeper: True

ctl00$Content$OrderView$OrderFormView$AuditTrailSection$SectionExpander$StateKeeper: True

ctl00$Content$OrderView$OrderFormView$DetailsSection$SectionExpander$StateKeeper: False

ctl00$Content$OrderView$OrderFormView$WorkPackageSection$SectionExpander$StateKeeper: False

ctl00$Content$OrderView$OrderFormView$WorkPackageSection$WorkPackageBlock$WPRepeater$ctl01$CommandExpander$StateKeeper: True

ctl00$Content$OrderView$OrderFormView$WorkPackageSection$WorkPackageBlock$WPRepeater$ctl01$DueDateTextBox: Apr/20/2006 13:38:16

ctl00$Content$OrderView$OrderFormView$WorkPackageSection$WorkPackageBlock$WPRepeater$ctl01$CSDLBlock$CSDLRepeater$ctl01$CSDLExpander$StateKeeper: True
__SCROLLPOSITIONX: 0
__SCROLLPOSITIONY: 0
__PREVIOUSPAGE: OhNCDIkOEWrq3LZu42rczg2
__EVENTVALIDATION: (...snip...)


Note that a different server is answering.
The error repeats even if I press F5 and resend post data, or go back and
press the submit button again.

 

[offwhite]

Have you tried turning off the scroll position feature?

Here is some info on potential problems with it.

http://forums.asp.net/thread/1256944.aspx

I did an ASP.NET 2.0 project this past year and used my own custom
Javascript to scroll to position. It was a client project so I cannot
just give you the code, but I will give you a few snippets so you can
implement it yourself.

When the page is loaded you can call jumpToElement(elementId) with the
ID of the element you want to jump to. For my client work I had it
optional scroll slowly or jump to that position.

// shortcut method
function d(id) {
return document.getElementById(id);
}

function jumpToElement(id) {
var xPos = 0;
var yPos = findYPos(d(id));
window.scrollTo(xPos, yPos);
}

function findYPos(obj)
{
if (!obj) { return 0; }
var curtop = 0;
if (obj.offsetParent)
{
while (obj.offsetParent)
{
curtop += obj.offsetTop
obj = obj.offsetParent;
}
}
else if (obj.y)
curtop += obj.y;
return curtop;
}