Which is the first NDIS routine registered by miniport with NDIS that needs to be called when network device is disabled?

When I try to disable the ethernet device, the device manager hangs and device disable never seems to get disabled.

I see lots of incoming traffic and packets getting indicated from my driver to NDIS.

\windows\inf\setuapi.app.log has the log enclosed below.

Wondering why disable is not going through.. Looking at my device context I dont have any pendings sends to be completed.

Neither is my pause routine getting called. Nor is Ndis close routine getting called. Any what the problem could be?



Regds,




dvi: Using exported function 'NetClassInstaller' in module 'C:\Windows\system32\NetCfgx.dll'.
dvi: Class installer == NetCfgx.dll,NetClassInstaller
dvi: Using exported function 'NciDeviceInstall' in module 'C:\Windows\system32\nci.dll'.
dvi: CoInstaller 1 == nci.dll,NciDeviceInstall
dvi: Using exported function 'WlanDeviceClassCoInstaller' in module 'C:\Windows\system32\wlaninst.dll'.
dvi: CoInstaller 2 == wlaninst.dll,WlanDeviceClassCoInstaller
dvi: Using exported function 'FDCoInstaller' in module 'C:\Windows\system32\fdco1ins.dll'.
dvi: CoInstaller 3 == fdco1ins.dll,FDCoInstaller
dvi: CoInstaller 1: Enter 00:28:50.265
dvi: CoInstaller 1: Exit
dvi: CoInstaller 2: Enter 00:28:50.281
dvi: CoInstaller 2: Exit
dvi: CoInstaller 3: Enter 00:28:50.281
dvi: CoInstaller 3: Exit
dvi: Class installer: Enter 00:28:50.281
dvi: Class installer: Exit
dvi: Default installer: Enter 00:28:50.281
dvi: {Change State}
dvi: Device Instance = '{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&00'.
dvi: {DICS_DISABLE, DICS_FLAG_GLOBAL}
dvi: Using exported function 'NetClassInstaller' in module 'C:\Windows\system32\NetCfgx.dll'.
dvi: Class installer == NetCfgx.dll,NetClassInstaller
dvi: Using exported function 'NciDeviceInstall' in module 'C:\Windows\system32\nci.dll'.
dvi: CoInstaller 1 == nci.dll,NciDeviceInstall
dvi: Using exported function 'WlanDeviceClassCoInstaller' in module 'C:\Windows\system32\wlaninst.dll'.
dvi: CoInstaller 2 == wlaninst.dll,WlanDeviceClassCoInstaller
dvi: Using exported function 'FDCoInstaller' in module 'C:\Windows\system32\fdco1ins.dll'.
dvi: CoInstaller 3 == fdco1ins.dll,FDCoInstaller
dvi: CoInstaller 1: Enter 13:34:36.234
dvi: CoInstaller 1: Exit
dvi: CoInstaller 2: Enter 13:34:36.234
dvi: CoInstaller 2: Exit
dvi: CoInstaller 3: Enter 13:34:36.234
dvi: CoInstaller 3: Exit
dvi: Class installer: Enter 13:34:36.234
dvi: Class installer: Exit
dvi: Default installer: Enter 13:34:36.234
dvi: {Change State}
dvi: Device Instance = '{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&00'.
dvi: {DICS_DISABLE, DICS_FLAG_GLOBAL}
dvi: Using exported function 'NetClassInstaller' in module 'C:\Windows\system32\NetCfgx.dll'.
dvi: Class installer == NetCfgx.dll,NetClassInstaller
dvi: Using exported function 'NciDeviceInstall' in module 'C:\Windows\system32\nci.dll'.
dvi: CoInstaller 1 == nci.dll,NciDeviceInstall
dvi: Using exported function 'WlanDeviceClassCoInstaller' in module 'C:\Windows\system32\wlaninst.dll'.
dvi: CoInstaller 2 == wlaninst.dll,WlanDeviceClassCoInstaller
dvi: Using exported function 'FDCoInstaller' in module 'C:\Windows\system32\fdco1ins.dll'.
dvi: CoInstaller 3 == fdco1ins.dll,FDCoInstaller
dvi: CoInstaller 1: Enter 14:00:13.609
dvi: CoInstaller 1: Exit
dvi: CoInstaller 2: Enter 14:00:13.625
dvi: CoInstaller 2: Exit
dvi: CoInstaller 3: Enter 14:00:13.625
dvi: CoInstaller 3: Exit
dvi: Class installer: Enter 14:00:13.625
dvi: Class installer: Exit
dvi: Default installer: Enter 14:00:13.625
dvi: {Change State}
dvi: Device Instance = '{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&00'.
dvi: {DICS_DISABLE, DICS_FLAG_GLOBAL}
<ins>

