:)
I missed the part where you followed through on resetting winsock. Likely, nothing interesting to be seen. I was interested in IP/IPSec routing, transports, and proxies. You've tried:
netsh winsock reset
netsh int ip reset reset.log
right?
May as well complete the trifecta:
netsh firewall reset
Then enable logging (advanced tab on the FW dialog) and see what you can see in %systemroot%\Pfirewall.log.
Back to winsock. A system service (hidden, injected, or sitting in plain sight) could be adding to the catalog after reset. Try
netsh winsock show catalog >xsp.txt
An obvious sign would be the presence of something removed by the reset (
check the reset log Edit: no reset log is generated for winsock - use a clean machine's catalog or Google and a fine tooth comb). Resetting winsock removed non-default Layered Service Provider registry keys. Unless one of the third-party repair tools claims to do more they're not going to help.
Sorry about the second one. netdiag is part of the support tools package (on the CD and a free download) but now that I've read all the steps you have and have not taken I see it's pointless.
AU uses BITS. BITS uses HTTP and HTTPS to transfer files. Another tool in the support tools package, bitsadmin.exe, will allow you to create jobs, add files to a job, and monitor progress. There's also a BITS MMC snap-in if you want a GUI but I don't know which editions, if any, have it installed. Never used it.
The presence of successful MS Automatic Update downloads means HTTP transport is working for the Update Agent but I'm fuzzy on the circumstances. Have any of these downloads occurred in Normal mode or were they all in Safe/Clean Boot modes? If I've read what you've reported clearly, ICMP (Ping) and UDP (DNS) seem unaffected.
The next thing that pops into my head is Group Policy restrictions. GPResult.exe might help. Myself, I'd probably have Process Explorer and NetMon running at this point as well as a copious supply of "Admin fuel" aka beer.