 <p>You've definitely hit across an interesting problem with WinPcap. Its protocol driver (NPF) expects to be able to open an adapter whenever it wants. When paired with Wireshark, it will do this frequently &mdash; it's typical to see NPF open and close the same adapter dozens of times just while the Wireshark GUI is loading. It's even possible to see NPF have multiple bindings to the same adapter <em>simultaneously</em>.</p> <p>The rough equivalent of this in NDIS 6.x is the <code>NdisReEnumerateProtocolBindings</code> function. What this does is queue up a workitem to call into your protocol' <code>ProtocolBindAdapterEx</code> handler for each adapter that is marked as bound in the registry, but isn't currently bound in NDIS. (I.e., for each adapter that INetCfg finds a bindpath to that does not already have an open handle.)</p> <p>However, due to the large impedance between NPF's API and how NDIS regards binding, you'll need to tackle a few issues:</p> <ol> <li><p><strong>Multiple simultaneous bindings to the same adapter</strong>. (This is a rarely-used feature; NPF is one of two protocols that I know use this, so it's not really discussed much in the MSDN documentation.) The only way to get multiple simultaneous bindings in NDIS 6.x is to call <code>NdisOpenAdapterEx</code> twice <em>within the same <code>ProtocolBindAdapterEx</code> call</em>. That's going to be challenging, because NPF's model is to open a new binding whenever an API call comes in from usermode; it doesn't know in advance how many handles will need to be opened.</p> <p>If another bind request comes in, you can attempt to close all previous handles to that adapter (transparently to the NPF API[!]), call <code>NdisReEnumerateProtocolBindings</code>, then open N+1 handles in your upcoming <code>ProtocolBindAdpaterEx</code> handler. But this is brittle.</p> <p>You can also try and merge all API calls to the same adapter. If a second bind request comes in, just route it to the pre-existing binding to that adapter. This might be difficult, depending on how NPF's internals work. (I'm not allowed to read NPF source code; I can't say.)</p> <p>Finally, the cheesy solution is to just allocate two (or three) binding handles always, and keep the extras cached in case Wireshark needs them. This is cheap to implement, but still a bit fragile, since you can't really know if Wireshark will want more handles than you pre-allocated.</p></li> <li><p><strong>Missing <code>INetCfg</code> bindings</strong>. NDIS 5.x protocols are allowed to bind to an adapter even if the protocol isn't actually supposed to be bound (according to <code>INetCfg</code>). Wireshark uses this to get itself bound to all sorts of random adapters, without worrying too much about whether <code>INetCfg</code> agrees that NPF should be bound. Once you convert to NDIS 6.x, the rules are enforced strictly, and you'll need to make sure that your protocol's INF has a <code>LowerRange</code> keyword for each type of adapter you want to bind over. (I.e., the NPF protocol should show up in the Adapter Properties dialog box.)</p></li> <li><p><strong>Asynchronous bindings</strong>. The <code>NdisReEnumerateProtocolBindings</code> model is that you call it, and NDIS will make an attempt to bind your protocol to all bindable adapters. If the adapter isn't bindable for some reason (perhaps it's in a low-power state, or it's being surprise-removed), then NDIS will simply not call your protocol back. It's going to be tough to know exactly when to give up and return failure to the usermode NPF API, since you don't get a callback saying "you <em>won't</em> bind to this adapter". You may be able to use <code>NetEventBindsComplete</code>, but frankly that's kind of a dodgy, ill-defined event and I'm not convinced it's bulletproof. I'd put in a timeout, then use the NetEvent as a hint to cut the timeout short.</p></li> </ol> <p>Finally, I just wanted to note that, although you said that you wanted to minimize the amount of churn in WinPcap, you might want to consider repackaging its driver as an NDIS LWF. LWFs were designed for exactly this purpose, so they tend to fit better with NPF's needs. (In particular, LWFs can see native 802.11 traffic, can get more accurate data without going through the loopback hack, and are quite a bit simpler than protocols.)</p>