Differences how Firefox, Cygwin and Python access the Windows 7 networking stack?

The Question

I am not sure about the exact terminology here, but it seems like there are fundamental differences in how the following programs access the Windows 7 network stack:

Group 1:

• Firefox


• Cygwin (XWin Server)


• Internet Explorer


• ping google.com

Group 2:

• Python (urllib2)


• Network drives (Samba shares)


• VNC Viewer


• curl http://example.com/


• ping machine.on.the.intranet


• Oracle VirtualBox guest operating system

Are these groups using different APIs or drivers? If one of the groups stops being able to access the network but the other one doesn't, which network component might be the culprit (or could it be something entirely unrelated)?

Why I am asking

As you might have guessed, I have a strange networking problem. I think it started after receiving some Windows updates and manifests itself in the following way:

1. After (re-) starting Windows, all programs operate just fine, at least for a while. This while is not a fixed time-delta, sometimes hours, sometimes minutes.


2. At some point, Group 1 stops operating as they should, i.e. Firefox and Internet Explorer can't access any websites (neither on the intranet nor the internet) any more, Cygwin (XWin Server) can't open new xterm windows (for which I believe it is trying to open at least one new [local] TCP connection). At the same time my network drives work fine, I can nslookup domains and ping machines on the intranet and my little Python script fetching the http://www.example.com/ website through urllib2.urlopen still works like a charm.

Given all that, I think there must be a specific component in the Windows network stack which the Group 1 programs rely on and which breaks/crashes/freezes, leaving the Group 2 programs unaffected.

Any clues which component that might be would be appreciated - or any suggestions where to go from here, for that matter.

Update 2 Mar 2015

The internet is accessed through a proxy server. I tried setting the proxy in Firefox manually, as well as "Use system proxy settings": it didn't make any difference (still can't access the web once the network stack "breaks").

I also noticed that pings to machines on the internet are also affected, while pings to machines on the intranet are not. So that probably rules out differences in the API and rather points towards a particular component in the Windows 7 network stack misbehaving.

When the network is in the "broken" state, my Ubuntu guest in VirtualBox is able to access the internet just fine through its "bridged adapter" (on a different IP address) - in fact, that is where I am writing this very update from.