We have a windows 2008 server which makes after startup with 10 seperate processes TCP/IP connections to 10 seperate systems. After about 20 days at the same moment all connections get a problem. It looks as if the TCP/IP stack on low level closes and re-opens the TCP/IP connections without notifying the owner process. Please advice.

Hi sanderM_973, Thanks for posting here. > After about 20 days at the same moment all connections get a problem. What was the problem did we get ? could you please discuss that in detail ? Were these connections still active and have we also monitored any TCP resetting issue by using the utilities like network monitor ?Here is a blog article may help: Where do resets come from? (No, the stork does not bring them.) http://blogs.technet.com/b/networking/archive/2009/08/12/where-do-resets-come-from-no-the-stork-does-not-bring-them.aspx > It looks as if the TCP/IP stack on low level closes and re-opens the TCP/IP connections without notifying the owner process. If we have issue that regard to programing then we may consider getting the most professional responses form the MSDN forum. http://social.msdn.microsoft.com/Forums/en-US/categories Thanks. Tiger LiTiger Li TechNet Community Support

Hello Tiger Li, Our process connects an RTU on TCP/IP level and opens then some session inside it. Inside that session TCP/IP reads and writes are done. So the RTU needs some session context after the TCP/IP connect. After about 20 days we see spontainious a FIN/ACK session followed by a new SYN session. Because our program does not get any error it continues with the reads and writes, but the RTU does not understand it anymore because its session context is lost. Strange enough this happens in the same second for most connections. The few connections without problems are not working for 20 days because the related RTU is restarted. Regards.

Hi SanderM_973, Thanks for your reply. We would like to know if you have any proof to show that the Windows server disconnect the session by sending a FIN/ACK sessions first. And we considered this problem might be probably to the paged pool memory in the Server. So please try the suggestions below: Modify the Registry ================ The following tuning recommendation has been helpful in alleviating the problem: Start Registry Editor (Regedt32.exe).Locate and then click the following key in the registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Management On the Edit menu, click Add Value, and then add the following registry value: Value name: PoolUsageMaximum Data type: REG_DWORD Radix: Decimal Value data: 60 Setting the value at 60 informs the Memory Manager to start the trimming process at 60 percent of PagedPoolMax rather than the default setting of 80 percent. If a threshold of 60 percent is not enough to handle spikes in activity, reduce this setting to 50 percent or 40 percent. Value name: PagedPoolSize Data type: REG_DWORD Radix: Hex Value data: 0xFFFFFFFF Setting PagedPoolSize to 0xFFFFFFFF allocates the maximum paged pool in lieu of other resources to the computer. Caution The 0xFFFFFFFF PagedPoolSize setting is not recommended for use on 32-bit Windows Server 2003-based computers that have 64GB of RAM. This will potentially bring the Free System PTE entry down and can cause continuous reboot of the computer. For this configuration, carefully choose a value based on the requirements and available resources.Quit Registry Editor.Restart the server for the changes to take effect. Performance Monitor ================== At the same time, please enable Performance Monitor to trace the memory and the other resouces usage by following the steps below: a. Click Start and choose Run, and input "perfmon" (without quotation mark). b. On the left pane, expand the "Performance Logs and Alerts" item. Right-click Counter logs and choose New log Settings. c. Specify a name for the log settings and click OK. d. Click the "Add Counters" button. e. In the Performance Object section, please add the following items one by one: - Memory (All counters) - Network Interface (All counters, and All instances) - Physical Disk (All counters and All instances) - Process (All counters, and All instances) - Processor (All counters, and All instances) f. After adding all the objects above, click Close. Then please note down the "Current log file name" content. We need to find the *.blg files with the related name to zip and upload when monitoring is finished. g. On the "Sample data every" section of General tab, please set the time interval to 1800seconds. h. In the Log Files tab, please record the location and file name of the log file. On the Schedule tab, choose Manually in the "Start log" and "Stop log" sections. Click OK. Now on the right pane, we can see the log settings name we have just created. Right-click it and choose Start to record data. i. Please leave it running on the server, when the issue occurs again, then stop the logging and upload the .blg file to us. If anything is unclear about my response, please don't hesitate to let me know. Thanks. Annie

Hi SanderM_973, I would like to know how things are going on your end. If you have any questions or concerns about the recent information I provided, please don't hesitate to let me know. It's my pleasure to be of assistance and I look forward to hearing from you. Best Regards, Annie

Dear Annie, Thank you for the answers. My college that is directly involved with this issue is out of the office and will be back on Monday 20Feb. He will reply you ASAP. Best regards, Sander

Hi Sander, Thanks for your reply. I will wait for your reply on Feb.2rd. Please feel free to let me know if you have anything unclear. Best Regards, Annie

Hello Annie, I have a Wireshark logging at the moment of the problem, only I don't know how to link it to this text. I can send it by e-mail. My e-mail address is henk.koekoek@nl.yokogawa.com. Testing is time consuming. The system with problems is on the other side of Europe and the problem only occurs when the system is running without interruption for 20 days. We are trying to setup an inhouse test, but again we have to wait at least 20 days to see if we can reproduce the problem. Best regards, Henk and Sander

Hello Annie, Its OK to close this session. We first continue testing. Regards, Sander and Henk