locked
Trying to fix 'The underlying connection was closed: An unexpected error occurred on a send.' RRS feed

  • Question

  • Hi,

    I've been seeing this error intermittently on our Windows 2003 servers while running web services under the 1.1 framework.  The setup is fairly simple, the client is a windows service and it makes a number of requests to a web service throughout the day.  Requests are authenticated using NTLM (Negotiate) and respond fairly quickly (less than a second).  Occasionally though, the exception The underlying connection was closed: An unexpected error occurred on a send. is thrown.

    I'm fairly certain its not a hardware fault as only this particular application (which is the only application using web services) is having problems.  Having searched the internet it seems to be a common problem, that may possibly be fixed by removing keepalives - however, it also seems this is not an option when using NTLM authentication.

    Before I start hacking code and implementing dodgy work arounds, I was hoping there was a patch for the 1.1 framework that resolves the issue.  At the very least I was hoping to have a better understanding as to why this exception is being generated intermittently.

    Can anyone help?

     

    Thursday, December 29, 2005 1:35 AM

Answers

  • Here is a link to a blog written by one of the msft support engineers that works with companies to diagnose these kinds of failures.

    http://blogs.msdn.com/engelsr/articles/497902.aspx

     

    The most common cause of this error is exactly as you describe.  The connection is closed but the client doesn't know that it has been closed.  It then tries to use the connection but it blows up.  SP1 for v1.1 of the .NET framework includes an important fix that helps with this type of error but you should still make sure that you have your client and server configured in such a way to limit your exposure to this type of problem.  The most important/helpful setting for most people that run into this problem is that the client needs to set its "Max Idle timeout" to be something LESS than the connection idle timeout set on the server.

    What does this mean?  The server will automatically close the connection after N seconds.  The client should be configured to dispose of any connection that is idle for some small amount of time less than N.  For example: if the server is set to close idle connections after 120 seconds, then I would suggest that the client not use the connection after 100 seconds.  This can be done by following the instructions mentioned in point #4 in the above mentioned blog.

    Hope this helps.

    Tuesday, January 3, 2006 5:38 PM
    Moderator

