Hi, I have been playing with the netvmini sample in the WDK and was
wondering what’s the easiest way to pass certain parameters from an
installer app (like devcon) such that when the miniport context is
initialized (e.g. in NICAllocAdapter invoked by MPInitializeEx) all
the custom parameters can be configured immediately before
MPInitializeEx returns.
If I have adapter specific parameters in the registry, I am assuming
there is no way for the user mode installer app to configure
per-device properties until the actual adapter installation happens
and the device node, etc. get created by which point protocols may
have started binding on the adapter, correct?
Turns out I can invoke SetupDiCreateDevRegKey after the call to
SetupDiCallClassInstaller (in the installer) and get registry keys and
values created and reflected in the software keys that
NdisReadConfigurationEx can pick up during adapter initialization. Let
me know if there is anything wrong with this or if there is a better
approach.
I am also curious if getting configuration data through
NdisReadConfigurationEx is the most common mechanism for miniports
(and other NDIS) drivers to get device-specific configuration data.
Why are the hardware keys (under Enum*\Net*\Device Parameters) not
used?
Thanks!
On Mon, Sep 24, 2012 at 8:22 PM, Puchu Pachok wrote: > Hi, I have been playing with the netvmini sample in the WDK and was > wondering what’s the easiest way to pass certain parameters from an > installer app (like devcon) such that when the miniport context is > initialized (e.g. in NICAllocAdapter invoked by MPInitializeEx) all > the custom parameters can be configured immediately before > MPInitializeEx returns. > > If I have adapter specific parameters in the registry, I am assuming > there is no way for the user mode installer app to configure > per-device properties until the actual adapter installation happens > and the device node, etc. get created by which point protocols may > have started binding on the adapter, correct? > > Thanks!
The expectation is that installer apps use INetCfgComponent::OpenParamKey to modify NIC configuration. I’m not
I am also curious if … NdisReadConfigurationEx is the most common mechanism …
Yes. I’m not a logo-lawyer, but I believe that between Device.Network.LAN.Base.NDISCalls and Device.Network.LAN.Base.AdvProperties, you are essentially required you to use that API, instead of some Rtl*Registry or Zw*Key routine. This helps us add new features and improve existing ones. For example, during Windows 8, we found several compatibility issues with the new PowerShell cmdlet Get-NetAdapterAdvancedProperty. Some drivers had been doing strange things with the advanced property keywords. You don’t want to attract that kind of attention from us
So the bottom line is that NDIS drivers should use Ndis*Configuration APIs to access their settings.
(Protocols and filters may choose to use non-NDIS APIs for non-networking things. For example, if your IDS filter is pulling in malware signatures from a shared database, you wouldn’t be expected to write an NDIS version of your database-reading code.)