<ins>

<ins>

Praveen Kumar Amritaluru wrote:
MiniportHalt().

Try ndiskd, see

http://groups.google.com/group/micro...d6528d23ea80cc

See also

"INFO: NDIS Debug Tracing and Kernel Debugger Extensions"
http://support.microsoft.com/default...;EN-US;Q248413

"Getting Trace from NETCFG.DLL"
http://www.ndis.com/papers/

Stephan

What are "pause" and "close" routines???? Are you speaking about
MiniportPnPEventNotify() and MiniportHalt() routines,
or "close routine" means MiniportShutdown()???

In your case MiniportHalt() should be the one that gets called first,
and what you do in in it is just the reverse of MiniportInitialize().
MiniportShutdown() should not call any NDIS functions.

Are you sure you have implemented MiniportHalt() properly???

Anton Bassov


Stephan Wolf [MVP] wrote:

Thanks Stephan for the link. It gives much useful info for debugging.

"Stephan Wolf [MVP]" <stewo68@hotmail.com> wrote in message
news:1166536297.445560.6460@f1g2000cwa.googlegroup s.com...

Hi,

Here is the information I got in windbg following the instructions in
the link:
http://groups.google.com/group/micro...d6528d23ea80cc

It talks about some references being held by upper layers.
But is that the reason why my miniporthalt routine is not getting called?
What reference are they talking about?

Is it some sends pending to be completed? Or some other requests pending?
If so is it possible to find what exactly is pending/held by my driver that
is stopping from MiniportHalt routine getting called?

Regds,


4.000044 82c55ad0 0002447 Blocked nt!KiSwapContext+0x26
nt!KiSwapThread+0x389
nt!KeWaitForSingleObject+0x414
ndis!ndisPauseMiniport+0x157
ndis!ndisCloseMiniportBindings+0x18d
ndis!ndisPnPRemoveDevice+0x1ab
ndis!ndisPnPDispatch+0x2ec
nt!IovCallDriver+0x252
nt!IofCallDriver+0x1b
nt!ViFilterDispatchPnp+0xd3
nt!IovCallDriver+0x252
nt!IofCallDriver+0x1b
nt!IopSynchronousCall+0xce
nt!IopRemoveDevice+0xd5
nt!PnpRemoveLockedDeviceNode+0x172
nt!PnpDeleteLockedDeviceNode+0x2b
nt!PnpDeleteLockedDeviceNodes+0x4c
nt!PnpProcessQueryRemoveAndEject+0x8ac
nt!PnpProcessTargetDeviceEvent+0x38
nt!PnpDeviceEventWorker+0x201
nt!ExpWorkerThread+0xfd
nt!PspSystemThreadStartup+0x9d
nt!KiThreadStartup+0x16




kd> !ndiskd.miniports
NDIS Driver verifier level: fa
NDIS Failed allocations : 0
Miniport Driver Block: 91b58df0, Version 1.0
Miniport: 97ffd488, NetLuidIndex: 2, IfIndex: 15, Microsoft ISATAP Adapter
Miniport Driver Block: 936e1570, Version 0.1
Miniport: 936e60e8, NetLuidIndex: 4, IfIndex: 10, <xyz>
Miniport Driver Block: 869e1200, Version 0.0
Miniport: 89e54370, NetLuidIndex: 1, IfIndex: 3, WAN Miniport (PPTP)
Miniport Driver Block: 89e55c48, Version 0.0
Miniport: 869e1488, NetLuidIndex: 0, IfIndex: 4, WAN Miniport (PPPOE)
Miniport Driver Block: 89e584e0, Version 0.0
Miniport: 89e550e8, NetLuidIndex: 0, IfIndex: 5, WAN Miniport (IPv6)
Miniport: 869ef0e8, NetLuidIndex: 3, IfIndex: 6, WAN Miniport (IP)
Miniport Driver Block: 868fcdb0, Version 0.0
Miniport: 869f60e8, NetLuidIndex: 0, IfIndex: 2, WAN Miniport (L2TP)
Miniport Driver Block: 868f7d40, Version 0.0
Miniport: 868fc0e8, NetLuidIndex: 5, IfIndex: 9, Teredo Tunneling
Pseudo-Interface
kd> !ndiskd 936e60e8
No export ndiskd found
kd> !ndiskd.miniport 936e60e8

