[dotnet-sdk-9.0.100-preview.4.24253.11] IPInterfaceProperties.GatewayAddresses. FirstOrDefault() returns Null

[Junjun-zhao]

Description

when we run OpenNetMeter app with 9.0.100-preview.5.24227.1 or higher version. It will show error: GatewayAddresses is NULL.

Application Name: OpenNetMeter
OS:Windows 10 21H2
CPU:AMD64
.NET Build Number: dotnet-sdk-9.0.100-preview.5.24227.1

App or source Location checking at: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2049203

Github Link: https://github.com/Ashfaaq18/OpenNetMeter

Reproduction Steps

Test Steps for the Application:

1.Launch app from folder “OpenNetMeter.exe".

Expected Result: Show detailed data service successfully.
Actual Result: App is in Disconnected State, nothing appears.

Minimal Repro steps:(Demo AttachedConsoleApp12.zip)
1)Create .NET Console App
2) Add this code

 NetworkInterface[] adapters = NetworkInterface.GetAllNetworkInterfaces();
 foreach (NetworkInterface n in adapters)
 {
     IPInterfaceProperties adapterProperties = n.GetIPProperties();
     try
     {
       
         Console.WriteLine($"{n.Id} {n.Name} {n.Description} GatewayAddresses is {adapterProperties.GatewayAddresses.FirstOrDefault().Address}");
     }
     catch (System.NullReferenceException)
     {
         //in .NET 9.0.100-preview.5.24227.1, it always come to this line because GatewayAddresses is always NULL
         Console.WriteLine($"{n.Id} {n.Name} {n.Description} GatewayAddresses is NULLL");
     }
 }

3. Build the app and change the runtime to .NET 9.0:

"framework": {
     "name": "Microsoft.NETCore.App",
           "version": "9.0.0-preview.4.24225.8"
   }

4. Run the app .

Expected behavior

App run successfully without error.

Actual behavior

Show error: GatewayAddresses returns NULL

Regression?

Yes

Verify Scenarios:

1). Windows 10 21H2 AMD64 + dotnet-sdk-9.0.100-preview.5.24227.1: Fail
2). Windows 10 21H2 AMD64 + dotnet-sdk-9.0.100-preview.4.24223.3: Pass
3). Windows 10 21H2 AMD64 + dotnet-sdk-8.0.300-win-x64: Pass
4). Windows 10 21H2 AMD64 + dotnet-sdk- 7.0.306-win-x64: Pass
5). Windows 10 21H2 AMD64 + dotnet-sdk-6.0.422-win-x64: Pass
6). Windows 10 21H2 AMD64 + dotnet-sdk-9.0.100-preview.4.24253.11: Fail

Did it work in .NET Framework?
Yes

Known Workarounds

No response

Configuration

dotnet info:

dotnet --info
.NET SDK:
 Version:           9.0.100-preview.5.24227.1
 Commit:            0f7644da23
 Workload version:  9.0.100-manifests.f3024191
 MSBuild version:   17.11.0-preview-24223-07+d542f3a80

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19044
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.100-preview.5.24227.1\

.NET workloads installed:
There are no installed workloads to display.

Host:
  Version:      9.0.0-preview.4.24225.8
  Architecture: x64
  Commit:       74d927967d

.NET SDKs installed:
  9.0.100-preview.5.24227.1 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 9.0.0-preview.4.24223.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 9.0.0-preview.4.24225.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 9.0.0-preview.5.24226.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Other information

Finding:
After debugging the app, we find out that IPInterfaceProperties.GatewayAddresses Property returns NULL, app stays in Disconneted State , in earlier Runtimes, we get value of GatewayAddresses

@dotnet-actwx-bot @dotnet/compat

[stephentoub]

in .NET 9.0.100-preview.5.24227.1, it always come to this line because GatewayAddresses is always NULL

Is it null, or is it empty? With your use of adapterProperties.GatewayAddresses.FirstOrDefault().Address, that will fail with a null reference exception if GatewayAddresses returns null, but it will also fail with a null reference exception if GatewayAddresses returns an empty collection, because the FirstOrDefault() will then return null and you'll dereference that null as part of accessing its Address. And based on a quick look at the implementation, it doesn't look like GatewayAddresses ever returns null.

[wfurt]

This is likely outcome of #100824 cc: @MojtabaTajik
The list will now include more interfaces .... some of them may not have address or gateway.

[Junjun-zhao]

in .NET 9.0.100-preview.5.24227.1, it always come to this line because GatewayAddresses is always NULL

