Previous Next

• 06-10-2008, 3:46 AM

  Jason Hill Joined on 04-23-2006, 3:39 AM Sydney, Australia Posts 24

  The I/O operation has been aborted because of either a thread exit or an application request Reply Contact 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

• 06-10-2008, 6:07 AM

  In reply to

  Rovastar Joined on 03-13-2008, 2:00 PM London, UK Posts 743

  Re: The I/O operation has been aborted because of either a thread exit or an application request Reply Contact 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 Most overused word in IT is 'should' as in 'That should work!?!'

• 06-10-2008, 6:48 AM

  In reply to

  Jason Hill Joined on 04-23-2006, 3:39 AM Sydney, Australia Posts 24

  Re: The I/O operation has been aborted because of either a thread exit or an application request Reply Contact Thanks for the response.  Some answers to your questions: 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. The event viewer is showing the same exception that I have listed. It is not a virtual machine. We are connecting to a SQL Server 2005 database and I can't see anything in the logs that point to a problem there. 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)

• 06-10-2008, 5:12 PM

  In reply to

  tmarq Joined on 06-11-2002, 10:44 AM 42 Posts 24

  Re: The I/O operation has been aborted because of either a thread exit or an application request Reply Contact 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

• 06-11-2008, 5:30 PM

  In reply to

  Jason Hill Joined on 04-23-2006, 3:39 AM Sydney, Australia Posts 24	Re: The I/O operation has been aborted because of either a thread exit or an application request Reply Contact Thanks Thomas. Do you know if there is a hotfix available for this?

• 06-11-2008, 5:48 PM

  In reply to

  tmarq Joined on 06-11-2002, 10:44 AM 42 Posts 24

  Re: The I/O operation has been aborted because of either a thread exit or an application request Reply Contact 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

• 07-22-2008, 12:03 AM

  In reply to

  Jason Hill Joined on 04-23-2006, 3:39 AM Sydney, Australia Posts 24	Re: The I/O operation has been aborted because of either a thread exit or an application request Reply Contact Big thanks to Thomas for the awesome customer service and providing a private build which contained the fix for this problem. Jason

• 08-13-2008, 12:39 PM

  In reply to

  tmarq Joined on 06-11-2002, 10:44 AM 42 Posts 24

  Re: The I/O operation has been aborted because of either a thread exit or an application request Reply Contact 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.