Recommended Posts

I just stumpled upon this, a simple entry in the registry that lets you disable the half-open Tcp connection limit :laugh:

It's from an KB article on MS describing how you can enable it on Vista SP2/Win2008 SP2, since it's now by default disabled there.

On Win7, it can be used to disable the half-open Tcp limit :cool:

Simply open regedit and go here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\

There, change the value of "EnableConnectionRateLimiting" to '0' to disable it.

The MS article says you need to reboot after the change, but it seems that with Win7, you don't have to.

Source (Author of Tcp-Z)

MS KB article

I used to patch tcpip.sys in XP but kept hearing conflicting reports about how effective this was. So now in 7 I've left it at the default limit of 10 and I've yet to get any 4226 EventIDs in Event Log. So is it really necessary to mess with the limit after all?

  GreyWolfSC said:
7 doesn't have the limit by default, so the key is unnecessary.

Nonsense. Win7 (*all* builds until 7127!) have the usual limit of 10, as confirmed by Tcp-Z.

Perhaps they'll change that for Rtm, seeing as they disabled it for Vista SP2, but right now, it's still there.

  ak03 said:
I think it is done for torrenting reasons

It's done to stop malware spreading (well, e-mail viruses that spam e-mails)

It doesn't effect torrent speeds (any half open connections over the limit just wait for a second, normal connections don't count)

From the author of TCP-Z

  Quote
Good news from Microsoft!

At May 6, 2009, In this article, Microsoft confirm that:

By default, the half-open TCP connections limit is disabled in Windows Server 2008 with Service Pack 2 (SP2) and in Windows Vista with Service Pack 2 (SP2).

Thank for this, my doubts about RateLimit long time ago has been solved by Microsoft's answer.

Last year, I found a case. In Vista, I can simply modify the value "TcpCreateAndConnectTcbRateLimitDepth" from 1 to 0 in the kernel memory, and then the Half-open TCP connections limit has been removed immediately!

But I am not sure whether this is a safe method. so, in tcp-z, this function never be active. TCP-Z only show this value.

After Vista 16670 and Windows 7 6956, Microsoft strangely set TcpCreateAndConnectTcbRateLimitDepth to 0 in default.

In latterly version of TCP-Z, it will show a lock icon to distinguish these difference.

Now, Microsoft answer: It's safe! and provide a simple modification method by registry.

When you add a registry entry "EnableConnectionRateLimiting", and set to 1 or 0, it will switch TcpCreateAndConnectTcbRateLimitDepth between 1/0 synchronously.

You can see the changes in the graph of TCP-Z.

After TcpCreateAndConnectTcbRateLimitDepth change to 1, Windows will calculate the create rate and do the limitation. In testing you can see the value is limited to 11.

This registry entry only works in Windows Server 2008 with SP2 / Windows Vista with SP2 / Window 7.

It is time to retire for me!

  gregrocker said:
OK, so I add a 32 bit D word registry key "EnableConnectionRateLimiting" set to "0" here: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\

and I no longer need to run the TCP-Z patch?

