The intall process of NDIS IM driver hangs in vista sp1
in [Device Drivers]
|
Prev: WAN IM Driver between PPP and AsynMAC
Next: How to query Win32_PhysicalMemory instances using WMI in the kernel.
From: lgonhia on 5 Jan 2009 22:19 Description: OS: Windows Vista SP1 enviroment: A process(called ProtocolBind) binds a protocol dirver to the adapter which is not binded by it. The ProtocolBind process check the adapters in the system every 1 second. Action: When install the passthru process, the intall process of passthru (which is a sample NDIS IM driver) hangs and the CPU usage is 100%. I find that there is a endless loop in ndisCloseMiniportBindingsForPause+0x287 The call stack is ChildEBP RetAddr 884d0a9c 85b8db40 ndis!ndisCloseMiniportBindingsForPause+0x287 (FPO: [Non-Fpo]) 884d0b38 85b99568 ndis!ndisPnPNotifyAllTransports+0x2de (FPO: [Non-Fpo]) 884d0bbc 85b99c2d ndis!ndisHandleProtocolUnbindNotification+0x25a (FPO: [Non-Fpo]) 884d0bd8 85b89650 ndis!ndisHandleUModePnPOp+0x10e (FPO: [Non-Fpo]) 884d0c0c 85b892be ndis!ndisHandlePnPRequest+0x319 (FPO: [Non-Fpo]) 884d0c2c 81908053 ndis!ndisDispatchRequest+0x8a (FPO: [Non-Fpo]) 884d0c44 81a98515 nt!IofCallDriver+0x63 884d0c64 81a98cba nt!IopSynchronousServiceTail+0x1d9 884d0d00 81a8298e nt!IopXxxControlFile+0x6b7 884d0d34 818a3a7a nt!NtDeviceIoControlFile+0x2a 884d0d34 77da9a94 nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 884d0d64) 0012e350 77da8444 ntdll!KiFastSystemCallRet (FPO: [0,0,0]) 0012e354 76c3c2a3 ntdll!ZwDeviceIoControlFile+0xc (FPO: [10,0,0]) 0012e3b4 7412c2bb kernel32!DeviceIoControl+0x14a (FPO: [Non-Fpo]) 0012e41c 7410c66e netcfgx!NdisHandlePnPEvent+0x1d5 (FPO: [Non-Fpo]) 0012e478 7410cb7b netcfgx!HrPnpBindOrUnbind+0xa6 (FPO: [Non-Fpo]) 0012e8b0 74103ad3 netcfgx!CRegistryBindingsContext:: PnpBindOrUnbindBindPaths+0x126 (FPO: [Non-Fpo]) 0012eae8 74104ace netcfgx!CModifyContext:: ApplyChanges+0x9c2 (FPO: [Non-Fpo]) 0012eafc 74104bb4 netcfgx!CModifyContext:: HrApplyIfOkOrCancel+0x2d (FPO: [Non-Fpo]) 0012eb04 74105c14 netcfgx!CModifyContext:: HrPopRecursionDepth+0x20 (FPO: [Non-Fpo]) 0012eb18 740f6cc2 netcfgx!CModifyContext:: HrInstallNewOrReferenceExistingComponent+0xac (FPO: [Non- Fpo]) 0012eb38 74105523 netcfgx!CImplINetCfg:: SelectWithFilterAndInstall+0xfa (FPO: [Non-Fpo]) 0012eb58 0043d6d0 netcfgx!CImplINetCfgClass:: SelectAndInstall+0x29 (FPO: [Non-Fpo]) There is a simple method to reproduce it 1,Install wireshark (you can find it with google) 2,run the following command in a BAT file :: goto the install path of wireshark :loop dumpcap -i AdapterName -a duration:100000 -w output.pcap goto loop 3,Install the passthru (which is a sample NDIS IM driver in DDK) The install process hangs Thank you
From: lgonhia on 5 Jan 2009 22:37 There is a simple method to reproduce it 1,Install wireshark (you can find it with google) 2,run the following command in a BAT file :: goto the install path of wireshark :loop dumpcap -i AdapterName -a duration:100000 -w output.pcap goto loop 3,Install the passthru (which is a sample NDIS IM driver in DDK) The install process hangs
From: lgonhia on 5 Jan 2009 23:25 So What will do to avoid this hang if bind a protocol driver in windows vista sp1? Thank you "lgonhia" wrote: > There is a simple method to reproduce it > > 1,Install wireshark (you can find it with google) > > 2,run the following command in a BAT file > > :: goto the install path of wireshark > > :loop > dumpcap -i AdapterName -a duration:100000 -w output.pcap > goto loop > > 3,Install the passthru (which is a sample NDIS IM driver in DDK) > > > The install process hangs > > >
From: David R. Cattley on 7 Jan 2009 10:36 NDIS relies on the cooperation of protocols to process PnP Notifications and honor ProtocolUnbind() requests promptly. It would be my guess that some protocol in the system (in your original case) is not cooperating. Perhaps it is the protocol you mention in the first post (the one your program is binding to adapters in the 1 second polling loop). You do not mention how this process "ProtocolBind" is functioning. Is it using INetCfg interfaces or doing something else? If this process thinks it is being clever and bypassing the INetCfg (NETCFG) mechanisms for *managing* bindings, then, it could easily create confusion in the system since it is not synchronizing 'control' of the NDIS bindings with NETCFG. Consider that NETCFG has asked NDIS to pause a miniport so that it can make some binding change (to insert the IM between the miniport and other bound protocols). Your "ProtocolBind" process is continuously adding a binding back. If this is occurring outside the synchronization of NETCFG's lock, then, NDIS might end up in a continuous loop. Now with respect to the test case you posted using Wireshark performing repeated continuous capture - perhaps the author of WinPCAP will offer an explanation. But that does not seem to be your real problem. Is the "ProtocolBind" process your code? If so, how does it 'bind' adapters to 'the protocol'? What 'protocol' is "ProtocolBind" binding adapters too? Is that protocol your code? Does that protocol properly process PnP notifications (from NDIS) and promptly unbind when requested? Good Luck, Dave Cattley Consulting Engineer Systems Software Development
From: lgonhia on 8 Jan 2009 21:08
Thanks for your answer. The ProtocolBind is my code. It is works well in windows 2K,XP,2k3. It is not using the INetCfg interfaces .It calls the NdisOpenAdapter directly (as the wireshark). The ProtocolBind processed the PnP notifications (from NDIS) and promptly unbind when requested. My question : 1,It must use NETCFG to bind a protocol driver? 2,If it doesn't use the NETCFG ,how to improve the binding process. Thank you. "David R. Cattley" wrote: > NDIS relies on the cooperation of protocols to process PnP Notifications and > honor ProtocolUnbind() requests promptly. It would be my guess that some > protocol in the system (in your original case) is not cooperating. Perhaps > it is the protocol you mention in the first post (the one your program is > binding to adapters in the 1 second polling loop). > > You do not mention how this process "ProtocolBind" is functioning. Is it > using INetCfg interfaces or doing something else? If this process thinks > it is being clever and bypassing the INetCfg (NETCFG) mechanisms for > *managing* bindings, then, it could easily create confusion in the system > since it is not synchronizing 'control' of the NDIS bindings with NETCFG. > Consider that NETCFG has asked NDIS to pause a miniport so that it can make > some binding change (to insert the IM between the miniport and other bound > protocols). Your "ProtocolBind" process is continuously adding a binding > back. If this is occurring outside the synchronization of NETCFG's lock, > then, NDIS might end up in a continuous loop. > > Now with respect to the test case you posted using Wireshark performing > repeated continuous capture - perhaps the author of WinPCAP will offer an > explanation. But that does not seem to be your real problem. > > Is the "ProtocolBind" process your code? > If so, how does it 'bind' adapters to 'the protocol'? > What 'protocol' is "ProtocolBind" binding adapters too? > Is that protocol your code? > Does that protocol properly process PnP notifications (from NDIS) and > promptly unbind when requested? > > Good Luck, > Dave Cattley > Consulting Engineer > Systems Software Development > > > > |