I see below bugcheck when my protocol is trying to make an OID call (using the same thread that NDIS used to indicate an NBL to my miniport).
I will next run with verifier
Also I see a lock version of ndis in ndisMDispatchReceiveNetBufferListsWithLock.
Not sure if this is the same lock that NDIS is spinning on when I make the OID call?
Anyways will try to issue the OID from a PASSIVE worker thread to see if that ‘workarounds’ the problem.
See miniport OID state as well.
I guess NDIS serializes OIDs at the miniport; i.e. if the first
OID is stuck, we won’t get a better response by queuing another OID behind the
first.
But from protocol I do not know if a miniport is in such state.
Looking into miniport as well to see what below OID dump means, is any OID stuck or just processing normally.
Also there seems to be standard MS filter between my protocol and miniport.
Not sure what it means here. Will try disabling that as well?
ALL PENDING OIDs
Miniport fffffa80187d41a0 - NIC1
Current OID OID_TCP_OFFLOAD_PARAMETERS
Queued OIDs OID_GEN_MEDIA_CONNECT_STATUS
Filter fffffa8010b74c80 - NIC1-WFP Native MAC Layer LightWeight Filter-0000
Current OID OID_TCP_OFFLOAD_PARAMETERS
Filter fffffa800e2fcbf0 - NIC1-QoS Packet Scheduler-0000
Current OID OID_TCP_OFFLOAD_PARAMETERS
Queued OIDs OID_GEN_STATISTICS
–
DPC_WATCHDOG_VIOLATION (133)
The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL
or above.
Arguments:
Arg1: 0000000000000000, A single DPC or ISR exceeded its time allotment. The offending
component can usually be identified with a stack trace.
Arg2: 0000000000000283, The DPC time count (in ticks).
Arg3: 0000000000000282, The DPC time allotment (in ticks).
Arg4: 0000000000000000
If I am interpreting above link correct, looks like OID_ TCP_ OFFLOAD__PARAMETERS is taking long time (and NDIS will issue a **RESET** soon).
But not sure how that resulted in a DPC_WATCHDOG_VIOLATION BSOD.
Debuuging more and will update.
Thx
NIC1
Ndis handle fffffa80187d41a0
Ndis API version v6.30
Adapter context fffffa8018800000
Miniport driver fffffa800b489bc0 - my_miniport v0.0
Network interface fffffa80071faa50
Media type 802.3
AUTOMATIC DIAGNOSTICS
This miniport will operate in a slow path until 9 more protocol(s) bind, or
until a 30-second timeout expires.
STATE
Miniport Running
Device PnP Started Show state history
Datapath Normal
Interface Up
Media Connected
Power D0
References 0n15 Show detail
User handles 1
Total resets 0
Pending OID OID_TCP_OFFLOAD_PARAMETERS
Flags BUS_MASTER, 64BIT_DMA, SG_DMA, DEFAULT_PORT_ACTIVATED,
SUPPORTS_MEDIA_SENSE, DOES_NOT_DO_LOOPBACK,
MEDIA_CONNECTED
PnP flags PM_SUPPORTED, DEVICE_POWER_ENABLED, RECEIVED_START,
HARDWARE_DEVICE
More flags PROCESSING_REQUEST, REQUEST_TIMEOUT
This issue repro rate is very rare.
From problem reprot it seems this happens only after fresh ghost and during the first install after that.
Have made a change to send my OID from a passive thread (but due to above difficult repro, doesn’t mean anything if it doesn’t reprobut I guess atleast means sending OID down from a dispatch level thread is not excasbeating the issue.)
Will also do verifier on suggested components.
>Looks like the miniport spinlock is taken, and NDIS is trying to take it again.<<
Pls can you eloborate on this ‘miniport lock’.
Is it anything like below
“there is a per miniport slock that ndis creates. NDIS took it as part of pkt indication to my_protocol. Then when my_protocol made the OID call in that same thread context, NDIS tried to take that same miniport_lock?..”