mysterious asp.net errors

[rh]

hi all,
i've got a multi-page form that requests a bunch of stuff
and saves the info in viewstate as it goes from page to page.
finally the data is saved to sqlserver and an email is sent
to user.
here's the problem:
the page fails occasinally. the reason i know is that i have
a customerror in web.config. ever time there's a failure the
user is sent to that custom page and that page sends me an email
including the the full url. the aspxerrorpath in most cases
point to this page.

usually i get a bunch of failures within a very short period and
then things are back to normal.
i have try/catch blocks all over the page but i'm not trapping
anything in there.

somehow this page fails and the user is ushered to the custom error
page but the try/catch blocks never get a chance to report anything
back to me. and i've tested them by throwing a deliberate
exception and catching it.
is it possible that asp.net is auto-recycling thereby
messing the viewstate and other things between form posts?

i'm at my wit's end. anyone could suggest what other places to look
at for troubleshooting? using dotnet 1.1 on win2003server.

thanks,
rh

[Curt_C [MVP]]

check your win2k3 IIS settings on that AppPool.
If you have it set to recycle at a certain memory usage point it could be
hitting it's limit. Try upping it

--
Curt Christianson
Owner/Lead Developer, DF-Software
Site: http://www.Darkfalz.com
Blog: http://blog.Darkfalz.com
"rh" <rh********@hotmail.com> wrote in message
news:56**************************@posting.google.c om...

hi all,
i've got a multi-page form that requests a bunch of stuff
and saves the info in viewstate as it goes from page to page.
finally the data is saved to sqlserver and an email is sent
to user.
here's the problem:
the page fails occasinally. the reason i know is that i have
a customerror in web.config. ever time there's a failure the
user is sent to that custom page and that page sends me an email
including the the full url. the aspxerrorpath in most cases
point to this page.

usually i get a bunch of failures within a very short period and
then things are back to normal.
i have try/catch blocks all over the page but i'm not trapping
anything in there.

somehow this page fails and the user is ushered to the custom error
page but the try/catch blocks never get a chance to report anything
back to me. and i've tested them by throwing a deliberate
exception and catching it.
is it possible that asp.net is auto-recycling thereby
messing the viewstate and other things between form posts?

i'm at my wit's end. anyone could suggest what other places to look
at for troubleshooting? using dotnet 1.1 on win2003server.

thanks,
rh

[rh]

thanks,
i'll look into doing this. so it is possible that this behaviour
is caused by the app recycling in the middle of a bunch of users
going thru the motions on this page. suddenly their viewstates
get wiped and the app throws an exception? i still have some trouble
understanding why. viewstate is a hidden field, unlike the session
vars, so even if the app recycles in between page posts, the
page should pick up from where it left off, right?

i have checked the event log and i'm not seeing any recycling
or other critical entries there, but perhaps no logs are
generated when this happens.

the app contains many pages that share a number of resources
such as ascx controls. if i divide them up to multiple apps,
i believe i'd have to copy those resources to each separate
app in order to be able to use them.

maybe there is bad page (maybe one with inifinite loop inside)
in the site that causes all this. if so, would i be able to pinpoint
the errant page by looking in some log file somewhere? also would perfmon
be of any assistance? if so, which items should i be tracking? there are
oh so many of them.

thanks,
rh

"Curt_C [MVP]" <software_AT_darkfalz.com> wrote in message news:<OX**************@tk2msftngp13.phx.gbl>...

check your win2k3 IIS settings on that AppPool.
If you have it set to recycle at a certain memory usage point it could be
hitting it's limit. Try upping it

--

[rh]

... and for those who might be curious about if there
were a resolution to this, the answer is yes.
the viewstate was getting corrupt between page posts,
hence the error. and the fix was to set enableviewstatemac=false.
despite what the doc claims, this value is true by default,
the viewstate gets bloated and it sometimes gets corrupt between page
posts. i couldn't find why encrypting the viewstate would
cause such error. perhaps the bloated version couldn't
always be correctly decrypted due to size. but after
making the change, the page is behaving okay.

if you are going to disable enableviewstatemac, beware the
the viewstate data will make the round trips unencrypted and
can be easily deciphered by the users. don't store anything
critical in there such as db logic, system accounts, etc.

rh
rh********@hotmail.com (rh) wrote in message news:<56**************************@posting.google. com>...

thanks,
i'll look into doing this. so it is possible that this behaviour
is caused by the app recycling in the middle of a bunch of users
going thru the motions on this page. suddenly their viewstates
get wiped and the app throws an exception? i still have some trouble
understanding why. viewstate is a hidden field, unlike the session
vars, so even if the app recycles in between page posts, the
page should pick up from where it left off, right?

i have checked the event log and i'm not seeing any recycling
or other critical entries there, but perhaps no logs are
generated when this happens.

the app contains many pages that share a number of resources
such as ascx controls. if i divide them up to multiple apps,
i believe i'd have to copy those resources to each separate
app in order to be able to use them.

maybe there is bad page (maybe one with inifinite loop inside)
in the site that causes all this. if so, would i be able to pinpoint
the errant page by looking in some log file somewhere? also would perfmon
be of any assistance? if so, which items should i be tracking? there are
oh so many of them.

thanks,
rh