Last post Oct 07, 2008 11:45 AM by savvyboarder
Apr 15, 2008 07:23 PM|savvyboarder|LINK
I'm wondering if you can help me out with this error. We just moved to IIS 7 and this error started popping up, but I can't seem to find a fix. I've read some places that it has to do with ViewState which is why I'm posting in this forum. Any direction
is appreciated. Thanks!
Process ID: 3804
Process name: w3wp.exe
Account name: VIAWEBPROD\IUSR_extraspace
Exception type: System.Runtime.InteropServices.COMException
Exception message: The I/O operation has been aborted because of either a thread exit or an application request. (Exception from HRESULT: 0x800703E3)
Request path: /MyAccount/MakePayment.aspx
User host address: 184.108.40.206
Is authenticated: True
Authentication Type: Forms
Thread account name: VIAWEBPROD\IUSR_user
Thread ID: 23
Thread account name: VIAWEBPROD\IUSR_user
Is impersonating: False
Stack trace: at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at System.Web.Hosting.IIS7WorkerRequest.ReadEntityCoreSync(Byte buffer, Int32 offset, Int32 size)
at System.Web.Hosting.IIS7WorkerRequest.ReadEntityBody(Byte buffer, Int32 size)
at System.Web.UI.Page.GetCollectionBasedOnMethod(Boolean dontReturnNull)
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
Apr 16, 2008 11:30 AM|jpbrassard|LINK
I've been encountering this same error for the past two weeks, with little to show for it. The stack trace on the thread information is exactly the same, and is only applicable on pages that have ViewState enabled. I've done a lot of testing, and here's
what I've been able to discover so far:
I've tried disabling event validation and viewstate encryption by setting the <pages> node under <system.web> in web.config, to no effect:
<pages enableViewStateMac="false" enableEventValidation="false" viewStateEncryptionMode="Never">
I *think* the problem is with IIS7, rather than Windows XP - or maybe it's a problem with the communication between the two. What this smells like to me is that ViewState is getting corrupted somehow - but exactly how and where that corruption is happening,
I've yet to determine.
I know this isn't a solution to your problem, savvyboarder, but maybe this information will help narrow down the focus and give you or anyone else some bright ideas.
If I find out anything else, I'll put my findings here.
Apr 16, 2008 12:38 PM|savvyboarder|LINK
Thanks JP! I will keep digging as well, any information helps!!
Apr 30, 2008 04:03 PM|ian_a_anderson|LINK
I am getting the same error on our Windows Server 2008 IIS7 box. It seems to happen randomly.
May 01, 2008 07:38 AM|jpbrassard|LINK
Can you test for the error on different client operating systems, as well as different browsers? As per my post, I've tested viewing our web app (hosted on Server 2008/IIS7) from boxes or VMs running Windows XP SP2, Vista, Server 2003 and Server 2008, running
both IE7 and Firefox 2.x. The error consistently happens when viewing from XP SP2, no matter which browser is used. I can view the web app fine,
consistently without error, from the other client operating systems, again regardless of browser.
One thought I had: we make extensive use of the GridView control throughout our app. The page where I first noticed the error happening contains two GridView controls, bound to DataTables for their datasources. The DataTables aren't huge - four columns each,
one containing at most 3 rows of data, the other so far never getting above 10 rows - so I've stuffed them into ViewState to maintain their state. The page initially loads fine, but any kind of postback triggers the described error, when viewed from XP SP2.
However, another page in our app that does not use the GridView control
never experiences this error.
I'm not sure what this signifies. I don't think it's a problem with the GridView control, or any specific control really. I still think it's a ViewState weirdness thing, and the GridView control makes fairly extensive use of ViewState, so...
I'm going to keep plugging away at this one, as time allows. I'll report back with any significant findings.
May 01, 2008 08:51 AM|ian_a_anderson|LINK
The error is so intermittent that it's hard to test for. However, I can confirm that the error is happening on WinXP SP2 clients running IE7. We do not use the GridView control, so it isn't an issue specific to that control. If it happens across both IE
and FireFox then it seems more like a TCP communication issue between XP SP2 and Server 2008. Are you running your apps under an HTTPS/SSL web address? Ours is, and that could be another factor to consider.
Does your problem always happen on a certain page? If so, maybe try saving the HTML from the page to see if you can capture a testable scenario. I'll try to do the same and will post again if I can isolate the problem. If we can get to this point then it
probably would be worth opening a ticket with MS suport to see what they say.
May 01, 2008 01:04 PM|ian_a_anderson|LINK
FYI -- I just got this error message from a Vista client running IE7... so it is not related to Windows XP.
May 01, 2008 01:53 PM|jpbrassard|LINK
Our app will be running under HTTPS/SSL when it goes into production, but we're still fairly early on in the process yet, so we're just running under normal HTTP.
I'm intrigued, now that you've gotten the error to occur on a Vista client, as I have yet to be able to produce this error on Vista, or anything other than XP SP2. You've said your error happens pretty randomly, but
how randomly? Is it always the same page that errors, just not all the time? Or does the error happen sporadically, regardless of page?
I'm working on producing a sample app that will produce this error, with the idea of opening a trouble ticket with MS. At this point, the only other thing I can think to do is run a network trace/packet sniffer while viewing the app and see if anything interesting
turns up when the error happens.
Keep you apprised,
May 01, 2008 02:04 PM|ian_a_anderson|LINK
It occurs sporadically (5-6 times per day) across several different pages. There doesn't seem to be one specific page that is causing the problem. Even more interesting is that I spoke to the Vista user and they did not get any error page returned, even
though an error was generated and emailed to our support mailbox. The request processed fine, and they viewed the resulting page fine. So, from a user standpoint, it's hard to tell if this is actually affecting users. Have you witnessed the error on your system?
Do you get an error page back as the response?
May 01, 2008 02:21 PM|jpbrassard|LINK
I have witnessed the error, but what happens is that the page just sits there for a few minutes (3-4 minutes, I think) before finally displaying an error page saying the thread aborted, or something like that. I haven't seen an instance in our app where
this error happens but the user gets results back from the postback.
Are there any asynchronous calls in the offending page (like a "fire-and-forget" WCF service hosted through IIS7) that could have triggered the error? That might explain the behavior on the Vista client.
May 01, 2008 03:03 PM|ian_a_anderson|LINK
Nothing asynchronous is on the offending page. No AJAX or anything fancy. Just a basic event handler...
May 06, 2008 03:18 PM|savvyboarder|LINK
We contacted Microsoft about the problem, and it is a known issue they are working on a fix for. They said it should be available in the next few months. Here is thier workaround solution for the interim.
May 06, 2008 03:23 PM|savvyboarder|LINK
i tried to make the formatting better, but when i hit post it moves everything around. Hopefully you can read it.
Jun 10, 2008 06:52 AM|Jason Hill|LINK
I have the same problem and posted here:
Someone linked back to this post and it seems like it might be a known issue. Did you implement one of the workarounds? Did they fix the problem?
The first workaround would be too much change for us. I don't understand the 2nd...isn't that just going to discard all the application errors that get raised?
Jun 10, 2008 07:54 AM|ian_a_anderson|LINK
I didn't try either of those suggestions as the issue didn't affect us severely. I also didn't like the fact that both options are essentially just cover-ups... so I am waiting for an official MS fix.
Jun 11, 2008 12:39 PM|savvyboarder|LINK
We did implement the "workaround" on the page level, but I agree that the fixes are just coverups. I wouldn't recommend placing the workaround on a global application error event.
Oct 07, 2008 11:45 AM|savvyboarder|LINK
Applying the ASP.NET 3.5 SP1 fixed this issue.