NdisIMDeInitializeDeviceInstance not calling MiniportHalt
Larry Clawson
two NICs under the driver. When I change the Link Speed of the one of the
NICs everything works fine. I see PtUnbindAdapter get called then
MiniportHalt is called followed by the PtBindAdapter.
When I try to change the Link Speed on the second NIC I only get as far as
the PtUnbindAdapter calling NdisIMDeInitializeDeviceInstance() where the
driver hangs. MinitportHalt is never called.
It does not matter which NIC I start with the second NIC always hangs. What
are the cases for NdisIMDeInitializeDeviceInstance not calling MiniportHalt?
Larry
Stephan Wolf
several scenarios. This is mainly on XP.
This has been discussed here several times, AFAIK without a satisfying
result.
I am more and more under the impression that there is a problem in
"the system" -be it NDIS, PnP, whatever- that causes this. We've been
banging our heads against the wall looking at "setupapi.log",
"checked" NDIS trace output etc.
Time for MS to jump in?
Stephan
---
Alireza Dabagh [MS]
calling DeInitDeviceInstance), NDIS first tries to close all the bindings
with overlying protocols. Bindings can not get closed if there are pending
requests/sends. Is it possible that you are pending a request that overlying
protocol has issued as a result of the unbind process and you have not
completed it?
Break into kernel debugger and do the following at the prompt:
!stack 2 ndis!
This will list all the threads with ndis on stack.
then lets get some information about the state of the binding from NDIS
point of view, first we have to find the "open block".
!ndiskd.miniports
to get a list of the miniports
and then:
!ndiskd.miniport <miniport block>
where miniport block is obtained from the previous step. this is also the
MiniportAdapterHandle NDIS passed to your MiniportInitialize.
this will get you details about the state of the miniport and all the
bindings on the miniport.
Then get some detail about the state of the binding:
!ndiskd.mopen <open block (obtained in previous step)>
-ali
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Larry Clawson" <larry....@honeywell.com> wrote in message
news:uozGFcRg...@TK2MSFTNGP11.phx.gbl...
Alireza Dabagh [MS]
initialized in the first place. Assuming your problem is different from the
original poster and in your case the call does not hang, please let me know
how we can get a repro.
-ali
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Stephan Wolf" <ste...@hotmail.com> wrote in message
news:3f6f5f4f...@news.t-online.de...
Larry Clawson
I have found that when the NetEventQueryRemoveDevice is signaled, if I stop
processing packets on both ports within the my IM (i.e. go into passthru
mode) then everything works. I then must go into the Property Page for my IM
to get it to continue processing packets by doing a reconfigure.
I will do your suggestions to narrow down why this happens.
Thanks,
Larry
"Alireza Dabagh [MS]" <al...@online.microsoft.com> wrote in message
news:OHL2akVg...@TK2MSFTNGP11.phx.gbl...
Stephan Wolf
MUX IM using SetupDi. This leads to the IM unbinding from the HW
miniport and as a result the IM also wants to stop its corresponding
virtual adapter using NdisIMDeInitializeDeviceInstance().
This virtual adapter is actually up and running i.e.
MiniportInitialize() has run. However, both SetupDi and
NdisIMDeInitializeDeviceInstance() do not return. Opening Device
Manager hangs ("not responding").
The last time I analyzed this is about two or three weeks ago but I no
longer have the environment set up. I'll come back when the problem
loops back on me ("analyze problem" -> "ignore problem" -> "deliver
driver" -> "angry customer" -> "analyze problem" ...). ;)
Stephan
---
Larry Clawson
!stack 2 ndis!
returns:
"No export stack found"
Larry C
"Alireza Dabagh [MS]" <al...@online.microsoft.com> wrote in message
news:OHL2akVg...@TK2MSFTNGP11.phx.gbl...
Alireza Dabagh [MS]
-ali
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Larry Clawson" <larry....@honeywell.com> wrote in message
news:uxhoKGfg...@TK2MSFTNGP12.phx.gbl...
Larry Clawson
It produced about 2500 lines of stacks dumps. What in particular should I
look for?
Here is the outputs from !ndiskd.miniports and !ndiskd.miniport for the
handle of the adapter that has hung:
kd> !ndiskd.miniports
Driver verifier level: fa
Failed allocations: 0
Miniport Driver Block: 814687b0
Miniport: 8146a130 Direct Parallel
Miniport Driver Block: 81469f30
Miniport: 814699d0 WAN Miniport (PPTP)
Miniport Driver Block: 8146be50
Miniport: 8146cb70 WAN Miniport (IP)
Miniport: 8146c130 WAN Miniport (Network Monitor)
Miniport Driver Block: 8147d8b0
Miniport: 8146d130 WAN Miniport (L2TP)
Miniport Driver Block: 8147eaf0
Miniport: 8147d2f0 Intel(R) PRO/100 S Dual Port Server Adapter - Honeywell
Fault Tolerant Ethernet Virtual Adapter
Miniport: 8147dab0 Intel(R) PRO/100 S Dual Port Server Adapter #2 -
Honeywell Fault Tolerant Ethernet Virtual Adapter
Miniport Driver Block: 81820390
Miniport: 8147e130 Intel(R) PRO/100 S Dual Port Server Adapter #2
Miniport: 8147f8f0 Intel(R) PRO/100 S Dual Port Server Adapter
kd> !ndiskd.miniport 8147d2f0
Miniport 8147d2f0 : Intel(R) PRO/100 S Dual Port Server Adapter - Honeywell
Fault Tolerant Ethernet Virtual Adapter
Flags : 2044ba00
INDICATES_PACKETS, IGNORE_PACKET_QUEUE, IGNORE_REQUEST_QUEUE
IGNORE_TOKEN_RING_ERRORS, INTERMEDIATE_DRIVER, DESERIALIZED
RESOURCES_AVAILABLE, MEDIA_CONNECTED,
NOT_BUS_MASTER, NOT_SUPPORTS_MEDIA_SENSE,
PnPFlags : 00018021
PM_SUPPORTED, DEVICE_POWER_ENABLED, NO_HALT_ON_SUSPEND
RECEIVED_START,
CheckforHang interval: 2 seconds
CurrentTick : 0001
IntervalTicks : 0001
InternalResetCount : 0000
MiniportResetCount : 0000
References: 0
UserModeOpenReferences: 0
PnPDeviceState : PNP_DEVICE_STOPPED
CurrentDevicePowerState : PowerDeviceD0
Bus PM capabilities
DeviceD1: 0
DeviceD2: 0
WakeFromD0: 0
WakeFromD1: 0
WakeFromD2: 0
WakeFromD3: 0
SystemState DeviceState
PowerSystemUnspecified PowerDeviceUnspecified
S0 D0
S1 D3
S2 D3
S3 D3
S4 D3
S5 D3
SystemWake: S0
DeviceWake: PowerDeviceUnspecified
Current PnP and PM Settings: : 00000031
NOT_STOPPABLE, DISABLE_WAKE_UP, DISABLE_WAKE_ON_RECONNECT
No Resources Allocated
MediaType : 802.3
DeviceObject : 8147d1f0, PhysDO : 81815d10 Next DO: 81815d10
MapRegisters : 0
FirstPendingPkt: 0
SingleWorkItems:
[0]: 0 [1]: 8147d6b4 [2]: 8147d6c0 [3]: 8147d6cc
[4]: 8147d6d8 [5]: 8147d6e4
DriverVerifyFlags : 00000000
Miniport Open Block Queue:
85a5f628: Protocol 85a58808 = TCPIP, ProtocolContext 85a60848
Miniport Interrupt 00000000
"Alireza Dabagh [MS]" <al...@online.microsoft.com> wrote in message
news:euVRMKjg...@tk2msftngp13.phx.gbl...
Larry Clawson
Any help would be appreciated.
Here is a stack from when MPHalt is called:
8.000038 8181c020 0000000 RUNNING FteImDrv!MPHalt+0x0
ee04f7dc f9c3b0e8 NDIS!ndisMCommonHaltMiniport(8147df4c, f9c2c197,
8147eaf0)+0x11c
ee04f7e4 f9c3b226 NDIS!ndisMHaltMiniport(8147eaf0, 8147dab0,
ee04f938)+0x1f
ee04f914 f9c2c197 NDIS!ndisPnPRemoveDevice(8451e628, 8147e9a8,
00000000)+0x1dd
ee04f924 f9c38a12 NDIS!NdisIMDeInitializeDeviceInstance(8147dab0,
8451e6a8, f9c2a89a)+0x40
ee04f938 f5a6e0c3 FteImDrv!PtUnbindAdapter(ee04fa04, 8451e6a8,
ee04f958)+0x91
ee04fa0c f9c2a97d NDIS!ndisUnbindProtocol(8451e628, 844d4828,
8147e130)+0x130
ee04fa58 f9c3b3f4 NDIS!ndisCloseMiniportBindings(8147e130,
8147e130, ee04fbc4)+0x103
ee04fb88 f9c2c17f NDIS!ndisPnPRemoveDevice(8147e030, fc28d768,
fc28d768)+0x1c5
ee04fbc4 f9c2cd57 NDIS!ndisPnPDispatch(8147e030, fc28d7fc,
8147e030)+0x229
ee04fbd8 8041f79f nt!IopfCallDriver(814d9030, 814d9030,
00000002)+0x35
ee04fc04 8049ac37 nt!IopSynchronousCall(8147e030, ee04fc24,
ee04fc54)+0xca
ee04fc4c 8049ace8 nt!IopRemoveDevice(814d9030, 00000002,
e2366848)+0x86
ee04fc74 804c1925 nt!IopDeleteLockedDeviceNode(8147e018, e242d168,
e2366848)+0x24b
ee04fcb0 8049c0ec nt!IopDeleteLockedDeviceNodes(814d9030,
e2366800, 00000002)+0xb0
ee04fd3c 8051ca18 nt!PiProcessQueryRemoveAndEject(00000000,
80063028, e2719428)+0x7ac
ee04fd54 804b258b nt!PiProcessTargetDeviceEvent(ee04fd74,
86364628, 8046d41c)+0x33
ee04fd78 804b249c nt!PiWalkDeviceList(86364628, 00000000,
00000000)+0xf7
ee04fda8 80418dc7 nt!ExpWorkerThread(86364628, 00000000,
00000000)+0xae
ee04fddc 804553af nt!PspSystemThreadStartup(80418d02, 00000001,
00000000)+0x69
00000000 804695b2 nt!KiThreadStartup(00000000, 00000000,
00000000)+0x16
Here is a stack from when MPHalt is NOT called:
8.00003c 8181cda0 0000846 BLOCKED nt!KiSwapThread
ee05362c 8042da3a nt!KeWaitForSingleObject(85a6094c, 00000006,
00000000)+0x1a1
ee053648 ee0c8fed TDI!CTEBlock(85a60948, 00000000, 85a32788)+0x17
ee05366c f595abb8 tcpip!ARPClose(85a60648, 85a60648,
85a60848)+0x94
ee0536a4 f59574a4 tcpip!IPDelInterface(85a32600, 00000001,
85a60648)+0x239
ee0536c4 f595c222 tcpip!ARPUnbindAdapter(ee053790, 85a60848,
ee0536e4)+0x6e
ee053798 f9c2a97d NDIS!ndisUnbindProtocol(85a60648, 85a5f628,
8147d2f0)+0x130
ee0537e4 f9c3b3f4 NDIS!ndisCloseMiniportBindings(8147eaf0,
8147d2f0, ee053938)+0x103
ee053914 f9c2c17f NDIS!ndisPnPRemoveDevice(813770e8, 8147e9a8,
00000000)+0x1c5
ee053924 f9c38a12 NDIS!NdisIMDeInitializeDeviceInstance(8147d2f0,
81370b48, f9c2a89a)+0x40
ee053938 f5a6e0c3 FteImDrv!PtUnbindAdapter(ee053a04, 81370b48,
ee053958)+0x91
ee053a0c f9c2a97d NDIS!ndisUnbindProtocol(813770e8, 81370a48,
8147f8f0)+0x130
ee053a58 f9c3b3f4 NDIS!ndisCloseMiniportBindings(8147f8f0,
8147f8f0, ee053bc4)+0x103
ee053b88 f9c2c17f NDIS!ndisPnPRemoveDevice(8147f7f0, fc295988,
fc295988)+0x1c5
ee053bc4 f9c2cd57 NDIS!ndisPnPDispatch(8147f7f0, fc295a1c,
8147f7f0)+0x229
ee053bd8 8041f79f nt!IopfCallDriver(814dc430, 814dc430,
00000002)+0x35
ee053c04 8049ac37 nt!IopSynchronousCall(8147f7f0, ee053c24,
ee053c54)+0xca
ee053c4c 8049ace8 nt!IopRemoveDevice(814dc430, 00000002,
e133d908)+0x86
ee053c74 804c1925 nt!IopDeleteLockedDeviceNode(8147f7d8, e237d488,
e133d908)+0x24b
ee053cb0 8049c0ec nt!IopDeleteLockedDeviceNodes(814dc430,
e133d900, 00000002)+0xb0
ee053d3c 8051ca18 nt!PiProcessQueryRemoveAndEject(00000000,
80063028, e266ea88)+0x7ac
ee053d54 804b258b nt!PiProcessTargetDeviceEvent(ee053d74,
8113d248, 8046d41c)+0x33
ee053d78 804b249c nt!PiWalkDeviceList(8113d248, 00000000,
00000000)+0xf7
ee053da8 80418dc7 nt!ExpWorkerThread(8113d248, 00000000,
00000000)+0xae
ee053ddc 804553af nt!PspSystemThreadStartup(80418d02, 00000001,
00000000)+0x69
00000000 804695b2 nt!KiThreadStartup(00000000, 00000000,
00000000)+0x16
"Alireza Dabagh [MS]" <al...@online.microsoft.com> wrote in message
news:euVRMKjg...@tk2msftngp13.phx.gbl...
Bryan S. Burgin [MSFT]
re: "2500 lines" did you also include "2 ndis!" as in "!stack 2 ndis!".
This will limit the listing to only stacks that have "ndis!".
Bryan S. Burgin
bbu...@microsoft.com
Bryan S. Burgin [MSFT]
And, I left off the 's', too. Should be: "!stacks 2 ndis!"
Larry Clawson
I posted the stack with Ndis for both when MPHalt is called and when MPHalt
is not called. Can anyone gleem any reason why MPHalt is not being called?
Larry
""Bryan S. Burgin [MSFT]"" <bbu...@online.microsoft.com> wrote in message
news:Jfx%23dAyg...@cpmsftngxa06.phx.gbl...
Alireza Dabagh [MS]
ndis!NdisIMDeinitializeDeviceInstance on it.
You should also look for any thread with ndis on it. you should see
ndis!<function name> listed on the stack dump for that thread.
Please post whatever you find.
Also, could you please do !mopen on the "open block"? in the case below that
would be:
!mopen 85a5f628
-thanks, ali
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Larry Clawson" <larry....@honeywell.com> wrote in message
news:elNQHQs...@TK2MSFTNGP11.phx.gbl...