Wow, this one should be really easy, but it turns out it's not, thanks to Microsoft's API having an incorrect information return from one of their API functions.

I'm having a programming problem and I'm wondering if anyone on the BBS has seen a solution to this one?

Requirement: Programatically find out which network interfaces on the system (Wired, WiFi, Mobile Broadband, Bluetooth, 1394, whatever) are ENABLED or DISABLED (*not* connected/disconnected which must be ignored in this case, but rather, we need to know enabled or disabled).

In other words, if I'm in the Windows GUI and I run the program:
NCPA.CPL
...which brings up the network adapters control panel, I see a list of network adapters including all of the Wired, Bluetooth, WiFi, Mobile Broadband, and whatnot adapters. I can right-click on any of them and select DISABLE or I can select ENABLE. When one is disabled it is grayed out. In addition to the level of whether they are enabled or disabled, any given one of them can be connected or disconnected (or in the process of connecting).

What I want to know is, regardless of whether they are disconnected or connected, I want to know, from any programming language (DOS script, C, C#, powershell, whatever, but preferably C# because it's what I'm working in right now) which ones are ENABLED or DISABLED. I need a list. That list should be every network adapter on the system, and whether, at the moment I run the function, their current state is ENABLED or DISABLED.

Oh my God, do you have any idea how hard that is? You'd think it's easy. There are a thousand things on the internet saying "oh sure just do this...." Guess what? They're all WRONG because they all harken back to the same WMI interface command, and it's WRONG. IT LIES. Here's what they all boil back down to: Win32_NetworkAdapter class, property: NetEnabled

If you look at the dox for the NetEnabled property it says:

THIS IS A LIE.

It only responds with the adapter's connected state not its enabled/disabled state. For example, if the adapter is enabled, but not connected to the network, this property will return FALSE.

What's interesting is that the Enable and Disable methods indeed disable and enable the adapter as mentioned in the dox above, but the NetEnabled property has nothing to do with that. For example, you can have five network adapters, all of them disconnected (but enabled) and NetEnabled will be "FALSE" for all of them. Run ".Disable" on one of them and it will go gray in the network control panel, but all five will still read NetEnabled="FALSE". Run ".Enable" on the one you disabled, and it will ungray in the network control panel, but it will still read NetEnabled="FALSE" when queried with WMI.

Okay, so how do I work around it? I've tried:

- In .NET in C#, using System.Net.NetworkInformation namespace NetworkInterface class. This can get me a property of "OperationalStatus" which is "Up" or "Down" but again this is useless since it's only "Up" if it's connected.

- The DOS command "netsh interface show interface". This WORKS and shows the correct "Admin State" of the interface as being enabled or disabled. However it's only for wired and Wifi networks, and does not include the other types of networks such as Mobile Broadband, which happens to be hyper-critical for my particular application.

- The DOS command "wmic nic get NetConnectionID". This lists all network adapter names including the disabled ones. No information about disabled/enabled.

- The DOS command "wmic nic get > somelistfile.txt". This lists all network adapters and all their WMI properties to a file. None of the columns in that file indicate disabled/enabled state. There is a column for our old friend NetEnabled which is still lying like a rug, as above.

- Any variations in various languages I've seen all come back down to that WMI "NetEnabled" property. I.e., a lie.

Any ideas? Has anyone run into this before?

No need to go calling it a lie multiple times as if MS is out to get you.

This appears to work in Visual C# 2010 (using .NET 4.0) using the WMI NetEnabled property on my machine. It correctly shows enabled and disabled interfaces and is able to enable and disable them.

http://code.msdn.microsoft.com/windowsapps/Disableenable-network-8112f642

According to the documentation only Vista onwards is supported.

But it *does* lie. I downloaded and ran that example code and it lies like a rug. See the attached screen shot.



Note in the screen shot that my wireless network connection is ENABLED, though it is not connected to anything at the moment. The example code that you linked presents it as DISABLED, which is wrong, as shown in the screen shot.

If I connect it to a wireless network, then the example code presents it as ENABLED. Again, this is wrong. Connected is not the same thing as Enabled. Disconnected is not the same thing as Disabled.

This Microsoft-supplied example code has the same problem as all of the other code I've found on the internet. Exactly as I stated in my original post.

However, the page you linked did say one thing which I hadn't seen yet! This is very interesting:



I will investigate this MSFT_NetAdapter class!!!!!!!!

The MSFT_NetAdapter class is looking very promising:
http://msdn.microsoft.com/en-us/library/hh968170(v=vs.85).aspx

Maybe some of those values ("State" perhaps?) will report what I need them to report.

Hm. Can't get that class to work.

Trying to use the namespace that it's in, I keep getting "Invalid Namespace" errors. I'm trying the example code here and it's not working, keeps erroring out on the GET statement saying that the namespace is wrong.

http://wutils.com/wmi/ROOT/StandardCimv2...NetAdapter.html

Sigh. None of the sample code is working because the namespace is wrong. In all cases in all languages. For example, the simple PowerShell command, typed into powershell, is supposed to work:

Get-WmiObject MSFT_NetAdapter -Namespace root\StandardCimv2

It doesn't, says Invalid Namespace. All the code examples I see on the net say it should work. Why doesn't it work?

Ok I can see the problem now when the wireless adapter is enabled but not connected. I had to delete my access point setup.

MSFT_NetAdapter is Windows 8/Server 2012 and above only. Is that your problem?

BTW: to lie = to intentionally make a false statement

It couldn't be something as dumb as this, could it?

Minimum supported client
Windows 8

Minimum supported server
Windows Server 2012

Namespace
\root\StandardCimv2

MOF
NetAdapterCim.mof

DLL
NetAdapterCim.dll

Naaahh... I didn't thing so.

tanstaafl.

edit: Never mind, I see that Shonky already addressed that.

Having been making lots of false statements lately, playing make-believe with my 4yo daughter, I would add "with intent to deceive" to that definition.

Yep. Damn. I need to be able to reliably detect this on Windows 7 too.



Seems real fucking deliberate to me. I'm really mad at whoever wrote that class right now. From a programmer's point of view, it really is lying. You design the code to a specification, and the docs state the spec. The docs specifically say the spec is "Enable" or "Disable", and yet the underlying code is deliberately reporting something entirely different from the spec.

I'm pretty sure it's because someone else needed that class to report the connected state instead of the enabled state for some other thing somewhere else in Windows. So instead of adding or making use of a different field/parameter, they went the cheap/easy route and changed (deliberately) what the reported value was. They did this without going through the necessary steps of going back in and updating the spec and the docs. Probably because they wanted to avoid the work, overhead, and management red tape involved in doing so. If that's not intentionally lying, then I don't know what is.

None of that matters of course. All it means is that I can't use that Win32_NetworkAdapter class to get the information I need. And the MSFT_NetAdapter won't work on one of my target platforms because it's too new.

So now I need to figure out how to get that information. And I'm stumped.

Somewhere in the Windows API there has to be a way to do it. The "Network Connections" screen is able to reliably show whether or not a given network adapter is disabled by graying it out. So what function is THAT program using to gather that information? That's what I need to find out.

Probably something in the SetupDiXxx family of functions. Good luck with that...

I don't agree with your theory that someone has gone the "cheap/easy route ... without ... updating the spec". Simply a bug. Anyway:

This might help you:

From a command line



Will return disabled network adapters only. My Wifi adapter is not returned regardless of connection as long as it is enabled so seems to do what you want/need. NetEnabled will show the incorrect status you are seeing. Then parse the text output. A bit clunky but workable.



Will give you the full "dump". On my machine there are all sorts of "virtual" interfaces from various devices that have been plugged in over time.

This might work better:



This should only filter in valid network interfaces. Stuff like VPNs should not show. Then, if ConfigManagerErrorCode is 22, the device is disabled.

BRILLIANT!

Yes, in my initial tests, the "ConfigManagerErrorCode" appears to be the correct indicator field.

Thank you!

How did you find that?

Improving that slightly to:



For my purposes, I think filtering on whether or not it's got a name is the correct thing. That gets me the list of everything that's visible in NCPA.CPL regardless of whether it's in the process of trying to connect to a carrier or something.

Final demonstration batch file showing the difference between ConfigManagerErrorCode (correct) and NetEnabled (incorrect). I'm putting this in my "bag of tricks" batch file folder, posting here for posterity. I'm also going to be incorporating the ConfigManagerErrorCode=22 thing into the original C# program that I'm working on.

Thanks again!

You do know about github and gists, right?

I am looking forward to the future post about deja vu when Tony goes Googling to solve this problem and find the answer on this board in his post again

Seriously. If this BBS ever goes dark, there will be a great disturbance in The Force.

I do, but haven't used them. Probably should start.

Some google and some minor work with the wmic command. Glad it worked. Still a bit clunky but if it works well enough then great.

The only clunky part is using the DOS command line WMIC. But that's just an example to demonstrate the field values. For the actual code I was writing, which was in C# and was making WMI queries directly, it wasn't clunky at all.

I already had a C# function that was querying the NetEnabled property and getting the wrong answer. I merely had to change that to querying the ConfigManagerErrorCode property to get the right answer, and I was done. Not clunky at all.

Ah OK. Cool.