Is it null, or is it empty? With your use of adapterProperties.GatewayAddresses.FirstOrDefault().Address, that will fail with a null reference exception if GatewayAddresses returns null, but it will also fail with a null reference exception if GatewayAddresses returns an empty collection, because the FirstOrDefault() will then return null and you'll dereference that null as part of accessing its Address. And based on a quick look at the implementation, it doesn't look like GatewayAddresses ever returns null.

From .NET 9.0 preview 5 build, adapterProperties.GatewayAddresses.FirstOrDefault() returns null, it is a way that used to return address from App Code. After investigation, we found that adapterProperties.GatewayAddresses is empty.

With dotnet-sdk-9.0.100-preview.4.24223.3 or previous build, it could return the address well.

[Junjun-zhao]

We verified this issue with the latest Preview 4 validation build #dotnet-sdk-9.0.100-preview.4.24253.11, this issue also reproduced.

@stephentoub @wfurt Could you please help confirm if this issue is a blocker for Preview 4? Thanks you.

[wfurt]

From the picture it seems like it is returning empty collection, right? And are both pictures on the same interface? What is corresponding ipconfig /all @Junjun-zhao?

[wfurt]

The code above is problematic IMHO even on 8.0

foreach (NetworkInterface n in NetworkInterface.GetAllNetworkInterfaces())
{
    var ipp = n.GetIPProperties();
    Console.WriteLine("{0}: {1} {2} {3}", n.Name, ipp.GatewayAddresses.Count, ipp.GatewayAddresses.FirstOrDefault(), ipp.GatewayAddresses.FirstOrDefault() == null);
      
}

will produce this output for me

Ethernet 2: 0  True
vEthernet (PUBLIC): 3 System.Net.NetworkInformation.SystemGatewayIPAddressInformation False
Loopback Pseudo-Interface 1: 0  True
Teredo Tunneling Pseudo-Interface: 0  True
vEthernet (Default Switch): 0  True

attempt to dereference GatewayAddresses.FirstOrDefault().Address with produce NRE @Junjun-zhao.
And I think the claim from subject is wrong, it is FirstOrDefault() what return NULL IMHO, not GatewayAddresses

same code on 9.0 (9.0.0-preview.5.24256.1)

Ethernet 2: 0  True
vEthernet (PUBLIC): 0  True
Loopback Pseudo-Interface 1: 0  True
Teredo Tunneling Pseudo-Interface: 0  True
vEthernet (Default Switch): 0  True
vSwitch (Default Switch)-Hyper-V Virtual Switch Extension Filter-0000: 0  True
vEthernet (Default Switch)-WFP Native MAC Layer LightWeight Filter-0000: 0  True
vEthernet (Default Switch)-Npcap Packet Driver (NPCAP)-0000: 0  True
vEthernet (Default Switch)-QoS Packet Scheduler-0000: 0  True
Local Area Connection* 6-WFP Native MAC Layer LightWeight Filter-0000: 0  True
vSwitch (PUBLIC)-Hyper-V Virtual Switch Extension Filter-0000: 0  True
vSwitch (PUBLIC)-Virtual Filtering Platform VMSwitch Extension-0000: 0  True
Ethernet-WFP Native MAC Layer LightWeight Filter-0000: 0  True
Ethernet-Npcap Packet Driver (NPCAP)-0000: 0  True
Ethernet 2-WFP Native MAC Layer LightWeight Filter-0000: 0  True
Ethernet 2-Npcap Packet Driver (NPCAP)-0000: 0  True
Ethernet 2-QoS Packet Scheduler-0000: 0  True
vEthernet (PUBLIC)-WFP Native MAC Layer LightWeight Filter-0000: 0  True
vEthernet (PUBLIC)-Npcap Packet Driver (NPCAP)-0000: 0  True
vEthernet (PUBLIC)-QoS Packet Scheduler-0000: 0  True
vEthernet (PUBLIC)-WFP 802.3 MAC Layer LightWeight Filter-0000: 0  True
Ethernet 2-WFP 802.3 MAC Layer LightWeight Filter-0000: 0  True
Local Area Connection* 6-Npcap Packet Driver (NPCAP)-0000: 0  True
Local Area Connection* 6-QoS Packet Scheduler-0000: 0  True
Local Area Connection* 7-WFP Native MAC Layer LightWeight Filter-0000: 0  True
Local Area Connection* 7-Npcap Packet Driver (NPCAP)-0000: 0  True
Local Area Connection* 7-QoS Packet Scheduler-0000: 0  True
Local Area Connection* 8-WFP Native MAC Layer LightWeight Filter-0000: 0  True
Local Area Connection* 8-Npcap Packet Driver (NPCAP)-0000: 0  True
Local Area Connection* 8-QoS Packet Scheduler-0000: 0  True
vEthernet (Default Switch)-WFP 802.3 MAC Layer LightWeight Filter-0000: 0  True
Ethernet (Kernel Debugger): 0  True
Ethernet: 0  True
vSwitch (Default Switch): 0  True
Local Area Connection* 6: 0  True
Local Area Connection* 7: 0  True
Npcap Loopback Adapter: 0  True
Ethernet 3: 0  True
Local Area Connection* 8: 0  True
vSwitch (PUBLIC): 0  True
Ethernet 4: 0  True
Local Area Connection* 5: 0  True
Microsoft IP-HTTPS Platform Interface: 0  True
6to4 Adapter: 0  True
Local Area Connection* 1: 0  True
Local Area Connection* 2: 0  True
Local Area Connection* 3: 0  True
Local Area Connection* 4: 0  True

