Given that you clearly have repo cases with your 'specific’ applications, have you tried looking at the import tables in the PE to see which socket functions they call versus the other applications that work as you expect?
I don’t know anything about TDI except what the acronym stands for, but clearly your port tracking routine is missing some code path from applications to lower levels or has some other flaw in tracking port allocations.
Sent from Surface Pro
From: xxxxx@gmail.com
Sent: Thursday, April 24, 2014 8:12 AM
To: Windows System Software Devs Interest List
Hi,
I’m maintaining a TDI filter driver whose purpose is to assign source ports of connections within special per-user port ranges.
My TDI filter driver is intercepting IRP_MJ_CREATE requests, and assigning the source port of each opened TCP/UDP connection according to my needs. The driver is internally maintaining a table with the connections (including socket open/close and TCP grace-period/time-wait), but I still see rare cases where the driver has incorrect information regarding availability of specific ports (maybe because certain notifications are not caught be the driver), causing issues where the driver assigns a used TCP port to user processes, resulting in connection drops.
I improved the situation by calling from my user mode process GetTcpTable once in a few minutes and updating the driver internal tables accordingly, but it is still happens that I still miss a few ports and get a drop (only happens with very specific applications).
Do you know an efficient way to check for port availability before I assign it? Another approach that might overcome it?
Thanks
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer