NdisMIndicateStatus issue on Windows 8 Customer Preview

NTDEV
1

Hello everyone,

I have a problem with NdisMIndicateStatus function on Windows 8.

From a Windows service I am sending an IOCTL to a NDIS driver in order to indicate media connection of a virtual network adapter. The issue is that, in most of the cases, Windows 8 fails to be notified about the adapter state change. The virtual adapter appears as being disconnected, when displaying IP addressing information with ipconfig command. I never had this issue happen on Windows 7 or Vista.

My Windows service starts automatically, i.e. startup type is “Automatic”, and the above issue appears if the IOCTL is sent just after Windows logs in. But if the service is delayed started, i.e. startup type is “Automatic (Delayed Start)”, then the adapter’s state successfully changes into “media connected”.

I know that on Windows 8 CP there are changes of the automatically started services list, or optimizations regarding unused started services, and I’m guessing that this could generate my issue but I didn’t found a proof to confirm my suspicions.

I am calling NdisMIndicateStatus function, when receiving the IOCTL from the service, as below:

VOID SetMediaStatus ( PADAPTER p_Adapter, BOOLEAN state )
{
if ( p_Adapter->m_MediaState != state )
{
if ( state )
NdisMIndicateStatus ( p_Adapter->m_MiniportAdapterHandle, NDIS_STATUS_MEDIA_CONNECT, NULL, 0 );
else
NdisMIndicateStatus ( p_Adapter->m_MiniportAdapterHandle, NDIS_STATUS_MEDIA_DISCONNECT, NULL, 0 );

NdisMIndicateStatusComplete ( p_Adapter->m_MiniportAdapterHandle );

p_Adapter->m_MediaState = state;
}
}

Any help is greatly appreciated.

Thanks!

2

NDIS doesn’t know about usermode. It doesn’t know anything about usermode services, and it doesn’t know when you log in. So NDIS isn’t blocking or dropping any status indications based on when you log in or what type of usermode service you use.

Therefore, it’s probably something more mundane. Set up a kernel debugger and set a breakpoint on SetMediaStatus. Check if it’s being called at all. Perhaps the usermode service start is racing with miniport enumeration/initialization. Or perhaps the usermode service is hitting some unrelated failure if it starts too early during boot.

3

Thanks Jeffrey for your reply.

I did a kernel debug and the SetMediaStatus function is called correctly, but I don’t know why the adapter’s state isn’t changing.

I don’t think that the service is racing with miniport enumeration/initialization, because the request to change the adapter into connected state comes from a GUI application to the service and then the service sends an IOCTL to the NDIS driver. So, by the time the request is made from GUI, the service is started and the driver is loaded. Even if the GUI request is repeated, there is no change in the adapter’s state.

I also debugged the usermode service and there is no issue there either. The request is passed to the NDIS driver as it should, but on Windows 8 the adapter stated is not changed into connected state and on Windows 7, the exact code manages to change the adapter’s state into connected.

I observed that if the Windows service is restarted then the request is successful, otherwise it fails. Any ideas?

4

Is your virtual adapter driver built as an NDIS5 or NDIS6 miniport? If you unbind & rebind any LWF that happens to be bound (there are always a couple) to your adapter using BindView or the properties dialog for the adapter, does it ‘fix’ the issue? Are their any NDIS5 style Intermediate (IM) drivers installed on your system and bound to your adapter? Good Luck,Dave Cattley

5

Hi David! My driver is a NDIS5 miniport driver. I disabled and re-enabled the virtual adapter from device manager, but nothing changed. The Windows 8 CP machine that I’m testing is fresh and there is no NDIS IM drivers installed on it.

6

My Win8 test system seems to have a couple of LWF drivers bound by default. What happens if you unbind “QoS Packet Scheduler” (for example). Does pausing & starting the filter stack suddenly make NDIS6 recognize that your NDIS5 (virtual) adapter is connected? Also, are you responding to OID_GEN_MEDIA_CONNECT_STATUS queries in MiniportQueryInformation()? Good Luck,Dave Cattley

7

I took a closer look at the query requests that arrive to my miniport driver and saw that the OID_GEN_MEDIA_CONNECT_STATUS query came just after calling NdisMIndicateStatus function. So the driver reported the previous connect status, which was disconnected, because the state assignment was done after the NdisMIndicateStatus call; see the above code in the SetMediaStatus function.

After moving the adapter state assignment before NdisMIndicateStatus function call, the problem disappeared. Now the MiniportQueryInformation function is called after NdisMIndicateStatus, but the new adapter state is already set, and the MiniportQueryInformation function returns the correct value.

On Windows 7 the OID_GEN_MEDIA_CONNECT_STATUS query arrive at a later time, when the new adapter state was already set.

Thanks a lot David and Jeffrey for your answers. It helped me a great deal.