Which is the first NDIS routine registered by miniport with NDIS that needs to be called when networ

Praveen_Kumar_Amritaluru · December 19, 2006, 6:51am

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 == 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}

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

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

David_R_Cattley · December 19, 2006, 8:29am

NDIS calls MiniportHalt after it has finished shutting down all protocol
bindings in response to a PnP ‘stop’. If your driver ‘hangs’ in
MiniportHalt, so will the PnP operation. Common errors include leaking
packet descriptors and then spinning in a loop waiting for the pool usage
count to return to zero.

Good luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Tuesday, December 19, 2006 6:47 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Which is the first NDIS routine registered by miniport with
NDIS that needs to be called when network device is disabled?

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,

Praveen_Kumar_Amritaluru · December 19, 2006, 12:05pm

OK. The problem is that its not coming till this point.
I dont see MiniportHalt getting called either… Neither do I see any of the
PauseHandler or ShutdownHandlerEx getting called.

By looping did you mean, looping with my driver code?
Also is there a way to figure out whether there is any source my driver is
holding that is pending remove from getting completed.
Is it possible to find it (other than looking at my driver code)?

Regds,

“David R. Cattley” wrote in message news:xxxxx@ntdev…
> NDIS calls MiniportHalt after it has finished shutting down all protocol
> bindings in response to a PnP ‘stop’. If your driver ‘hangs’ in
> MiniportHalt, so will the PnP operation. Common errors include leaking
> packet descriptors and then spinning in a loop waiting for the pool usage
> count to return to zero.
>
> Good luck,
> Dave Cattley
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
> Amritaluru
> Sent: Tuesday, December 19, 2006 6:47 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Which is the first NDIS routine registered by miniport
> with
> NDIS that needs to be called when network device is disabled?
>
> 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,
>
>

David_R_Cattley · December 19, 2006, 12:45pm

NDIS will not halt your miniport until after all protocols have closed their
bindings.

Break into WinDBG and use the ndiskd extensions to find out what binding
(miniport open) is still active on the stack.

Good luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Tuesday, December 19, 2006 12:05 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Which is the first NDIS routine registered by miniport
with NDIS that needs to be called when network device is disabled?

OK. The problem is that its not coming till this point.
I dont see MiniportHalt getting called either… Neither do I see any of the
PauseHandler or ShutdownHandlerEx getting called.

By looping did you mean, looping with my driver code?
Also is there a way to figure out whether there is any source my driver is
holding that is pending remove from getting completed.
Is it possible to find it (other than looking at my driver code)?

Regds,

“David R. Cattley” wrote in message news:xxxxx@ntdev…
> NDIS calls MiniportHalt after it has finished shutting down all
> protocol bindings in response to a PnP ‘stop’. If your driver ‘hangs’
> in MiniportHalt, so will the PnP operation. Common errors include
> leaking packet descriptors and then spinning in a loop waiting for the
> pool usage count to return to zero.
>
> Good luck,
> Dave Cattley
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
> Amritaluru
> Sent: Tuesday, December 19, 2006 6:47 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Which is the first NDIS routine registered by
> miniport with NDIS that needs to be called when network device is
> disabled?
>
> 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,
>
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Praveen_Kumar_Amritaluru · December 19, 2006, 2:26pm

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,
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 : , 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
-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 = , 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 = , 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 = , v6.0

MiniportAdapterContext: 93719000
Flags : 00000000
References : 1

“David R. Cattley” wrote in message news:xxxxx@ntdev…
> NDIS will not halt your miniport until after all protocols have closed
> their
> bindings.
>
> Break into WinDBG and use the ndiskd extensions to find out what binding
> (miniport open) is still active on the stack.
>
> Good luck,
> Dave Cattley
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
> Amritaluru
> Sent: Tuesday, December 19, 2006 12:05 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Which is the first NDIS routine registered by miniport
> with NDIS that needs to be called when network device is disabled?
>
> OK. The problem is that its not coming till this point.
> I dont see MiniportHalt getting called either… Neither do I see any of
> the
> PauseHandler or ShutdownHandlerEx getting called.
>
> By looping did you mean, looping with my driver code?
> Also is there a way to figure out whether there is any source my driver is
> holding that is pending remove from getting completed.
> Is it possible to find it (other than looking at my driver code)?
>
> Regds,
>
>
> “David R. Cattley” wrote in message news:xxxxx@ntdev…
>> NDIS calls MiniportHalt after it has finished shutting down all
>> protocol bindings in response to a PnP ‘stop’. If your driver ‘hangs’
>> in MiniportHalt, so will the PnP operation. Common errors include
>> leaking packet descriptors and then spinning in a loop waiting for the
>> pool usage count to return to zero.
>>
>> Good luck,
>> Dave Cattley
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
>> Amritaluru
>> Sent: Tuesday, December 19, 2006 6:47 AM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] Which is the first NDIS routine registered by
>> miniport with NDIS that needs to be called when network device is
>> disabled?
>>
>> 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,
>>
>>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>

Vince_Bridgers · December 19, 2006, 3:33pm

I have seen what you are describing occur when a
previous send has not yet been completed by the
miniport. Are you tracking sends and send completions?
Do you have any outstanding sends?

How about using checked ndis, tcpip, and kernel? Using
the ndis debug flags? These can be very useful.

— Praveen Kumar Amritaluru
wrote:

> 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,
>
> 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 : , 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
> -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 = , 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 = , 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 = , v6.0
>
> MiniportAdapterContext: 93719000
> Flags : 00000000
> References : 1
>
>
> “David R. Cattley” wrote in
> message news:xxxxx@ntdev…
> > NDIS will not halt your miniport until after all
> protocols have closed
> > their
> > bindings.
> >
> > Break into WinDBG and use the ndiskd extensions to
> find out what binding
> > (miniport open) is still active on the stack.
> >
> > Good luck,
> > Dave Cattley
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On
> Behalf Of Praveen Kumar
> > Amritaluru
> > Sent: Tuesday, December 19, 2006 12:05 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re:[ntdev] Which is the first NDIS
> routine registered by miniport
> > with NDIS that needs to be called when network
> device is disabled?
> >
> > OK. The problem is that its not coming till this
> point.
> > I dont see MiniportHalt getting called either…
> Neither do I see any of
> > the
> > PauseHandler or ShutdownHandlerEx getting called.
> >
> > By looping did you mean, looping with my driver
> code?
> > Also is there a way to figure out whether there is
> any source my driver is
> > holding that is pending remove from getting
> completed.
> > Is it possible to find it (other than looking at
> my driver code)?
> >
> > Regds,
> >
> >
> > “David R. Cattley” wrote in
> message news:xxxxx@ntdev…
> >> NDIS calls MiniportHalt after it has finished
> shutting down all
> >> protocol bindings in response to a PnP ‘stop’.
> If your driver ‘hangs’
> >> in MiniportHalt, so will the PnP operation.
> Common errors include
> >> leaking packet descriptors and then spinning in a
> loop waiting for the
> >> pool usage count to return to zero.
> >>
> >> Good luck,
> >> Dave Cattley
> >>
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com
> >> [mailto:xxxxx@lists.osr.com] On
> Behalf Of Praveen Kumar
> >> Amritaluru
> >> Sent: Tuesday, December 19, 2006 6:47 AM
> >> To: Windows System Software Devs Interest List
> >> Subject: [ntdev] Which is the first NDIS routine
> registered by
> >> miniport with NDIS that needs to be called when
> network device is
> >> disabled?
> >>
> >> 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,
> >>
> >>
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of
> OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR
> Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com