All replies

  • I am not sure I can "Help" but I can comment a bit.

    Yes it is a Pain in the @#$@^%

    I get it on Recive side more than on send.

    one item is that HTTP expects a client to only open 2 connections.

    you can modify that in the web.config and it *might* help.

    the keep alive setting can help but can also break things as you have seen.

    I am strting to think that we need a general wrapper on web service proxy's that traps

    this stuff and does some limited attempts at handling this.

    here is my take on what happens:

    the client thinks that the server has a connection ready for it...

    but the server is busy and has kiled the connection.

    the client tries to use the connection -- gets a SOckets error and throws an expetion.

    what should happen (IMHO) is that the client should watch for this and try to create a new connection and trash the old one.

    if that fails then throw an expection up to the app.

    seems like it should be simple to do that -- but can we get the .net tools to make that happen automaticaly ??

    I'd love to chat with a MSFT dev about this and see if my idea is right or wrong.

    Thursday, December 29, 2005 11:44 PM
  • Hello,

    Your analysis of the issue is generally correct.  The server has closed the connection for some reason, such as a connection timeout.  The Windows Networking team should be able to help out with this issue.  I'm moving this thread to the web forum that they monitor.

    Daniel Roth

     

    Tuesday, January 3, 2006 3:42 AM
    Moderator
  • Here is a link to a blog written by one of the msft support engineers that works with companies to diagnose these kinds of failures.

    http://blogs.msdn.com/engelsr/articles/497902.aspx

     

    The most common cause of this error is exactly as you describe.  The connection is closed but the client doesn't know that it has been closed.  It then tries to use the connection but it blows up.  SP1 for v1.1 of the .NET framework includes an important fix that helps with this type of error but you should still make sure that you have your client and server configured in such a way to limit your exposure to this type of problem.  The most important/helpful setting for most people that run into this problem is that the client needs to set its "Max Idle timeout" to be something LESS than the connection idle timeout set on the server.

    What does this mean?  The server will automatically close the connection after N seconds.  The client should be configured to dispose of any connection that is idle for some small amount of time less than N.  For example: if the server is set to close idle connections after 120 seconds, then I would suggest that the client not use the connection after 100 seconds.  This can be done by following the instructions mentioned in point #4 in the above mentioned blog.

    Hope this helps.

    Tuesday, January 3, 2006 5:38 PM
    Moderator
  • SSRS 2008 Report Builder 2.0

    I'm also getting:  The underlying connection was closed: An unexpected error occurred on a send.

    When trying to deploy my report model through visual basic

    I'm running version 9.0.30729.1 SP .net 3.5 sp1 and doing this locally on the server. 
    Friday, January 8, 2010 5:05 AM
  • I have a similar problem.  I can deploy locally fine but receive an error deploying to a remote server.  Other users can deploy to the same remote server OK, however I am running Windows 7 where they are on Vista/XP.

    Wednesday, June 2, 2010 9:56 PM
  • Try running as "Administrator" and see if that works for you.

    also make sure you're Windows 7 account has access to the report server. you might need to run as.

    Google RunAS.exe to get more help on that.

    Wednesday, June 2, 2010 10:13 PM
  • Hi Edgar,

    Thanks for your suggestion.

    Coincidentally I tried Running as "Administrator" just before receiving your suggestion but received the same error "The underlying connection was closed: An unexpected error occurred on a send" you experienced.  I also tried changing my local username/password to one that matches an administrative account on the server but received the same error.

    I can upload a new model by browsing to Report Manager in IE and simply uploading it as a .smdl file, but just can't do it from BIDS.

    I encountered a similar issue in Report Builder 2.0 when trying to save some reports back to the server - small .rdl report files worked, larger report files received a similar error.

    I'm using HTTPS and basic authentication on the server.  I know there are some OS-specific issus around Kerberos and AES which may exhibit depending on the size of the file you're trying to transmit, however because I'm using Basic Auth on the Report Server I believed wouldn't be exposed to this.

    On a slightly related note, I'm getting errors checking files into SharePoint (different server, not controlled by us) using the Office 2007 Sharepoint integration, however if I do the same thing and upload files via the browser it works OK, it's just frustrating and clumsy.  It's almost as though my machine has a problem transmitting files via SSL Web Services at the application/OS level but an HTTP file upload through the browser work fine through SSL.

    Have also tried disabling my NOD32 virus checker and firewall to see if they are interfering but no luck.

    Michael

    Wednesday, June 2, 2010 10:38 PM
  • Try pointing your visual studio via plain http (not https) and see if that works.

     

    Thursday, June 3, 2010 12:13 AM
  • We have multiple SSRS instances in this server the one I am having trouble with has the setting SecureConnectionLevel set to 3 in rsreportserver.config which would prevent upload via plain HTTP.

    I tried deploying via HTTP to a different instance on the same machine which as SecureConnectionLevel set to 0 and deployment of the same model worked.  So it seems to be related to the use of SSL.

    I also stumbled across this posting which looks promising:

    http://stackoverflow.com/questions/2238494/cant-deploy-or-upload-large-ssrs-2008-report-from-vs-or-ie

    [Pause for some testing]

    Hmm, actually I might forget that.  My symptoms are a little different - the registry setting discussed here allows you to extend the max bytes - this guy was having trouble only with large (e.g. 100kb) files irrespective of upload via IE or BIDS.  I have just tested with a small file (1kb) and I still get the same error, whereas I have always been able to upload fine from IE irrespective of file size.

    Michael

    • Edited by michael12345 Thursday, June 3, 2010 10:22 PM Update after some more testing
    Thursday, June 3, 2010 10:06 PM
  • try - this http://support.microsoft.com/default.aspx?scid=kb%3bEN-US%3b956158

    see if this helps you.  at this point, it's definitely your cert. make sure the sll cert is valid, trusted and the URL you're using the one in report manager and ssrs reportserver config files as well.

     

    Friday, June 4, 2010 9:11 PM
  • I found the solution to my problem here:

    http://stackoverflow.com/questions/2238494/cant-deploy-or-upload-large-ssrs-2008-report-from-vs-or-ie

     

    I modified the registry setting:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\ MaxRequestBytes

     

    And set it to a high-ish number, e.g. 5242880 (5 megabytes).  I originally thought it was an issue connecting from a Windows 7 client only, however I now think it was just coincidence that I was attempting to deploy smaller files from Vista but only struck this issue trying to deploy larger files from Windows 7.

     

    Michael

     

     

    Friday, July 23, 2010 3:43 AM