I am having an intermittent problem with an NDIS Intermediate driver
binding. I used the passthru example as the base for my driver and used
snetcfg to create an install program.
Sometimes, the driver will not bind that is no packets are seen in the send
or receive functins of the intermediate driver but there is lots of network
traffic and the management application can open a driver object that is
created when the miniport initialize function is called. When the problem
occurs I uninstall and reinstall the driver from the connection manager and
everything works fine - packets are seen in the send and receive functions.
Any ideas what could be causing this?
Thanks in advance.
Regards,
Michael Wright
Rappore Technologies, Inc.
I know of one issue where PASSTHRU may seem to have a binding problem, but
it doesn't match your description. The situation I am aware of is when an
unsigned PASSTHRU driver is already installed and then you add a new
adapter. When an unsigned PASSTHRU is first installed, you will get
several messages (depending on your "ignore/fail/warn" setting for unsigned
drivers) about the driver not being signed and to verify if you want to
continue. However, if you add a new adapter and PASSTHRU is already
installed, an unsigned PASSTHRU will not be automatically bound. If you go
into that adapter's network properties, you will see PASSTHRU checked - to
indicate that it is a valid binding partner - but it will not be bound
unless you press Ok.
If the above occurs, you will see the following message in setupapi.log:
#I124 Doing copy-only install of "ROOT\MS_PASSTHRUMP\0002".
#-011 Installing section [PassthruMP.ndi] from "c:\windows\inf\oem14.inf".
#E358 An unsigned or incorrectly signed file "c:\windows\inf\oem14.inf" for
driver "Passthru Miniport" blocked (server install). Error 1168: Element
not found.
#E122 Device install failed. Error 1168: Element not found."
This is a known issue, is by design and the resolution is to sign the IM
driver.
There is a self-signing procedure for NDIS IM drivers. Documentation is
available at
http://download.microsoft.com/download/whistler/Install/1.0/NT5XP/EN-US/NDIS
_IM_Driver_Self_test.exe. The document came out last summer and there may
be updates to the procedure that you can contact WHQL about at
whq...@microsoft.com.
Again, I recognize that this doesn't exactly fit your description. If this
isn't your issue, you might expand the verboseness of setupapi logging to
0x00006060 and checking to see if any messages appear in the log
(Windows\setupapi.log). Search for "setupapi.log" in the DDK search panel
for more information on Setting SetupAPI Logging Levels.
Hope this helps.
Bryan S. Burgin
bbu...@microsoft.com
This posting is provided "AS IS" with no warranties, and confers no rights.