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

This is a multi-part message in MIME format.

------=_NextPart_000_0026_01C72391.85217160
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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,

>>> [DIF_PROPERTYCHANGE - =
{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&00]
>>> Section start 2006/12/19 00:28:50.234
cmd: "C:\Windows\system32\mmc.exe" C:\Windows\system32\devmgmt.msc
dvi: Using exported function 'NetClassInstaller' in module =
'C:\Windows\system32\NetCfgx.dll'.
dvi: Class installer =3D=3D NetCfgx.dll,NetClassInstaller
dvi: Using exported function 'NciDeviceInstall' in module =
'C:\Windows\system32\nci.dll'.
dvi: CoInstaller 1 =3D=3D nci.dll,NciDeviceInstall
dvi: Using exported function 'WlanDeviceClassCoInstaller' in module =
'C:\Windows\system32\wlaninst.dll'.
dvi: CoInstaller 2 =3D=3D wlaninst.dll,WlanDeviceClassCoInstaller
dvi: Using exported function 'FDCoInstaller' in module =
'C:\Windows\system32\fdco1ins.dll'.
dvi: CoInstaller 3 =3D=3D 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 =3D =
'{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 =3D=3D NetCfgx.dll,NetClassInstaller
dvi: Using exported function 'NciDeviceInstall' in module =
'C:\Windows\system32\nci.dll'.
dvi: CoInstaller 1 =3D=3D nci.dll,NciDeviceInstall
dvi: Using exported function 'WlanDeviceClassCoInstaller' =
in module 'C:\Windows\system32\wlaninst.dll'.
dvi: CoInstaller 2 =3D=3D =
wlaninst.dll,WlanDeviceClassCoInstaller
dvi: Using exported function 'FDCoInstaller' in module =
'C:\Windows\system32\fdco1ins.dll'.
dvi: CoInstaller 3 =3D=3D 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 =3D =
'{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 =3D=3D =
NetCfgx.dll,NetClassInstaller
dvi: Using exported function 'NciDeviceInstall' =
in module 'C:\Windows\system32\nci.dll'.
dvi: CoInstaller 1 =3D=3D =
nci.dll,NciDeviceInstall
dvi: Using exported function =
'WlanDeviceClassCoInstaller' in module =
'C:\Windows\system32\wlaninst.dll'.
dvi: CoInstaller 2 =3D=3D =
wlaninst.dll,WlanDeviceClassCoInstaller
dvi: Using exported function 'FDCoInstaller' in =
module 'C:\Windows\system32\fdco1ins.dll'.
dvi: CoInstaller 3 =3D=3D =
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 =3D =
'{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&00'.
dvi: {DICS_DISABLE, DICS_FLAG_GLOBAL}
<ins>

>>> [DIF_PROPERTYCHANGE - =
{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&00]
>>> Section start 2006/12/19 13:34:36.187
cmd: "C:\Windows\system32\mmc.exe" C:\Windows\system32\devmgmt.msc
<ins>

>>> [DIF_PROPERTYCHANGE - =
{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&00]
>>> Section start 2006/12/19 14:00:13.578
cmd: "C:\Windows\system32\mmc.exe" C:\Windows\system32\devmgmt.msc
<ins>

------=_NextPart_000_0026_01C72391.85217160
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3020" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV>
Which is the first NDIS routine registered by =
miniport with=20
NDIS that needs to be called when network device is disabled?
When I try to disable the ethernet device, the =
device=20
manager hangs and device disable never seems to get disabled.
 I see lots of incoming traffic and packets =
getting=20
indicated from my driver to NDIS.
\windows\inf\setuapi.app.log has the log enclosed=20
below.
Wondering why disable is not going through.. =
Looking at my=20
device context I dont have any pendings sends to be =
completed.
 Neither is my pause routine getting called. =
Nor is=20
Ndis close routine getting called. Any what the problem could =
be?
 
Regds,
 
 >>>  [DIF_PROPERTYCHANGE -=20
{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&=
amp;00] >>> =20
Section start 2006/12/19 00:28:50.234       =
cmd:=20
"C:\Windows\system32\mmc.exe"=20
C:\Windows\system32\devmgmt.msc      dvi: Using =
exported=20
function 'NetClassInstaller' in module=20
'C:\Windows\system32\NetCfgx.dll'.      dvi: =
Class=20
installer =3D=3D =
NetCfgx.dll,NetClassInstaller      dvi:=20
Using exported function 'NciDeviceInstall' in module=20
'C:\Windows\system32\nci.dll'.      dvi: =
CoInstaller 1 =3D=3D=20
nci.dll,NciDeviceInstall      dvi: Using exported =

function 'WlanDeviceClassCoInstaller' in module=20
'C:\Windows\system32\wlaninst.dll'.      dvi: =
CoInstaller=20
2 =3D=3D =
wlaninst.dll,WlanDeviceClassCoInstaller      dvi: =

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

installer: Enter 13:34:36.234     =20
dvi:           &nb=
sp;   =20
{Change State}     =20
dvi:           &nb=
sp;        =20
Device Instance =3D=20
'{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0=
&00'.     =20
dvi:           &nb=
sp;        =20
{DICS_DISABLE, DICS_FLAG_GLOBAL}     =20
dvi:           &nb=
sp;        =20
Using exported function 'NetClassInstaller' in module=20
'C:\Windows\system32\NetCfgx.dll'.     =20
dvi:           &nb=
sp;        =20
Class installer =3D=3D =
NetCfgx.dll,NetClassInstaller     =20
dvi:           &nb=
sp;        =20
Using exported function 'NciDeviceInstall' in module=20
'C:\Windows\system32\nci.dll'.     =20
dvi:           &nb=
sp;        =20
CoInstaller 1 =3D=3D =
nci.dll,NciDeviceInstall     =20
dvi:           &nb=
sp;        =20
Using exported function 'WlanDeviceClassCoInstaller' in module=20
'C:\Windows\system32\wlaninst.dll'.     =20
dvi:           &nb=
sp;        =20
CoInstaller 2 =3D=3D=20
wlaninst.dll,WlanDeviceClassCoInstaller     =20
dvi:           &nb=
sp;        =20
Using exported function 'FDCoInstaller' in module=20
'C:\Windows\system32\fdco1ins.dll'.     =20
dvi:           &nb=
sp;        =20
CoInstaller 3 =3D=3D =
fdco1ins.dll,FDCoInstaller     =20
dvi:           &nb=
sp;        =20
CoInstaller 1: Enter 14:00:13.609     =20
dvi:           &nb=
sp;        =20
CoInstaller 1: Exit     =20
dvi:           &nb=
sp;        =20
CoInstaller 2: Enter 14:00:13.625     =20
dvi:           &nb=
sp;        =20
CoInstaller 2: Exit     =20
dvi:           &nb=
sp;        =20
CoInstaller 3: Enter 14:00:13.625     =20
dvi:           &nb=
sp;        =20
CoInstaller 3: Exit     =20
dvi:           &nb=
sp;        =20
Class installer: Enter 14:00:13.625     =20
dvi:           &nb=
sp;        =20
Class installer: Exit     =20
dvi:           &nb=
sp;        =20
Default installer: Enter 14:00:13.625     =20
dvi:           &nb=
sp;           &nbs=
p; =20
{Change State}     =20
dvi:           &nb=
sp;           &nbs=
p;      =20
Device Instance =3D=20
'{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0=
&00'.     =20
dvi:           &nb=
sp;           &nbs=
p;      =20
{DICS_DISABLE, DICS_FLAG_GLOBAL} <ins>
>>>  [DIF_PROPERTYCHANGE -=20
{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&=
amp;00] >>> =20
Section start 2006/12/19 13:34:36.187       =
cmd:=20
"C:\Windows\system32\mmc.exe" =
C:\Windows\system32\devmgmt.msc <ins>
>>>  [DIF_PROPERTYCHANGE -=20
{1A3E09BE-1E45-494B-9174-D7385B45BBF5}\NVNET_DEV0373\4&55C493A&0&=
amp;00] >>> =20
Section start 2006/12/19 14:00:13.578       =
cmd:=20
"C:\Windows\system32\mmc.exe"=20
C:\Windows\system32\devmgmt.msc <ins></DIV></BODY></H=
TML>

------=_NextPart_000_0026_01C72391.85217160--

Stephan
Tue Dec 19 07:51:37 CST 2006

Praveen Kumar Amritaluru wrote:
> Which is the first NDIS routine registered by miniport with NDIS that needs to be called when network device is disabled?

MiniportHalt().

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

Try ndiskd, see

http://groups.google.com/group/microsoft.public.development.device.drivers/browse_frm/thread/4e5ff068f010b374/3cd6528d23ea80cc

See also

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

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

Stephan

soviet_bloke
Tue Dec 19 09:35:54 CST 2006

> Neither is my pause routine getting called. Nor is Ndis close routine getting called.

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:
> Praveen Kumar Amritaluru wrote:
> > Which is the first NDIS routine registered by miniport with NDIS that needs to be called when network device is disabled?
>
> MiniportHalt().
>
> > When I try to disable the ethernet device, the device manager hangs and device disable never seems to get disabled.
>
> Try ndiskd, see
>
> http://groups.google.com/group/microsoft.public.development.device.drivers/browse_frm/thread/4e5ff068f010b374/3cd6528d23ea80cc
>
> See also
>
> "INFO: NDIS Debug Tracing and Kernel Debugger Extensions"
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q248413
>
> "Getting Trace from NETCFG.DLL"
> http://www.ndis.com/papers/
>
> Stephan

Praveen
Tue Dec 19 11:28:39 CST 2006

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.googlegroups.com...
> Praveen Kumar Amritaluru wrote:
>> Which is the first NDIS routine registered by miniport with NDIS that
>> needs to be called when network device is disabled?
>
> MiniportHalt().
>
>> When I try to disable the ethernet device, the device manager hangs and
>> device disable never seems to get disabled.
>
> Try ndiskd, see
>
> http://groups.google.com/group/microsoft.public.development.device.drivers/browse_frm/thread/4e5ff068f010b374/3cd6528d23ea80cc
>
> See also
>
> "INFO: NDIS Debug Tracing and Kernel Debugger Extensions"
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q248413
>
> "Getting Trace from NETCFG.DLL"
> http://www.ndis.com/papers/
>
> Stephan
>

Praveen
Tue Dec 19 13:17:12 CST 2006

Hi,

Here is the information I got in windbg following the instructions in
the link:
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_frm/thread/4e5ff068f010b374/3cd6528d23ea80cc

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.googlegroups.com...
> Praveen Kumar Amritaluru wrote:
>> Which is the first NDIS routine registered by miniport with NDIS that
>> needs to be called when network device is disabled?
>
> MiniportHalt().
>
>> When I try to disable the ethernet device, the device manager hangs and
>> device disable never seems to get disabled.
>
> Try ndiskd, see
>
> http://groups.google.com/group/microsoft.public.development.device.drivers/browse_frm/thread/4e5ff068f010b374/3cd6528d23ea80cc
>
> See also
>
> "INFO: NDIS Debug Tracing and Kernel Debugger Extensions"
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q248413
>
> "Getting Trace from NETCFG.DLL"
> http://www.ndis.com/papers/
>
> Stephan
>

soviet_bloke
Tue Dec 19 19:19:55 CST 2006

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:
> 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.googlegroups.com...
> > Praveen Kumar Amritaluru wrote:
> >> Which is the first NDIS routine registered by miniport with NDIS that
> >> needs to be called when network device is disabled?
> >
> > MiniportHalt().
> >
> >> When I try to disable the ethernet device, the device manager hangs and
> >> device disable never seems to get disabled.
> >
> > Try ndiskd, see
> >
> > http://groups.google.com/group/microsoft.public.development.device.drivers/browse_frm/thread/4e5ff068f010b374/3cd6528d23ea80cc
> >
> > See also
> >
> > "INFO: NDIS Debug Tracing and Kernel Debugger Extensions"
> > http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q248413
> >
> > "Getting Trace from NETCFG.DLL"
> > http://www.ndis.com/papers/
> >
> > Stephan
> >

Stephan
Wed Dec 20 09:07:40 CST 2006

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

soviet_bloke
Wed Dec 20 09:51:24 CST 2006

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:
> 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

Praveen
Wed Dec 20 11:24:48 CST 2006

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.googlegroups.com...
> 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
>

soviet_bloke
Wed Dec 20 16:44:22 CST 2006

> I dont see legacy protocol driver in the bind list. Do you see any in the
> o/p that I sent yday.

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\{4D36E972-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:
> 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.googlegroups.com...
> > 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
> >

Maxim
Thu Dec 21 06:04:04 CST 2006

> 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.

This is NDIS3, so, obsolete even for NT4.

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

Maxim
Thu Dec 21 06:07:17 CST 2006

> PnP-compliant (i.e. at least of NDIS-version 5.1) and some legacy
> protocol driver is still bound to it???

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

Maxim
Thu Dec 21 06:08:56 CST 2006

> (2), you can be sure that it has not been installed via Device Manager,
> so that this is not PnP-compliant installation

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

soviet_bloke
Thu Dec 21 08:35:13 CST 2006

Maxim,

> 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.

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

> 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.

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:
> > PnP-compliant (i.e. at least of NDIS-version 5.1) and some legacy
> > protocol driver is still bound to it???
>
> 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

soviet_bloke
Thu Dec 21 08:36:41 CST 2006

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

This is my omission, I admit....

Thank you for correction

Anton Bassov

Maxim S. Shatskih wrote:
> > (2), you can be sure that it has not been installed via Device Manager,
> > so that this is not PnP-compliant installation
>
> Sorry,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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