New answer, powershell

TCP

Get-Process -Id (Get-NetTCPConnection -LocalPort YourPortNumberHere).OwningProcess

UDP

Get-Process -Id (Get-NetUDPEndpoint -LocalPort YourPortNumberHere).OwningProcess

Old answer, cmd

 C:\> netstat -a -b

(Add -n to stop it trying to resolve hostnames, which will make it a lot faster.)

Note Dane's recommendation for TCPView. It looks very useful!

-a Displays all connections and listening ports.

-b Displays the executable involved in creating each connection or listening port. In some cases well-known executables host multiple independent components, and in these cases the sequence of components involved in creating the connection or listening port is displayed. In this case the executable name is in [] at the bottom, on top is the component it called, and so forth until TCP/IP was reached. Note that this option can be time-consuming and will fail unless you have sufficient permissions.

-n Displays addresses and port numbers in numerical form.

-o Displays the owning process ID associated with each connection.

After testing on more platforms and more approaches, I've basically given up on this functionality (at least for my purposes). The problem for me is that I want to have something that works in 90%+ of the situations, and the reality is that with everything I could come up with, it's closer to 70%. The ironic thing is that it's actually just as flaky through the normal Windows method. For those who still want to go down this perilous path, here's what I found:

Of the API direct methods described above, the one which worked the most consistently was using the SetupAPI (SetupDiSetClassInstallParams) - the biggest problem I ran into with this is that sometimes it would get in a state where it would require a reboot and no changes would work until that happened. The only other thing to be aware of when using this is that there are two profiles for devices, so you need to toggle them both in some cases. The DDK contains the source to the devcon tool, which shows you exactly how to do everything. This ultimately looked like it was the closest to right-clicking, but it still exhibited some strange behavior that Network Connections didn't. This approach seemed to work about 70% of the time (in both tests and on test systems).

From the total hack approach, the best I found was not using the technique that ToggleNIC did, but instead use the IShellFolder stuff - this allows you to use GetCommandString which is language-independent. The problem with this is that under XP GetCommandString doesn't return anything (oh joy), but it did appear that the menu ID's for 'enable' and 'disable' were consistent (16 and 17 respectively), so if I failed to GetCommandString, I just fell back to the menu ID's. To Toggle, just call InvokeCommand with either the string if it returned one, or the menu ID if it didn't. The problem with this was that just like the normal Windows way, sometimes it doesn't work, nor does it give you any indication of what's going on or why it failed. This approach seemed to work about 70% of the time as well, but was much harder to tell if something went wrong, plus the normal "Enabling interface..." text would pop up.

Hopefully this helps anyone else - and if anyone manages to find another way that works in more situations, I'd love to hear it!