Remote host closed the connection error - .Net 2

[Brad]

I have several web apps which download content to client (pdf, tif, etc) by
writing out content in an aspx page. I've recently upgraded these from 1.1
to 2.0....and they all seem to work fine except that every now and then the
apps raise the following error (our apps email us when an error occurs):
==================================
The remote host closed the connection. The error code is 0x80072746.
Stack
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.FlushCachedR esponse(Boolean
isFinal)
at System.Web.Hosting.ISAPIWorkerRequest.FlushRespons e(Boolean finalFlush)
at System.Web.HttpResponse.Flush(Boolean finalFlush)
at System.Web.HttpResponse.Flush()
==================================
Never had this message under 1.1 so my quesiton is: Is this a new type of
"error" under 2.0 that isn't really an error but just telling me the client
closed the browser before the content was sent.....or....is this an error I
need to be noting? If the later what is it telling me and how would I
address it?

Thanks

- Brad

[Steven Cheng[MSFT]]

Hi Brad,

Thank you for posting.

As for the "remote host closed connection exception...", it indicates the
response of the ASP.NET worker thread has been closed due to some certain
internal exception when flushing data out to the response stream. And from
the internal diassemblied code, this error message is a general exception
message and we can not get the detailed cause from it or the related
exception handling code logic.

Based on my experience, there is several possible things can cause the
httprequest connection be closed unexpectedly.

1. when establshing https/ssl connection

2. when upload or flush out large data content cause the request timeout or
exceed the max allowed request length.

For your scenario, #1 is not likely the cause. I'm wondering how often
does the error occur in your converted ASP.NET 2.0 applicaiton. Also, is
the problem occuring when the page is flushing out large data content that
is time consuming? For the ASP.NET request, there is max value setting for
the request length and executiontime, I'm not sure whether your application
or server has ever manualy modified that value in 1.X(in machine.config),
and after converted to 2.0, the application will inherit 2.0's global
configuration which hasn't changed the value accordingly? The
executionTimeout and other httpRuntime related setting are in the following
configuration element:

#httpRuntime Element (ASP.NET Settings Schema)
http://msdn2.microsoft.com/en-us/lib...41(VS.80).aspx

If you are using the Application_Error event to handle the unexpected
exception, you can consider record the page that cause the problem. Thus,
we can check whether the problem occurs on some page which has some common
setting or code logic.

Anyway, since this is a concrete project specific issue, it would be more
helpful if we can generate a simplified page which can reproduce the
behavior.

Regards,

Steven Cheng
Microsoft Online Community Support
==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Brad]

Steven - Thank you for the reply.
1. SSL is not an issue here, using staight http
2. No uploads always when writing a response to the client so request length
would not be an issue (but yes we have modified for some apps that require
it). I am writing out pdf and images, via aspx page, from sources not
direclty accessible by client. The majority are not large enough to to
result in a request timeout, but a few are and even in 1.1 I had changed the
time out, for example <httpRuntime executionTimeout="600" />. I am
capturing the errors in Application_Error, which is how I know about there
errors (our apps use a custom global class which emails full details of
errors, including page, full error and detials about client such as ip,
browser, etc). I know the exact pages where the error occurs but it is not
an error easily reproduced: considering these apps are accessed hundreds of
times a day the total number of errors amoung all of them is fifteen or less
a day.

Brad

"Steven Cheng[MSFT]" <st*****@online.microsoft.com> wrote in message
news:7Q*************@TK2MSFTNGXA01.phx.gbl...
Hi Brad,

Thank you for posting.

As for the "remote host closed connection exception...", it indicates the
response of the ASP.NET worker thread has been closed due to some certain
internal exception when flushing data out to the response stream. And from
the internal diassemblied code, this error message is a general exception
message and we can not get the detailed cause from it or the related
exception handling code logic.

Based on my experience, there is several possible things can cause the
httprequest connection be closed unexpectedly.

1. when establshing https/ssl connection

2. when upload or flush out large data content cause the request timeout or
exceed the max allowed request length.

For your scenario, #1 is not likely the cause. I'm wondering how often
does the error occur in your converted ASP.NET 2.0 applicaiton. Also, is
the problem occuring when the page is flushing out large data content that
is time consuming? For the ASP.NET request, there is max value setting for
the request length and executiontime, I'm not sure whether your application
or server has ever manualy modified that value in 1.X(in machine.config),
and after converted to 2.0, the application will inherit 2.0's global
configuration which hasn't changed the value accordingly? The
executionTimeout and other httpRuntime related setting are in the following
configuration element:

#httpRuntime Element (ASP.NET Settings Schema)
http://msdn2.microsoft.com/en-us/lib...41(VS.80).aspx

If you are using the Application_Error event to handle the unexpected
exception, you can consider record the page that cause the problem. Thus,
we can check whether the problem occurs on some page which has some common
setting or code logic.

