How to investigate NDIS Test Protocol Drivers assertions

WINDBG
1

HLK failing NDISTest6.0 - Mini6Send triggering BSOD.
From stack it is obeserved that ndprot630 assertion is hitting.
what is the proper way to investigate ndprot630 assertion.
HLK verification driver threads not showing much information why this assertion is trigger in NDprot driver.
Tried to check pending OIDs, NBLS using !ndiskd.netadapter.

Stack:
nt!KiBreakpointTrap+0x311
NDProt630!CNDTKeLog::NDTKeDoAssertion+0xd2
NDProt630!CNDTSimpleSendCommMgr::SendAtPassive+0xbaNDProt630!CNDTCommunicationManager::WorkerThreadCallBackRoutine+0x67
nt!PspSystemThreadStartup+0x55
nt!KiStartSystemThread+0x28

2

Not familiar with this driver or these tests, but presumably there's an error message along with the assert?

3

Hi Scott,
After exploring HLK logs and other logs. NDIS test protocol drivers is expecting to complete the sent or recived packets within specific time. if it is not completed its asserting. The time it is expecting and during crash times details not captured in logs as expected. if I connect debugger test always fails due delay in processing. and also test is not failed always.

from code point of view trying to optimize code. but overall its tedious to map code to for optimization.

4

Sounds painful...

Is there NO debug output before the ASSERT?

5

Hi Scott, HLK logging not much helpful. its two machine test server and client with two network interfaces created. observed server is crashing due assert but issue is with client, at point client is not accessible due to with server is ASSERTED.
following steps.

  • CPU usage monitored.
  • WPRUI ran on client machine.
  • Perfmon tools also running.
  • One instance force crash when cpus hogging.
  • There is driver glitch two dpc we created one is normal DPC other is threaded DPC. in threaded DPC we raised and lower IRQL other DPC thought other as normal DPC and keep adding packets sync issue seen. due to which cache memory keep on allocated made VM inaccessible to outside world.
  • started with ping when it stopped even PCs are not crashed. :slight_smile:
6

I was thinking that there would be debugger output from the machine before the ASSERT. This wouldn't show up anywhere but an attached kernel debugger (or !dbgprint from the crash dump if you're lucky).

And was the DPC thing "the problem" or are you still having issues after fixing that?

7

Hi Scott after converting Threaded DPC to normal DPC issue not seen. Kernel debugger attaching not showing more information about crash. According to ASSERT test is failed due to specific time test is not completed, it is waiting for send completion.

In this issue Client is not reachable after sometime due to our driver issue.

1 Like