Miniport 936e60e8 : <xyz>, v6.0

AdapterContext : 93719000
Flags : 2c452218
BUS_MASTER, 64BIT_DMA, IGNORE_TOKEN_RING_ERRORS
DESERIALIZED, RESOURCES_AVAILABLE, SUPPORTS_MEDIA_SENSE
DOES_NOT_DO_LOOPBACK, MEDIA_CONNECTED, SG_DMA
PnPFlags : 00700031
PM_SUPPORTED, REMOVE_IN_PROGRESS, DEVICE_POWER_ENABLED
VERIFYING, HARDWARE_DEVICE, NDIS_WDM_DRIVER
MiniportState : STATE_PAUSING
IfIndex : 10
Ndis5MiniportInNdis6Mode : 0
InternalResetCount : 0000
MiniportResetCount : 0000
References : 7
UserModeOpenReferences: 0
PnPDeviceState : PNP_DEVICE_REMOVED
CurrentDevicePowerState : PowerDeviceD0
Bus PM capabilities
DeviceD1: 1
DeviceD2: 1
WakeFromD0: 0
WakeFromD1: 1
WakeFromD2: 1
WakeFromD3: 1

SystemState DeviceState
PowerSystemUnspecified PowerDeviceUnspecified
S0 D0
S1 D3
S2 D3
S3 D3
S4 D3
S5 D3
SystemWake: S4
DeviceWake: D3

WakeupMethods Enabled 2:
WAKE_UP_PATTERN_MATCH
WakeUpCapabilities:
MinMagicPacketWakeUp: 4
MinPatternWakeUp: 4
MinLinkChangeWakeUp: 4
Current PnP and PM Settings: : 00000030
DISABLE_WAKE_UP, DISABLE_WAKE_ON_RECONNECT,
No Resources Allocated
MediaType : 802.3
DeviceObject : 936e6030, PhysDO : 936a0ac0 Next DO: 936cbdc0
MapRegisters : 00000000
FirstPendingPkt: 00000000
DriverVerifyFlags : 00000000
Miniport Interrupt : 00000000
Miniport version 6.0
Miniport Filter List:
Filter 977cf620: FilterDriver 89e0a0e0, FilterModuleContext 977cf378
<xyz>-QoS Packet Scheduler-0000
Miniport Open Block Queue:
936fe4b8: Protocol 89e23740 = TCPIP, ProtocolBindingContext 936fe868,
v6.0
936fec58: Protocol 92c16e78 = LLTDIO, ProtocolBindingContext 936fe008,
v6.0
936fd470: Protocol 91b25c50 = RSPNDR, ProtocolBindingContext 936fd820,
v6.0
kd> !ndiskd.mopen 936fe4b8
Miniport Open Block 936fe4b8
Protocol 89e23740 = TCPIP, ProtocolContext 936fe868, v6.0
Miniport 936e60e8 = <xyz>, v6.0

MiniportAdapterContext: 93719000
Flags : 01000000
OPEN_USE_MULTICAST_LIST,
References : 1
kd> !ndiskd.mopen 936fec58
Miniport Open Block 936fec58
Protocol 92c16e78 = LLTDIO, ProtocolContext 936fe008, v6.0
Miniport 936e60e8 = <xyz>, v6.0

MiniportAdapterContext: 93719000
Flags : 00000000
References : 1
kd> !ndiskd.mopen 936fd470
Miniport Open Block 936fd470
Protocol 91b25c50 = RSPNDR, ProtocolContext 936fd820, v6.0
Miniport 936e60e8 = <xyz>, v6.0

MiniportAdapterContext: 93719000
Flags : 00000000
References : 1




"Stephan Wolf [MVP]" <stewo68@hotmail.com> wrote in message
news:1166536297.445560.6460@f1g2000cwa.googlegroup s.com...

Praveen,

