January 9, 2008 at 3:48 pm
Has anyone found a solution for this? I'm using Server 2003 and SQL Server 2005 with same prob. The SynAttackProtect=0 did not help either. I'm seeing nothing from SQL Server logs/traces to identify the prob.:w00t:
January 24, 2008 at 10:22 pm
I have just spent weeks trying to figure this problem out. It occurs for my app mostly when attempting an oledb connection. Using SQL Server 2005 or SQL Express or SQL 2000 on either Vista, 2003 with SP2 or on XP with latest service pack. I seems most prevalent when the database machine is busy.
In the end I replaced all my sqlconnection.open statements with a call to a function that performs the open, if it fails with the "General Network Error" it retries... up to 10 times with a second sleep in between.. this has eliminated most of the failures with the connection being established on the second or third time... mostly...
While i appreciate that some or possibly most of you may not be able to change the app I thought it worth mentioning how I got around the problem...well a bit of it anyway
there are still some other failures occurring with the same error but I haven't managed to track these down yet.
January 25, 2008 at 6:31 am
[font="Tahoma"][/font]
Masking the problem is probably not the best way to go. Sure, this modification is working for this application, but now your users are waiting up to 10 seconds for a connection.
In my experience with these connection issue have little to do with the application or SQL Server, but the connectivity between. We've had this occur now for about 5 customers running 2003 Server with SQL 2005. In all 5 cases turning off the network chimney function and updating the NIC drivers has resolved the issue.
I've learned that running the Microsoft default drivers for a NIC is generally not the way to go.
Best of luck to all of you.
Regards, Irish
January 25, 2008 at 2:53 pm
thanks for the update, you are correct, masking the problem is not the best solution and definitely not for an application that needs to be very responsive. However in my case the problem only manifests its self during overnight processing where the load is very heavy. I have turned off the network chimney function this didn't resolve the problem (and would not explain the Vista or XP problems) I don't believe it to be a problem with the NIC as the problem is occurring between a windows service and the database running on the same machine. As a software vendor I needed a solution that would allow my products to work correctly without the customer having to trial and error problem resolution.
I'm still looking for the root cause but as this issue have been around literally for years I'm not hopeful.
January 27, 2008 at 8:43 am
I can confirm that your approach is pretty sound - even if it does not get to the root cause. When I first ran into this problem I had decided to run a script 24/7 to determine the frequency of occurence and the time of day distribution. The script was based on a connection that was always connected and performed a simple 'select 0' every 5 seconds. When the connection got broken it would attempt to reconnect every 5 seconds.
I was never able to find anything meaningful regarding frequency or distribution of broken connections.
But the reconnect eventually always succeeded and always in less than 30 seconds.
So go with it.
February 25, 2008 at 1:27 pm
We struggled with receiving this error for 2-3 weeks after an upgrade to SQL Server 2005, and Windows 2003.
We opened cases with MS and end result was the TCP Chimney OFFLOAD feature was causing the issue. We did NOT have to follow the suggestion to disable SynAttackProtect. Disabling the TCP Chimney OFFLOAD stopped the disconnections.
BELOW IS THE ADVISE WE RECEIVED FROM OUR CASE:
THIS IS THE STEP THAT SOLVED OUR ISSUE: read the KB sited and also refer to KB942861 for more information
Step 2: Disable the TCPchimney setting on the SQL server and application server (in one of the machine where dynamics is running if it is running windows serve 2003) : Windows 2003 SP2 comes inbuilt with a new network scalability pack which is supposed to accelerate the Windows networking stack. But this setting may not be compatible with all the network cards and it could pose connectivity issues as well. For more information you can refer to http://support.microsoft.com/kb/912222
To disable this feature please take the following steps on both the SQL Server and application server.
Open up a command prompt on the machine.
Run the following command: "Netsh int ip set chimney DISABLED"
Change the values of the following registry keys to 0
a. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableRSS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableTCPA
Reboot the machine after the above changes.
==========================================================
Step 1: Disable SynAttackProtect on SQL server: Windows 2003 Sp1 and Sp2 introduces this new feature which monitors processes getting high number of connections and if it detects that too many connections are being made, the connections will be rejected.
1. Click Start, click Run, type regedit , and then click OK.
2. Locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
3. On the Edit menu, point to New, and then click DWORD Value.
4. Type SynAttackProtect , and then press ENTER.
5. On the Edit menu, click Modify.
6. In the Value data box, type 00000000 . Click OK.
7. Quit Registry Editor.
For more information on this we can refer to:
899599 A BizTalk Server Host instance fails, and a "General Network" error is written to the Application log when the BizTalk Server-based server processes a high volume of documents http://support.microsoft.com/default.aspx?scid=kb;EN-US;899599
February 25, 2008 at 2:14 pm
Funny how that works out. I am pleased to hear that the solution I posted was further recommended by M$
I posted that some time ago and it seemed that very few people wished to believe what I posted. I even noted the M$ KB article. :w00t:
Regards, Irish
February 27, 2008 at 8:21 am
Irish,
I also received my answer to the problem from a forum user before MS found the answer. I was posting for help everywhere I could think of. I've wanted to thank him but can't find my way back to his original reply! It's people like you and him that make life easier for the rest of us. I really appreciate it when someone posts a solution to one of the many mystery problems. Thanks.
July 1, 2008 at 3:46 am
For those poor souls still following this problem :
We've found the problems root cause is NDIS 6. It seems TCP chimnney stack implementation by default in Windows updates / service packs has brought bad NDIS 6 support to the surface.
Network adaptors whose drivers do not properly implement the NDIS 6 implementation will cause this problem.
In our particular case, it was when multiple Crystal Reports were executed in a multi-threaded fashion on a database where the machine had a network adaptor that was using an NDIS 6 interface that was buggy (Realtek, case in point).
Solution : use a "quality" network adaptor with the appropriate drivers, and the problem goes away.
I suggest anyone who experiences this problem tries plugging in an Intel network adaptor - into both the client and server, and re-configuring the machines accordingly (ie: install drivers, disable or remove old ones) and giving it a whirl.
If I had of known this in advance, I would have saved 0000's of $ of time, and gladly of recommended our clients spend the few '000's on the hardware.
However, I must again point the finger at Crystal Reports : It's only your crappy components causing this problem (for us, anyway), and given your blatent ignorance of best practices on deployment that has cause me SO MUCH PAIN, you better pray I never end up in the same room as your dev team.
Hell hath no fury like a developer scorned 🙁
July 1, 2008 at 6:43 am
Mike,
Yes, you make a valid point. Using a "quality" Network Interface that implements NDIS 6 correctly may be another approach. However, for the millions of Servers out there running various versions of Windows 2003 and SQL Server 2005 that already have one or more NICs that could be considered "legacy" (i.e. not fully supporting/implementing NDIS 6) this is a good solution.
Most of the folks that I work with are running hardware that is not ancient (less than 5 years old) and are running into this problem. Likely it will go away when they next upgrade their hardware, but until then this disabling TCP Chimney is the way I'm going to go.
Regards, Irish
July 1, 2008 at 6:49 am
Hi all,
I'm curious, my application was getting these issues (I posted a page or so back how I coded around it) It consists of a Windows service talking to SQL Server 2005 (or 2000) on the same hardware platform. How would the state of the Nic or it's drivers affect this situation?
Adrian Heald
Captell Developments
July 10, 2008 at 9:29 pm
Dear All,
How about on Windows 2000? I'm facing the same problem on both Windows 2003 and Windows 2000 with MSSQL 2000 SP4.
Best Regards,
Henry
October 9, 2008 at 5:21 am
We been seeing this problem, both at a client site, and in our development environment - but it only started recently. It does seem more prevelant on the multi-core machines.
In the development environment, we placed the client app on the same machine as the server, and we STILL get the error occasionally - so unless DCOM is using a poorly implemented NDIS 6 within the machine to talk cross-process, I doubt that is our problem.
Of course the highly generic nature of the error message isn't terribly helpful - it covers a multitude of potential sins.
Still, thanks for all the helpful advice - I will now go away and apply them in various patterns to see if I can make the problem go away. Sadly, I don't have a reliable way of reproducing it yet, so I'll struggle to be sure it's gone.
RG
October 9, 2008 at 6:35 am
We been seeing this problem, both at a client site, and in our development environment - but it only started recently. It does seem more prevelant on the multi-core machines.
One of the other items we have found is a problem with AMD Processors. There is a patch available on their site that fixes the issue with a timing loss that gets the processor out of sync with SQL. It has something to do with the Cool'n'Quiet technology.
Check this link and see if this looks like your problem.
http://support.microsoft.com/kb/895980
Regards, Irish
October 9, 2008 at 8:24 am
Jeffrey Irish (10/9/2008)
One of the other items we have found is a problem with AMD Processors. There is a patch available on their site that fixes the issue with a timing loss that gets the processor out of sync with SQL. It has something to do with the Cool'n'Quiet technology.
Thanks.
I checked the machines in question - one is an Intel Core Duo, one a twin Intel Xeon, and another a Pentium 4 (yes, I know ...) So, not AMD in this case.
I'm starting to wonder just how many conditions can trigger this error message.
Cheers,
RG
Viewing 15 posts - 16 through 30 (of 37 total)
You must be logged in to reply to this topic. Login to reply