Yes. (You could still use it if you want the statistics, but there's no *need* to run it anymore with that reg entry)

  gregrocker said:
Will I use a Qword key for my 64 bit machines?

No, always a Dword.

  • 3 weeks later...

Sorry for the bump, but I have to ask, is the reg entry

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableConnectionRateLimiting and then a DWORD entry TcpCreateAndConnectTcbRateLimitDepth with a value of 0,

or is it

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters and a DWORD entry EnableConnectionRateLimiting with a value of 0?

While Im here, anyone knows anything about EventID 4226 - TCP/IP has chosen to restrict the scale factor due to a network condition. This could be related to a problem in a network device and will cause degraded throughput.

Thanks!

  Satchmo Bevins said:
Bob's yer uncle.

I dont know what to make of your answer but I assume that is the correct entry. So thanks, I actually entered the first one but later deleted it because I had two concurent BSODs I assumed were network related. Im gonna try this one and see how it goes.

But I dont understand where "TcpCreateAndConnectTcbRateLimitDepth" fits in all of this...

  Satchmo Bevins said:
Bob's yer uncle.

I wouldn't want to have Microsoft Bob for an uncle :x

http://en.wikipedia.org/wiki/Microsoft_Bob

bobboot.th.gif

Bob had a "scrumptious" dog named Rover :x

bobscrumptious.gif

Even though he was never fed properly and only lived on table scraps, he somehow survived and later plagued XP as a Search Assistant :x

  Naala said:
But I dont understand where "TcpCreateAndConnectTcbRateLimitDepth" fits in all of this...

Simply, it *doesn't* fit.

  Naala said:
I dont know what to make of your answer......

"Bob's yer uncle" - slang for "There ya go", "That's the ticket", "Good to go", and the always popular "That is the correct answer".

:cool:

  Lord Ba said:
I wouldn't want to have Microsoft Bob for an uncle :x

Bite your tongue! :D

  spinning_quirK said:
Yes, he's sure about it, because there is no lock icon at the top right corner of the Vista orb.

http://www.mydigitallife.info/2009/06/07/h...patch-required/

Indeed. It also says so on the Tcp-Z homepage itself that there's no patch required :yes:

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Ah .. lockout for suspicious activity. I bet they uploaded the SanDisk utility detected as malware
    • Microsoft 365 will soon disable outdated authentication protocols for file access by Usama Jawad On a fairly regular basis, Microsoft disables outdated protocols that are used to access its services. In the past few years, the company has deprecated Basic Auth in Exchange Online and cut access to Outlook for third-party apps relying on this protocol. Now, it has decided to get rid of old authentication protocols for file access across Microsoft 365 services. As reported by Bleeping Computer, Microsoft has posted a message on its Microsoft 365 Admin Center. Starting from mid-July 2025, the company will begin disabling legacy authentication protocols used to access files across Microsoft 365 and Office apps, SharePoint, and OneDrive. Essentially, applications or services which use the Relying Party Suite (RPS) or FrontPage Remote Procedure Call (FPRPC) will to perform browser-based authentication to perform open operations on Office files will no longer be able to do so. As expected, this is primarily being done to improve the cybersecurity posture of various services. Microsoft states that RPS can be brute-forced and phished with relative ease as it is fairly outdated. Similarly, FPRPC is typically used for remote web page authoring and it is susceptible to exploitation through various vulnerabilities too. As such, both of these protocols will be disabled by default starting from mid-July 2025, with the rollout of this change targeting completion by August 2025. The Redmond tech giant will update the protocol baseline by default without mandating any licensing changes for customers. In addition, once these modifications are rolled out, Microsoft 365 will require admin consent to get third-party access to files and sites. IT admins can view the guidance available here to configure admin consent workflows. Microsoft says that these changes align with the principles of its Secure Future Initiative (SFI). Earlier today, it announced the rollout of improved security defaults for Windows 365 citing the same reasons too.
    • It does and it can... I took an i3 board and upgraded it to my FX8350... no issues, just put in new drivers over the top that Windows didn't. Not the issue for me, (though I eventually did do a new install from 23H2 to 24H2)... I was on 22H2 at the time. The issue is activation. You may get hit with having to activate again.
  • Recent Achievements

    • First Post
      Fuzz_c earned a badge
      First Post
    • First Post
      TIGOSS earned a badge
      First Post
    • Week One Done
      slackerzz earned a badge
      Week One Done
    • Week One Done
      vivetool earned a badge
      Week One Done
    • Reacting Well
      pnajbar earned a badge
      Reacting Well
  • Popular Contributors

    1. 1
      +primortal
      708
    2. 2
      ATLien_0
      284
    3. 3
      Michael Scrip
      218
    4. 4
      +FloatingFatMan
      197
    5. 5
      Steven P.
      130
  • Tell a friend

    Love Neowin? Tell a friend!