I see the possible reason for your problem......

Imagine if there is some legacy protocol driver bound to your miniport.
Once it is legacy driver, it does not have PnP handler that would be
called in event of NIC removal, and, hence, it has no chance to get
informed about NIC removal so that it cannot unbind itself from your
miniport. Imagine what would happen if miniport driver had been
unloaded and the protocol passed NDIS_OPEN_BLOCK that describes the
binding between this protocol and your driver to any NDIS function that
expects it.... BANG!!!!!!!


In order to avoid the above scenario, NDIS just would not allow
unloading your miniport driver, in the first place, until all legacy
protocol drivers bound to it unbind themselves from your miniport


Examine the bindings between your miniport and protocol drivers. If you
find some legacy protocol bound to it, try to unload it before
removing your NIC (unless it does not implement its Unload() routine,
you will be able to unload it via SC Manager)

Anton Bassov

Praveen Kumar Amritaluru wrote:

So your driver is a NDIS-WDM miniport?

In this case consider the description of MiniportPnPEventNotify() in
the DDK, excerpt:

"When a miniport driver receives notification of a surprise removal, it
should note internally that the device has been removed and cancel any
pending IRPs that it sent down to the underlying bus driver. After
calling the MiniportPnPEventNotify function to indicate the surprise
removal, NDIS calls the miniport's MiniportHalt function. If the
miniport driver receives any requests to send packets or query or set
OIDs before its MiniportHalt function is called, it should immediately
complete such requests with a status value of
NDIS_STATUS_NOT_ACCEPTED."

Stephan

Stephan,

And what is supposed to happen when NIC is removed if your miniport is
PnP-compliant (i.e. at least of NDIS-version 5.1) and some legacy
protocol driver is still bound to it???

Apparently, your driver will stay resident, but just return an error on
all subsequent calls to it (unless NIC gets re-inserted), right?

Anton Bassov


Stephan Wolf [MVP] wrote:

Surprise Removal is not applicable to our device. Currently checking out the
case of pending OIDs or send packets.

Looks like IRP_MN_QUERY_REMOVE is getting processed by
underlying bus driver and success returned meaning BD is not holding any
resources
including pending IRPs.

Soviet,

I dont see legacy protocol driver in the bind list. Do you see any in the
o/p that I sent yday.
QUOTe
936fe4b8: Protocol 89e23740 = TCPIP, ProtocolBindingContext 936fe868,
v6.0
936fec58: Protocol 92c16e78 = LLTDIO, ProtocolBindingContext 936fe008,
v6.0
936fd470: Protocol 91b25c50 = RSPNDR, ProtocolBindingContext 936fd820
UNQUOTe

Regds,


"Stephan Wolf [MVP]" <stewo68@hotmail.com> wrote in message
news:1166627259.974758.38190@80g2000cwy.googlegrou ps.com...

It does not work this way - WinDbg is not going to tell you that. What
you have to do is:

1. Get all protocols, bound to your driver, from WinDbg
2. Check info about your miniport under
HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E 972-E325-11CE-BFC1-08002bE10318},
namely, 'UpperBind' value of 'Linkage' key - it list all protocols that
are configured to bind to your miniport

3. If you see some protocol driver that appears under (1) but not under
(2), you can be sure that it has not been installed via Device Manager,
so that this is not PnP-compliant installation

Anton Bassov


Praveen Kumar Amritaluru wrote:

This is NDIS3, so, obsolete even for NT4.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

I think there are no more NDIS3 protocols. All protocol drivers shipped with
NT4 (!) are already NDIS4 and have the unbind handlers, so you can start and
stop the NIC drivers on NT4 without reboot.

Also I think that unbind handler is _mandatory according to the documentation_
for all protocols for w2k and later. So, I have the strong suspect that NDIS3
protocol is considered to be broken piece of code on w2k and later.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Sorry, for protocols, it is not Device Manager, it is NetCfg :-)

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Maxim,

What about third-party drivers????? The way they may *THEORETICALLY* be
written is described below

According to MSDN documentation, you need to call NdisOpenAdapter()
only from PtBindAdapter(), and, in order to be able do so, you need
..INF file - NDIS needs an info about underlying adapter in the
registry, because it has to pass the appropriate string to
PtBindAdapter(). This is the short story.

