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.
<div mce_keep="true">The errors are getting reported back to the asp.net application and being notified to the admin. It is just http and not https but I am not sure which layer they are occuring in. </div>
<div mce_keep="true">The event viewer is showing the same exception that I have listed.</div>
<div mce_keep="true">It is not a virtual machine.</div>
<div mce_keep="true">We are connecting to a SQL Server 2005 database and I can't see anything in the logs that point to a problem there.</div>
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
the problem.
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:
Exception of type 'System.Web.HttpUnhandledException' was thrown.
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)
The I/O operation has been aborted because of either a thread exit or an application request. (Exception from HRESULT: 0x800703E3)
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)
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."
0x80070001
"Incorrect function."
0x80070006
"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.
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.
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)
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.
Jason Hill
29 Posts
The I/O operation has been aborted because of either a thread exit or an application request
Jun 10, 2008 07:46 AM|LINK
Hi,
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.
Thanks,
Jason
Rovastar
3321 Posts
MVP
Moderator
Re: The I/O operation has been aborted because of either a thread exit or an application request
Jun 10, 2008 10:07 AM|LINK
Where are these errors occuring?
http layer? https?
iis layer?
event viewer?
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:
http://forums.asp.net/t/1248261.aspx
Jason Hill
29 Posts
Re: The I/O operation has been aborted because of either a thread exit or an application request
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 the problem.
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:
Exception of type 'System.Web.HttpUnhandledException' was thrown.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)
The I/O operation has been aborted because of either a thread exit or an application request. (Exception from HRESULT: 0x800703E3)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)
tmarq
48 Posts
Re: The I/O operation has been aborted because of either a thread exit or an application request
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."
0x80070001 "Incorrect function."
0x80070006 "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.
Thanks,
Thomas
Jason Hill
29 Posts
Re: The I/O operation has been aborted because of either a thread exit or an application request
Jun 11, 2008 09:30 PM|LINK
Thanks Thomas. Do you know if there is a hotfix available for this?
tmarq
48 Posts
Re: The I/O operation has been aborted because of either a thread exit or an application request
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.
Thanks,
Thomas
Jason Hill
29 Posts
Re: The I/O operation has been aborted because of either a thread exit or an application request
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.
Jason
tmarq
48 Posts
Re: The I/O operation has been aborted because of either a thread exit or an application request
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.
Alexey.UA
1 Post
Re: The I/O operation has been aborted because of either a thread exit or an application request
Dec 15, 2008 02:35 PM|LINK
Hi Thomas,
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:
tmarq
48 Posts
Re: The I/O operation has been aborted because of either a thread exit or an application request
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.
Thank you,
Thomas