That is LOT of interfaces. And some will throw when attempting IPv6 properties (and perhaps more)
While that is not necessarily wrong, I feel that can certainly surprise any app that just leisurely iterate through interfaces and dumps info.

It seems like we made it more difficult to use it (showing all Windows internals) for supporting corner case (e.g. disabled interfaces)

any thoughts on this @stephentoub and @dotnet/ncl ?
I'm also wondering if we can somehow hide at least the internal(?) interfaces @MojtabaTajik.
I tried to eyeball it but I don't see obvious pattern. On the original #89990, do we know if 'ipconfig /all` shows them?

[Junjun-zhao]

attempt to dereference GatewayAddresses.FirstOrDefault().Address with produce NRE @Junjun-zhao.
And I think the claim from subject is wrong, it is FirstOrDefault() what return NULL IMHO, not GatewayAddresses

Yes, you are right. we have updated the title .

And are both pictures on the same interface?

Yes, The both pictures on the same interface.
With dotnet-sdk-9.0.100-preview.4.24223.3 or previous build, FirstOrDefault() could return the address well.
From 9.0 prview5 , the FirstOrDefault() is Null.

What is corresponding ipconfig /all

you can refer to the devdiv bug to get ipconfig details info if you need

[Junjun-zhao]

@wfurt Any update for this issue? The validation window for Preview4 is until 5/16, could you please help confirm whether it is a blocker for .NET 9 Preview4? Thank you very much.

[wfurt]

what is the failing interface @Junjun-zhao? And are other propertied set? Just look at it ion the debugger.

[wfurt]

or at least run the code fragment above and share results here or on the internal issue.

[Junjun-zhao]

Sure. Do you mean this code fragment above mentioned?

foreach (NetworkInterface n in NetworkInterface.GetAllNetworkInterfaces())
{
    var ipp = n.GetIPProperties();
    Console.WriteLine("{0}: {1} {2} {3}", n.Name, ipp.GatewayAddresses.Count, ipp.GatewayAddresses.FirstOrDefault(), ipp.GatewayAddresses.FirstOrDefault() == null);
      
}

[wfurt]

yes.

[Junjun-zhao]

yes.

This is a result we tried with above code fragment on the same machine against .NET 8.0 and .NET 9.0. Please refer to the below picture. In the meantime, we are preparing the repro machine and share it if it is needed for doing more investigation.

[Junjun-zhao]

@wfurt We have updated the repro machine information under Internal bug, please let us know if any more information needed. Thanks.

[Junjun-zhao]

@wfurt Thanks for looking into this issue. Is there any update? This issue also reproduces on the latest dotnet-sdk-9.0.100-preview.6.24274.13.

[wfurt]

we tried to reproduce it with @ManickaP and we could not. Could you share access to your machine or perhaps create Azure VM for investigation? There seems to be something unique in your setup.

[ManickaP]

I was using Win 11 DevBox in Azure. I can share more details about that machine if you want.

[Junjun-zhao]

Thank you @wfurt @ManickaP . We had provided a reproducing machine for you. Please refer to the access info from Internal bug, And You can also share the access info about this Win 11 DevBox machine in the internal bug, we can try to reproduce on it.

[Junjun-zhao]

@wfurt Could you please help confirm which release build will consume this fix? We verified with preview 5 latest build dotnet-sdk-9.0.100-preview.5.24305.12, it is still repro.

[wfurt]

It will be in next public preview 6 for sure. I did look at current daily builds (.version file)

3750ac51619efbbc59bf07d3879758a9c18c4b0e
9.0.0-preview.6.24281.1

that commit is (barely) older than ead1d5c that fix the issue. I have no visibility to when SDK will pick up dated runtime again. But it seems like there is no build yet with the fix.

[Junjun-zhao]

Verified with dotnet-sdk-9.0.100-preview.6.24307.18, this issue has been fixed.