The long story is that, in practical terms, you still can install your
driver via SC Manager, and call NdisOpenAdapter() from DriverEntry -
even if MSDN says you cannot do so.....
This works *EVERYWHERE*, including pre-NDIS 6 protocols on Vista....

In other words, you still can have non-PnP (i.e NDIS3-style)
installation on your machine on any modern OS system, so that your
PnP-related functions will never get called - even if you have supplies
their addresses upon protocol registration, it is, in practical terms,
still just a legacy driver....


Anton Bassov


Maxim S. Shatskih wrote:

This is my omission, I admit....

Thank you for correction

Anton Bassov

Maxim S. Shatskih wrote:

I think that MS does not guarantee NDIS3 protocols to work on w2k anyway.

So, NDIS3 protocols are no more supported and documented.

Yes, protocols require installation via NetCfg. The name in the INF must match
the name passed to NdisRegisterProtocol.

....and then MS does not promise you that the OS will not crash just after. If
the OS will crash - then MS will respond to this "sorry, you have a bug in your
code, using outdated no-more-supported feature is a bug".

I would not be surprised that such an approach breaks something in the OS, for
instance, the ability to unload/reload the NIC drivers.

....with who-knows-what negative impact on the OS.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Maxim,



This is *EXACTLY* why I mentioned the whole thing. The problem is that,
although such approach normally works, you never know what "surprize"
in may have for you up its sleeve,
and when (or if) it is about to show it...

I don't exclude the possibility that the OP has such protocol driver on
his machine, so that it started showing its tricks - otherwise, I just
don't see any obvious reason why his MiniportHalt() does not get
called.

Anton Bassov

Maxim S. Shatskih wrote:

If a protocol driver registers with NDIS without having an Unbind handler,
NDIS will fail the protocol registration. I believe we added this check in
W2K. So no matter how such a protocol has been "installed" on a system, it
can not register with NDIS and bind to an adapter (as a protocol you can not
bind to a miniport without registering with NDIS first).

I have not read the entire thread yet, but the original problem reported
might be due to an OID request that has not been completed by the miniport.
That would block NDIS from unbinding protocols which is a prerequisite for
halting the miniport.

-ali

--
This posting is provided "AS IS" with no warranties, and confers no rights.

<soviet_bloke@hotmail.com> wrote in message
news:1166732344.411043.45550@79g2000cws.googlegrou ps.com...

Have you checked to make sure you do not have any outstanding OID requests
on the miniport?
Is this an NDIS 6 driver?

-ali

--
This posting is provided "AS IS" with no warranties, and confers no rights.

"Praveen Kumar Amritaluru" <apraveen.kumar@gmail.com> wrote in message
news:%23pxstN2IHHA.3424@TK2MSFTNGP02.phx.gbl...
Which is the first NDIS routine registered by miniport with NDIS that needs
to be called when network device is disabled?
When I try to disable the ethernet device, the device manager hangs and
device disable never seems to get disabled.
I see lots of incoming traffic and packets getting indicated from my driver
to NDIS.
\windows\inf\setuapi.app.log has the log enclosed below.
Wondering why disable is not going through.. Looking at my device context I
dont have any pendings sends to be completed.
Neither is my pause routine getting called. Nor is Ndis close routine
getting called. Any what the problem could be?

Regds,


