Hi there,
I am wondering if anyone knows a good way to hide and un-hide a driver, I’m using a ndis miniport built off of the netvmini example and would like to be able to hide and un-hide it when given a command from the user space. Windows has lots of hidden network adapters (device manager -> show hidden devices) so it should be possible.
The WDK documentation at https://msdn.microsoft.com/en-us/library/windows/hardware/ff547032(v=vs.85).aspx has three options:
Create a custom Install Class - I haven’t tried this option yet partly because I’m new to the inf files and it looks a bit complicated but also it seems like this approach will just permanently hide it on install. Is that correct?
Use the IoInvalidateDeviceState function to trigger an IRP_MN_QUERY_PNP_DEVICE_STATE irp - This failed for my with bugchecks saying that:
“PNP_DETECTED_FATAL_ERROR (ca)
PnP encountered a severe error, either as a result of a problem in a driver or
a problem in PnP itself. The first argument describes the nature of the
problem, the second argument is the address of the PDO. The other arguments
vary depending on argument 1.
Arguments:
Arg1: 0000000000000002, Invalid PDO
An API which requires a PDO has been called with either an FDO,
a PDO which hasn’t been initialized yet (returned to PnP in a
QueryDeviceRelation/BusRelations), or some random piece of
memory.
Arg2: fffffa8001fe4780, Purported PDO.
Arg3: 0000000000000000, Driver object.
Arg4: 0000000000000000”
As such I’m not sure this path will work for my driver, it seems like you have to have a specific device object for this. Is there another way I could trigger this IRP or adjust this setting?
or Use ACPI BIOS methods - The documentation doesn’t specify how to do this at all though and it looks quite complicated. Do I have to implement something in the driver before calling them? Will it work on different windowsie?
I didn’t think this would be such a complicated thing. Any advice?
Thanks,
Graeme
xxxxx@hotmail.com wrote:
I am wondering if anyone knows a good way to hide and un-hide a driver, I’m using a ndis miniport built off of the netvmini example and would like to be able to hide and un-hide it when given a command from the user space. Windows has lots of hidden network adapters (device manager -> show hidden devices) so it should be possible.
That doesn’t hide and unhide a driver, it hides and unhides a device.
You want the “NoDisplayInUI” bit in the DEVICE_CAPABILITIES structure,
but you can’t manipulate that bit on the fly for an existing device:
http://www.osronline.com/showThread.CFM?link=117796
You’d have to disable and re-enable the device, and alter the structure
on the way through. Hardly worth the trouble.
Why not just kill the device instead of hiding it?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Sorry yes, hide the device. In my case the network adapter.
I was looking for similar functionality to a com port, for example my adapter is up and running while my users need it and then when they don’t it can just hide. I don’t really want to kill it because then they have to reinstall it every time they need it again, not a big deal but a bit slower.
So it could be possible to disable - hide - re-enable then later disable - un-hide - re-enable? The post you’ve seems to say that I can’t even do that?
xxxxx@hotmail.com wrote:
Sorry yes, hide the device. In my case the network adapter.
I was looking for similar functionality to a com port, for example my adapter is up and running while my users need it and then when they don’t it can just hide. I don’t really want to kill it because then they have to reinstall it every time they need it again, not a big deal but a bit slower.
It shouldn’t take any time at all. How are you creating/installing the
device now? If you look at the “toaster” sample, you’ll see a very
simple bus driver that creates and removes child devices at the behest
of a user-mode application. You just need the same concept. I’m not a
network guy, but it looks like the netvmini sample in the Win 7 WDK
expects to be used that way: the INF matches one of the toaster bus
created device IDs.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi there,
I am wondering if anyone knows a good way to hide and un-hide a driver, I’m using a ndis miniport built off of the netvmini example and would like to be able to hide and un-hide it when given a command from the user space. Windows has lots of hidden network adapters (device manager - show hidden devices) so it should be possible.
The WDK documentation at https://msdn.microsoft.com/en-us/library/windows/hardware/ff547032(v=vs.85).aspx has three options:
Create a custom Install Class - I haven’t tried this option yet partly because I’m new to the inf files and it looks a bit complicated but also it seems like this approach will just permanently hide it on install. Is that correct?
Use the IoInvalidateDeviceState function to trigger an IRP_MN_QUERY_PNP_DEVICE_STATE irp - This failed for my with bugchecks saying that:
“PNP_DETECTED_FATAL_ERROR (ca)
PnP encountered a severe error, either as a result of a problem in a driver or
a problem in PnP itself. The first argument describes the nature of the
problem, the second argument is the address of the PDO. The other arguments
vary depending on argument 1.
Arguments:
Arg1: 0000000000000002, Invalid PDO
An API which requires a PDO has been called with either an FDO,
a PDO which hasn’t been initialized yet (returned to PnP in a
QueryDeviceRelation/BusRelations), or some random piece of
memory.
Arg2: fffffa8001fe4780, Purported PDO.
Arg3: 0000000000000000, Driver object.
Arg4: 0000000000000000”
As such I’m not sure this path will work for my driver, it seems like you have to have a specific device object for this. Is there another way I could trigger this IRP or adjust this setting?
or Use ACPI BIOS methods - The documentation doesn’t specify how to do this at all though and it looks quite complicated. Do I have to implement something in the driver before calling them? Will it work on different windowsie?
I didn’t think this would be such a complicated thing. Any advice?
Thanks,
Graeme
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
> I know of at least one Virtual Adapter solution that modifies this flag bit at run-time
And boy, does that cause us problems. Please don’t modify this flag at runtime. There’s no API to modify NetCfg Characteristics. The app (if we’re talking about the same app) instead writes to our registry keys. That doesn’t work at all on Windows 8.1 RTM or earlier, sort of works on Windows 8.1 if you get a special QFE, and doesn’t really work very well on Windows 10. The point is, it’s flaky, because we never intended this to work. We were forced to make it work by this app, so we got it working in just exactly the scenarios that the app uses. In general, though, it’s hard for the OS to notice that you went and scribbled on one of its registry keys; there’s no notification for us to trigger off of, so some of the caches are stale.
In general, there’s not a supported way to make a NIC hide and unhide itself on the fly.
First, ask yourself if you *really* need this feature. When you hide the NIC, users can’t configure it. This can be obnoxious. For example, suppose the NIC appears, and the user sets a static IP address of 192.168.1.2 on it. Then the NIC goes hidden. Now the user can’t (easily) un-set the static IP address. If the user tries to use that same address on another network interface, they’ll get a “address already assigned” error, but there won’t be a clear way to un-set it. As far as I can tell, the only reason to hide it is cosmetic, so you’re trading a cosmetic issue for a functional one, which doesn’t seem like a good trade.
If you do *really* want this feature, the most supported way to get it is to write your own bus driver. Have the bus enumerate the NIC when you want the NIC to show up in the UI, and don’t enumerate it when you don’t want the NIC to show up in the UI. This technique might be tedious to implement, but it’s fairly well-understood. It also still falls victim to the “address already assigned” problem above; you’re not escaping that.
> And boy, does that cause us problems. Please don’t modify this flag at runtime.
So noted.
If you do *really* want this feature, the most supported way to get it is to write your own bus driver.
Have the bus enumerate the NIC when you want the NIC to show up in the UI, and don’t enumerate
it when you don’t want the NIC to show up in the UI.
I know Mr. Tippet know this but the NCF_HIDDEN has the effect of keeping the adapter out of the NCPA (Adapter folder) even when the Adapter is enumerated and active which is slightly different than not having it show up when ‘not in use’ (unplugged).
IIRC responding to IRP_MN_QUERY_CAPABILITIES at the bus driver with Parameters.DeviceCapabilities.NoDisplayInUI set to TRUE did not have the desired effect of having the active adapter omitted from all shell UI.
I should have asked what larger problem the OP was trying to solve.
And I guess I need so stop causing trouble for the NDIS team. I’ll work on that!
Cheers,
Dave Cattley
NCF_HIDDEN also has the side effect of setting PNP_DEVICE_DONT_DISPLAY_IN_UI on the device, but only if NCF_HIDDEN is set in the INF (and not whacked in the registry later). So the NetCfg flag is somewhat tied to the PNP flag, although I agree that they’re not quite the same thing.
IIRC responding to IRP_MN_QUERY_CAPABILITIES at the bus driver with Parameters.DeviceCapabilities.NoDisplayInUI set to TRUE did not have the desired effect of having the active adapter omitted from all shell UI.
The way I look at it is that there are two distinct things. There’s a PNP device that shows up in PNP UIs like devmgmt.msc, Get-PnpDevice, etc. There’s a network interface that shows up in networking UIs like ncpa.cpl, Get-NetAdapter, etc. NDIS tightly ties the PNP device to a network interface, so we tend to think of them together, but the two aren’t the same thing. That’s why you need two flags to really truly hide your NIC: the NIC has both a PNP aspect and a networking aspect. (This is obscured by NDIS’s attempt to tie them together; NDIS helpfully sets the PNP flag automatically when it sees that the INF has the networking flag.)
And I guess I need so stop causing trouble for the NDIS team.
Dave, I wasn’t referring to any of your software when I was grousing about an unnamed app that modifies the OS’s registry keys. I wasn’t aware that your brand of trouble included setting this flag!