Ah, well, that the PNPID is MS_BTHPAN is a very important detail. Yes, that guy is very much special-cased – it’s even special-cased in my head, since when you said “LAN driver”, I unconsciously dismissed the possibility that you’d be replacing *that* driver.
Since I don’t know anything about Bluetooth, I tried enumerating my own miniport with PNPID “BTH\MS_BTHPAN”. It was indeed hidden from ncpa.cpl, largely because the network connections service tries to open a handle to a kernel driver and fire down some internal BTHPAN IOCTLs.
There’s really not much you can do to get an enabled device with Microsoft’s PNPID to show up in ncpa.cpl, short of implementing all our IOCTLs. I guess you should talk to the folks at MSFT who “blessed” your architecture and re-evaluate the approach here. I’m a little bit curious why it needs to be *that* PNPID, but I’ll take your word for it that there’s a good reason.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Saturday, October 30, 2010 8:05 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] LAN driver not shown in Network Connections
A great list of potential options, Jeffrey, thanks a lot for putting it together. Sounds like I am talking to one of my best friends at Microsoft? 
None of these options are applicable to this case though except possibly the INetCfg enumeration (will check that on Monday). I would however be very interested in “some additional hoops” you mention as this driver is indeed a replacement for the BTH\MS_BTHPAN. The issue seems to be clear enough: if I install a generic skeleton root enumerated NDIS 6 Ethernet emulating driver via the BTH\MS_BTHPAN id, it is not displayed in the Network Connections folder. Any random id in the INF works alright on the other hand with no other changes to either the binary or the INF. Note that the driver does not necessarily need to be installed onto its genuine PDO for the failure to be observed: root enumerated device suffers from the same deficiency.
Nice having knowledgeable friends,
-Ilya
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@microsoft.com
Sent: Friday, October 29, 2010 16:52 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] LAN driver not shown in Network Connections
(Why talk to Microsoft when you can enlist the aid of 1000 of your best friends on OSR NTDEV?)
As Dave said, NCF_HIDDEN devices will be hidden (surprise!). Other reasons a device will be hidden from this UI:
- Its INF file doesn’t list the network adapter as having ndis5 or (on Win7)
Flpp4/Flpp6 UpperRange (older OSes had more options here, like the venerable
FDDI)
- Device has a CM_PROB_XXX code (besides merely being CM_PROB_DISABLED)
- Network interface is not properly registered with INetCfg (check that it can be enumerated through INetCfg::EnumComponents)
- Device can’t be enumerated through HrSetupDiGetClassDevs(&GUID_DEVCLASS_NET,
…, DIGCF_PRESENT, …).
There’s also some additional hoops to jump through if you are a WLAN (or more exotically… Bluetooth and IrDA) device-- are you?
I would double-check the NCF_HIDDEN bit since it’s so easy to investigate. Find the property store under
HKLM\SYSTEM\CurrentControlSet\Control\Class{4D36E972-E325-11CE-BFC1-08002BE10318
}<some number> ! Characteristics
and verify that bit 0x0008 is clear. While you’re there, verify that there is a convincing-looking GUID under the REG_SZ value NetCfgInstanceId.
The Network Connections service does not, as far as I know, special-case any PNPIDs. My guess is actually on INetCfg weirdness. But usermode is a scary place, so I really can’t claim that my guesses carry any expertise.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Friday, October 29, 2010 11:42 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] LAN driver not shown in Network Connections
Appreciate a prompt reply, Dave. No, just the NCF_VIRTUAL is listed in Characteristics.
I’ve now isolated the issue to a particular hardware id. If I employ any other id, the connection is properly displayed. This is a replacement for the inbox network driver (blessed by MSFT but that’s a long story) so the use of MSFT id is desirable. That id apparently triggers special processing by the Network Connections service.
Time to talk to MSFT.
Many thanks,
Ilya Faenson
Rockville, MD USA
—
NTDEV is sponsored by OSR
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