GetBestRoute bug in Windows 10 Anniversary Release 1607

After upgrading to Windows 10 Anniversary Release 1607 on August 6, 2016, I noticed something strange happening with ARP Scanning Tool and I traced it to an intermittent problem in the IpHlpApi function GetBestRoute.

When the computer is first booted, GetBestRoute works normally as it has in NetScanTools Pro for years and as it has on other Windows operating systems. I am using it to determine if an IPv4 address can be reached LOCALLY without going through the Default Gateway. Operating System specifics:  64 bit OS build 14393.51, only one ethernet wired 1GB network interface connected to an IPv4 network. Compiled as a 32 bit application using VC++ 2012.

Code snippet:

MIB_IPFORWARDROW IPForwardRow;
memset(&IPForwardRow, 0, sizeof(IPForwardRow));

DWORD dwResult = GetBestRoute(targetIPAddress, outgoingIf, &IPForwardRow);

// note the fail on getting non-local route

if(dwResult == NO_ERROR && IPForwardRow.dwForwardType != MIB_IPROUTE_TYPE_DIRECT)

{

 // note the failure with a popup stating that the route is not local,

 // ie. not on the same subnet or local network segment

}

Problem statement: if you pass in ANY targetIPAddress between 192.168.0.1 and 192.168.0.254 and outgoing interface is 192.168.0.205 on your computer, it should come back with MIB_IPROUTE_TYPE_DIRECT. This is the normal way it works. Here is a view of the contents of the IPForwardRow structure as it should appear with 192.168.0.1 and 192.168.0.205 as the interface (192.168.0.1 is the default gateway).

You can see the dwForwardDest is populate correctly as is dwForwardMask and the ForwardType is direct as expected.

But for any other IPv4 address 192.168.0.2 through 192.168.0.254, you get this with empty dwForwardDest and dwForwardMask with the route type INCORRECTLY shown as MIB_IPROUTE_TYPE_INDIRECT.

Obviously something was broken in this new Windows 10 release. It is intermittent but once it goes into this failure mode, it stays in the failure mode until the computer is rebooted. I do not know what the trigger is.

I have fixed it by writing my own GetBestRoute equivalent - but I should not have to do that. Microsoft PLEASE FIX this ASAP!