dvi: Using exported function 'NetClassInstaller' in module
'C:\Windows\system32\NetCfgx.dll'.
dvi: Class installer == NetCfgx.dll,NetClassInstaller
dvi: Using exported function 'NciDeviceInstall' in module
'C:\Windows\system32\nci.dll'.
dvi: CoInstaller 1 == nci.dll,NciDeviceInstall
dvi: Using exported function 'WlanDeviceClassCoInstaller' in module
'C:\Windows\system32\wlaninst.dll'.
dvi: CoInstaller 2 == wlaninst.dll,WlanDeviceClassCoInstaller
dvi: Using exported function 'FDCoInstaller' in module
'C:\Windows\system32\fdco1ins.dll'.
dvi: CoInstaller 3 == fdco1ins.dll,FDCoInstaller
dvi: CoInstaller 1: Enter 00:28:50.265
dvi: CoInstaller 1: Exit
dvi: CoInstaller 2: Enter 00:28:50.281
dvi: CoInstaller 2: Exit
dvi: CoInstaller 3: Enter 00:28:50.281
dvi: CoInstaller 3: Exit
dvi: Class installer: Enter 00:28:50.281
dvi: Class installer: Exit
dvi: Default installer: Enter 00:28:50.281
dvi: {Change State}
dvi: Device Instance =
'{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&00'.
dvi: {DICS_DISABLE, DICS_FLAG_GLOBAL}
dvi: Using exported function 'NetClassInstaller' in module
'C:\Windows\system32\NetCfgx.dll'.
dvi: Class installer == NetCfgx.dll,NetClassInstaller
dvi: Using exported function 'NciDeviceInstall' in module
'C:\Windows\system32\nci.dll'.
dvi: CoInstaller 1 == nci.dll,NciDeviceInstall
dvi: Using exported function 'WlanDeviceClassCoInstaller' in
module 'C:\Windows\system32\wlaninst.dll'.
dvi: CoInstaller 2 == wlaninst.dll,WlanDeviceClassCoInstaller
dvi: Using exported function 'FDCoInstaller' in module
'C:\Windows\system32\fdco1ins.dll'.
dvi: CoInstaller 3 == fdco1ins.dll,FDCoInstaller
dvi: CoInstaller 1: Enter 13:34:36.234
dvi: CoInstaller 1: Exit
dvi: CoInstaller 2: Enter 13:34:36.234
dvi: CoInstaller 2: Exit
dvi: CoInstaller 3: Enter 13:34:36.234
dvi: CoInstaller 3: Exit
dvi: Class installer: Enter 13:34:36.234
dvi: Class installer: Exit
dvi: Default installer: Enter 13:34:36.234
dvi: {Change State}
dvi: Device Instance =
'{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&00'.
dvi: {DICS_DISABLE, DICS_FLAG_GLOBAL}
dvi: Using exported function 'NetClassInstaller' in
module 'C:\Windows\system32\NetCfgx.dll'.
dvi: Class installer ==
NetCfgx.dll,NetClassInstaller
dvi: Using exported function 'NciDeviceInstall' in
module 'C:\Windows\system32\nci.dll'.
dvi: CoInstaller 1 == nci.dll,NciDeviceInstall
dvi: Using exported function
'WlanDeviceClassCoInstaller' in module 'C:\Windows\system32\wlaninst.dll'.
dvi: CoInstaller 2 ==
wlaninst.dll,WlanDeviceClassCoInstaller
dvi: Using exported function 'FDCoInstaller' in
module 'C:\Windows\system32\fdco1ins.dll'.
dvi: CoInstaller 3 == fdco1ins.dll,FDCoInstaller
dvi: CoInstaller 1: Enter 14:00:13.609
dvi: CoInstaller 1: Exit
dvi: CoInstaller 2: Enter 14:00:13.625
dvi: CoInstaller 2: Exit
dvi: CoInstaller 3: Enter 14:00:13.625
dvi: CoInstaller 3: Exit
dvi: Class installer: Enter 14:00:13.625
dvi: Class installer: Exit
dvi: Default installer: Enter 14:00:13.625
dvi: {Change State}
dvi: Device Instance =
'{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&00'.
dvi: {DICS_DISABLE, DICS_FLAG_GLOBAL}
<ins>
<ins>
<ins>

Alireza,

Indeed, under modern OS versions you cannot register a protocol without
having specified its Unload() handler, but still you can install it via
SC Manager and bind to adapters from DriverEntry(), i.e. do it the way
NDIS3 drivers do (although MSDN says you cannot do it).


In other words, from NdisRegisterProtocol()'s perspective, you are
registering a perfectly valid NDIS 4/5 protocol driver, but, unless it
has been installed with .INF file, NDIS just does not seem to treat
your driver as PnP-compliant one, despite NDIS version that you have
specified upon protocol registration. For example, its PtBindAdapter()
does not get called upon DriverEntry()'s return the way it is supposed
to happen with protocol drivers of any NDIS version above 3 - instead,
you have to call NdisOpenAdapter() right from DriverEntry() the way you
do it with legact drivers if you install it via SC Manager. Therefore,
unless your driver has been installed with an .INF file, all your
PnP-related handlers seem to be just a piece of dead code that never
gets invoked, so that, in practical terms, this is just a legacy driver



Anton Bassov


Alireza Dabagh [MS] wrote: