IIS 7 & IIS 8
The I/O operation has been aborted because of either a thread exit or...
Last post Oct 31, 2012 07:53 AM by runningfree
Jun 10, 2008 07:46 AM|LINK
We are in the process of moving our application across to a new installation of Win Server 2008 Datacenter. During testing, we are seeing a couple of errors come through when doing rapid simultaneous ajax postbacks:
The I/O operation has been aborted because of either a thread exit or an application request
The specified network name is no longer available
Does anyone know what is causing this and how we should
be handling this? This was never a problem on our IIS6 machine so it must be something that has changed in IIS7.
Jun 10, 2008 10:07 AM|LINK
Where are these errors occuring?
http layer? https?
Are you running a virtual machine?
Are you connecting to a database? (if you are check the DB logs to see more info)
Looked around a bit and maybe it is a known issue see here:
Jun 10, 2008 10:48 AM|LINK
Thanks for the response.
Some answers to your questions:
The UI allows for multiple ajax async postbacks to be fired by the user changing some checkboxes and other form elements on the page. If I make a lot of rapid changes, which fires of simultaneous requests and probably even queues up a couple, then I start
getting these errors through. The application does not seem to be adversely affected and contues to operate as expected without the user seeing these errors. It does result in these errors getting logged and email to us though so we would really like to fix
That post you linked to mentions the client being disconnected...do you think that applies in this case, i.e. the initial ajax async postback gets disconnected because we have fired off subsequent ones? This was never a problem in IIS6 but maybe it is something
to do with the pipeline changes in IIS7?
The first workaround in that post is too laborious because there would be lots of places where we have this type of async postback. I don't understand the 2nd workaround. Isn't this just going to discard all application errors that get raised? We would not
want this but just want to ignore either of the 2 that I mentioned in my original post. Several months for a fix seems pretty cr*p too!
Here is the full stack trace of one of the errors:
at System.Web.UI.Page.HandleError(Exception e) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint,
Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest() at System.Web.UI.Page.ProcessRequest(HttpContext context) at ASP.broadband_refine_aspx.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo) at System.Web.Util.Misc.ThrowIfFailedHr(Int32 hresult) at System.Web.Hosting.IIS7WorkerRequest.ReadEntityCoreSync(Byte
buffer, Int32 offset, Int32 size) at System.Web.HttpRequest.GetEntireRawContent() at System.Web.HttpRequest.FillInFormCollection() at System.Web.HttpRequest.get_Form() at System.Web.HttpRequest.get_HasForm() at System.Web.UI.Page.GetCollectionBasedOnMethod(Boolean
dontReturnNull) at System.Web.UI.Page.DeterminePostBackMode() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
Jun 10, 2008 09:12 PM|LINK
Unfortunately, in integrated mode on Vista RTM, Vista SP1, and Windows Server 2008, if the HTTP client is disconnected, or disconnects,
when ASP.NET reads the entity body or flushes the response, ASP.NET converts the HRESULT from IIS to an exception and throws it. The actual HRESULT can vary depending on the IIS function that fails, but here are a few common ones:
0x800703E3 "The I/O operation has been aborted because of either a thread exit or an application request."
0x800704CD "An operation was attempted on a nonexistent network connection."
0x80070040 "The specified network name is
no longer available."
"The handle is invalid."
This is fixed in .NET Framework v2.0 SP2.
With the fix you will not see any exceptions when the client is disconnected, or disconnects, while ASP.NET reads the entity body. This is scheduled to release this summer (I believe in approximately six weeks) along with .NET Framework v3.5 SP1.
Jun 11, 2008 09:30 PM|LINK
Thanks Thomas. Do you know if there is a hotfix available for this?
Jun 11, 2008 09:48 PM|LINK
There is no hotfix for this, but please feel free to contact me via my blog at
http://blogs.msdn.com/tmarq/contact.aspx and I will put you in touch with product support. If I'm correct about the release date of v2.0 SP2, then it would be difficult to create, test, and sign-off on a
hotfix in less time than the release of v2.0 SP2.
Jul 22, 2008 04:03 AM|LINK
Big thanks to Thomas for the awesome customer service and providing a private build which contained the fix for this problem.
Aug 13, 2008 04:39 PM|LINK
Good news! .NET Framework 3.5 Service Pack 1 released on Monday August 11, and can be downloaded at
http://www.microsoft.com/downloads/details.aspx?FamilyId=AB99342F-5D1A-413D-8319-81DA479AB0D7&displaylang=en. It includes an update to the .NET Framework 2.0 binaries that will fix the issue described in this forum post.
Dec 15, 2008 02:35 PM|LINK
You have stated that "with the fix you will not see any exceptions when the client is disconnected while
ASP.NET reads the entity body."
And what about flushing the response? Would it be throwing an exception in both Integrated and Classic modes in the same case?
Following exceptions can be thrown when client is disconnected while flushing, but Classic mode one seems to be somehow intermittent:
An error occurred while communicating with the remote host. The error code is 0x80070057.: at System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6.FlushCore(Byte status, Byte header, Int32 keepConnected, Int32 totalBodySize, Int32 numBodyFragments, IntPtr bodyFragments, Int32 bodyFragmentLengths, Int32 doneWithSession, Int32 finalStatus, Boolean& async) at System.Web.Hosting.ISAPIWorkerRequest.FlushCachedResponse(Boolean isFinal) at System.Web.Hosting.ISAPIWorkerRequest.FlushResponse(Boolean finalFlush) at System.Web.HttpResponse.Flush(Boolean finalFlush) at System.Web.HttpResponse.Flush() at ASP.default_aspx.Page_Load(Object sender, EventArgs e)The remote host closed the connection. The error code is 0x80070057.: at System.Web.Hosting.IIS7WorkerRequest.RaiseCommunicationError(Int32 result, Boolean throwOnDisconnect) at System.Web.Hosting.IIS7WorkerRequest.ExplicitFlush() at System.Web.HttpResponse.Flush(Boolean finalFlush) at System.Web.HttpResponse.Flush() at ASP.default_aspx.Page_Load(Object sender, EventArgs e)
Dec 15, 2008 03:53 PM|LINK
In both Classic and Integrated mode, ASP.NET will throw an exception if the client closes the connection during or before an
explicit flush. An explicit flush means that someone called HttpResponse.Flush. This has been the behavior in classic mode for a long time, and so integrated mode does the same.