locked
Network Protocol driver installation behaviour changed in Windows 10 RRS feed

  • Question

  • Hi,

    At work I’ve taken on the support of a specialist legacy network driver protocol that we produce.

    On Windows 7 and earlier, when adding a new Network Protocol and pointing the OS dialog at our INF file, only one Network Protocol is shown. Selecting this causes two drivers (SYS files) to be installed. The two drivers are required and one has dependencies upon the other.

    On Windows 10 and 2019, the behaviour is different, two Network Protocols are shown and the user has to install both drivers individually.

    Ideally we would like the Windows 10 behaviour to be the same as the Windows 7 experience.

    Anyone have any advice (INF setting?) on getting both drivers to be installed in one go?

    Thanks.


    svoburner

    Tuesday, March 31, 2020 4:51 PM

Answers

  • Ah, okay, thanks, that screenshot clears it up, I think.  I now remember making a change in Windows 10 to that dialog.  In Windows 7, if you arrived at that dialog box by clicking on the Properties of a specific network adapter, then Windows would hide any protocol driver that could not bind to that specific adapter.

    For example, the INFs of most regular Ethernet adapters have an UpperRange of "ndis5".  So if you arrive at that dialog by coming through the properties of one of these Ethernet adapters, the dialog would only show protocol drivers whose LowerRange also contains "ndis5".

    I removed this quirk because it was implemented using a PNP Class Installer (DIF_SELECTDEVICE), and we've deprecated Class Installers in Windows 10.  Unfortunately, there's no replacement for the technology, so we won't be able to change Windows 10 to match the behavior of Windows 7 here.

    However, you don't need the OS to do this filtering for you.  You do have direct control over that dialog box: you can hide any protocol driver from the dialog using an ExcludeFromSelect directive.  Something like

    [ControlFlags]
    ExcludeFromSelect = my_protocol
    

    Note that chkinf.bat is superseded by infverif.exe https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/infverif

    In either case, though, these tools are fairly simple, and will only catch basic errors.  They don't have a detailed understanding about networking-specific INF directives, so they can easily overlook problems there.

    Notify Objects are only allowed to display UI in the INetCfgComponentPropertyUi callbacks; it can lock up the system to attempt to a display UI in other callbacks, like INetCfgComponentSetup::Install.  For example, when the user upgrades from one Windows 10 version to another, the OS reinstalls each driver in the background.  If a driver tries to display UI at that time, the end-user won't be able to see the UI, and installation will just wait forever for user input.  (Recent versions of Windows 10 do have some ability to detect Notify Objects that hang, but the consequence of this is that the driver is simply dropped during OS upgrades.)


    • Marked as answer by svoburner Tuesday, April 21, 2020 4:56 PM
    Wednesday, April 8, 2020 7:52 PM

All replies

  • I don't think we intentionally made changes to the end-user experience here, but there have been a *lot* of under-the-covers changes to how network drivers get installed in the last 10 years.  It's quite possible that there's some quirk here that I had overlooked when overhauling the backend.

    The terminology in the area is a bit confusing.  A "driver" is a single INF file.  It can contain multiple "protocols" (aka "models", although we don't usually use the word "model" with software drivers).  For example, here's an INF that shows a driver with 3 protocols:

    [Manufacturer]
    %ManufacturerName%=Contoso,NTamd64
    
    [Contoso.NTamd64]
    "My cool IPv4 driver"=InstallProtocol1, contoso_protocol1
    "My cool IPv6 driver"=InstallProtocol2, contoso_protocol2
    "My cool IPv8 driver"=InstallProtocol3, contoso_protocol3

    The next bit is the actual files that get laid down on disk.  You can lay down 0 or more files per protocol.  For example, this lays down 2 files when the first protocol is installed:

    [InstallProtocol1]
    CopyFiles = MyCopyFilesSection
    
    [MyCopyFilesSection]
    driver.sys,,,2
    support.sys,,,2

    All this is to say: can you clarify if you have 2 protocols in 1 INF, or 1 protocol with 2 files?

    It might not be possible to install 2 protocols in a single click on Windows 10; I am not aware of an easy way to do that.  But there are some kind of strange interactions with the `coservices` feature, so maybe it's possible.  And, although I would discourage it, you can use a Notify Object to force another protocol to be installed when the first is installed.


    Thursday, April 2, 2020 10:21 PM
  • Hi Jeffrey,
    Thanks for responding.
    I can confirm that we have 1x INF file containing 2x protocols.
    It contains sections for ntx86 and ntamd64 to add to the complexity.
    I’m currently verifying our INF by hand and I have also run it through Chkinf.bat (WinDDK\7600.16385.1 version). I might try a newer version of the tool too.
    We have a Notify Object which pops up 2 dialogs: 1) licence agreement dialog and 2) licence file picker dialog (although this dialog Isn’t being displayed on Win10).

    The following screenshot shows the difference in behaviour between Win7 and Win2019:

    Screen shot comparing Win7 and 2019 network driver install


    svoburner

    Friday, April 3, 2020 2:57 PM
  • Ah, okay, thanks, that screenshot clears it up, I think.  I now remember making a change in Windows 10 to that dialog.  In Windows 7, if you arrived at that dialog box by clicking on the Properties of a specific network adapter, then Windows would hide any protocol driver that could not bind to that specific adapter.

    For example, the INFs of most regular Ethernet adapters have an UpperRange of "ndis5".  So if you arrive at that dialog by coming through the properties of one of these Ethernet adapters, the dialog would only show protocol drivers whose LowerRange also contains "ndis5".

    I removed this quirk because it was implemented using a PNP Class Installer (DIF_SELECTDEVICE), and we've deprecated Class Installers in Windows 10.  Unfortunately, there's no replacement for the technology, so we won't be able to change Windows 10 to match the behavior of Windows 7 here.

    However, you don't need the OS to do this filtering for you.  You do have direct control over that dialog box: you can hide any protocol driver from the dialog using an ExcludeFromSelect directive.  Something like

    [ControlFlags]
    ExcludeFromSelect = my_protocol
    

    Note that chkinf.bat is superseded by infverif.exe https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/infverif

    In either case, though, these tools are fairly simple, and will only catch basic errors.  They don't have a detailed understanding about networking-specific INF directives, so they can easily overlook problems there.

    Notify Objects are only allowed to display UI in the INetCfgComponentPropertyUi callbacks; it can lock up the system to attempt to a display UI in other callbacks, like INetCfgComponentSetup::Install.  For example, when the user upgrades from one Windows 10 version to another, the OS reinstalls each driver in the background.  If a driver tries to display UI at that time, the end-user won't be able to see the UI, and installation will just wait forever for user input.  (Recent versions of Windows 10 do have some ability to detect Notify Objects that hang, but the consequence of this is that the driver is simply dropped during OS upgrades.)


    • Marked as answer by svoburner Tuesday, April 21, 2020 4:56 PM
    Wednesday, April 8, 2020 7:52 PM
  • Hi Jeffrey,

    Thanks for all the helpful advice.

    My current work task is to ‘sort out’ our Notify object to meet the Windows 10 requirements.

    Thanks again.

    svoburner

    Tuesday, April 21, 2020 4:59 PM