Opening the same port too soon results in UDP messages being discarded.

Question

I have a problem that is driving me demented.
I have a PC running XP (or W7, makes no difference) that has a direct Ethernet connection to a DSP (no routers in the way).
After reset, the DSP sends BOOTP packets to the PC as it waits to be loaded.
The PC detects these BOOTP packets using Winpcap.
On receiving a BOOTP, the PC sends a small program to the DSP using UDP.
The PC then opens a socket and reads a UDP packet from a specific port (actually 0xC0C0).
When the DSP starts, it broadcasts an ARP to find the host then sends a UDP packet to port 0xC0C0 on the host.
If I run this, it works.
The PC detects the BOOTP, loads the DSP, which sends the ARP and gets a response, the DSP sends its UDP packet and the PC gets it.
If I immediately reset the DSP and run the PC program again (having closed it down after the previous run), the PC detects the BOOTP, loads the DSP, which sends the ARP and gets a response, and the DSP sents its UDP packet (all verified by Wireshark on the
PC), but the PC program then never sees any incoming packet.
Instead, if I wait a minute or so after a successful run, I can run again without problems (the incoming UDP packet is read correctly).
I have verified that the data being sent in both directions are always the same on every run.
All the Winsock calls on the PC execute with success returns.
It appears that something in Windows is taking a long time (of the order of a minute) to close the socket at the end of a run and, in the meantime, it is absorbing incoming packets and discarding them. This must be happening AFTER Windows has happily opened
the socket for the next run.
As the PC program is shut down between runs, there cannot be any memory of previous runs in the program itself.
It must be something strange happening in Windows.
I have been chasing this problem for a very long time now and I am no closer to a solution.
Any suggestions would be gratefully received.

Answer 1

Hi,
Since we don't know the whole process. Please perform the steps as below.
Disable the 3rd party application or using Clean Boot for test.
Clean Boot
a. Click Start, click Run, type "msconfig" (without the quotation marks) in the Open box, and then click OK.
b. In the Startup tab, click the "Disable All" button.
c. In the Services tab, check the "Hide All Microsoft Services" checkbox, and then click the "Disable All" button.
======================================================
Clean Boot + binary search
In a Clean Boot, all the 3rd party services and startup programs are disabled. If the server can start normally in Clean Boot,
we can be sure that the issue was caused by some 3rd party service or application. And then we can do a "binary search".
You can enable half of all the services in Services tab, and then restart the server to check the result. If the issue reoccurs,
it means the culprit is in this list; if not, the culprit is in the other half. And then, we can continue the binary search,
until we find out the root cause. Please let me know if this action plan is OK for you.
Action Plan:
1.Download Microsoft Network Monitor Tool from the following link and install it on the two machines. 
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f
Gathering the nemon trace for research.
Thanks.
Best regards,
Steven Song
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.