Anyway, since this is a concrete project specific issue, it would be more
helpful if we can generate a simplified page which can reproduce the
behavior.

Regards,

Steven Cheng
Microsoft Online Community Support
==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Steven Cheng[MSFT]]

Hi Brad,

Thanks for your response.

So your ASP.NET 2.0 application's configuration has already adjusted the
exectionTimeout also, then that should not be the problem. BTW, is the
<compilation debug="..." /> attribute set to false in your application's
web.config, this is very important for release version application.

Also, I've performed some further check in our internal database and
haven't found any known issue of such behavior, so I think your application
is not suffering a common issue, still likely application or environement
specific. Yes, I agree with you that for such production environment it'll
be hard to create a simple reproduce, especially for this infrequently
occured problem.

So far what I can still get is checking the ASP.NET application's
restarting or the IIS worker process's recycling. It is possible that the
error is due to the worker process or application domain get restarted due
to some certain internal error(e.g high workload....). You can try writing
out some some trace entry in Application_End/Start event to see whether
those exception comes together with applicaiton restart. For IIS worker
process recycle, there should exists entry in system eventlog that we can
check.

Hope this also helps some.

Regards,

Steven Cheng
Microsoft Online Community Support
==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Steven Cheng[MSFT]]

Hey Brad,

How are you doing on this issue? Have you got any further progress or does
my last reply also helps a little? If there is still anything we can do to
help you, please feel free to post here.

Regards,

Steven Cheng
Microsoft Online Community Support
==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Brad]

Thanks for checking. No progress. No recycling or other errors in event
near time of this error. Below is an example of the code from one of the
applications which is getting the error. I still have not been able to
duplicate the error even using the same parameters that the cause the error
for the user. Other thoughts or suggestions are welcome.

Brad
====================
Note: code below is in an aspx devoted to presenting binary content (no
html content in page)
====================
With Current.Response
.ClearContent()
.ClearHeaders()

Select Case fi.Extension.ToLower
Case ".tif", ".tiff"
.ContentType = "image/tiff"
Case ".pdf"
.ContentType = "application/pdf"
End Select

'########################################
Dim fs As FileStream = New FileStream(imageFile, FileMode.Open,
FileAccess.Read)
Try
Dim FileLength As Integer = CType(fs.Length, Integer)
Dim buffer(FileLength) As Byte
fs.Read(buffer, 0, FileLength)
.BinaryWrite(buffer)

Catch ex As Exception
FileError()
Finally
fs.Close()
End Try
'########################################
.Flush()
.Close()
End With


"Steven Cheng[MSFT]" <st*****@online.microsoft.com> wrote in message
news:Wf**************@TK2MSFTNGXA01.phx.gbl...
Hey Brad,

How are you doing on this issue? Have you got any further progress or does
my last reply also helps a little? If there is still anything we can do to
help you, please feel free to post here.

Regards,

Steven Cheng
Microsoft Online Community Support
==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Brad]

I found the problem and have been able to duplicate it successfully. Using
the code below, if page buffering is on (default) and the client browser
closes before the content is flushed the error consistently occurs. I was
able to duplicate this by running in debug, setting a breakpoint at the
flush and closing the browser before stepping through the flush.
Adding Buffer="false" to the Page declaration resolves the error.
With Current.Response
.ClearContent()
.ClearHeaders()

Select Case fi.Extension.ToLower
Case ".tif", ".tiff"
.ContentType = "image/tiff"
Case ".pdf"
.ContentType = "application/pdf"
End Select

'########################################
Dim fs As FileStream = New FileStream(imageFile, FileMode.Open,
FileAccess.Read)
Try
Dim FileLength As Integer = CType(fs.Length, Integer)
Dim buffer(FileLength) As Byte
fs.Read(buffer, 0, FileLength)
.BinaryWrite(buffer)

Catch ex As Exception
FileError()
Finally
fs.Close()
End Try
'########################################
.Flush()
.Close()
End With

"Steven Cheng[MSFT]" <st*****@online.microsoft.com> wrote in message
news:Wf**************@TK2MSFTNGXA01.phx.gbl...
Hey Brad,

How are you doing on this issue? Have you got any further progress or does
my last reply also helps a little? If there is still anything we can do to
help you, please feel free to post here.

Regards,

Steven Cheng
Microsoft Online Community Support
==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Steven Cheng[MSFT]]

Thanks for your followup Brad,

So from the further code you provided, the "connection be closed ..." error
is due to the client close the browser (or maybe client be disposed
expectedly), in such scenario, when the response is buffered, the binary
data is still not sucessfully transfer to client, then the error occurred.
Anyway, I think this is a reasonable behavior when the client stop the
connection expectedly. I used to be afraid that the connection is aborted
due to some server-side error such as application get restarted or process
crashed unexpectedly. That'll be very hard to troubleshoot.

Regards,

Steven Cheng
Microsoft Online Community Support
==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)