IM Driver Crash at system startup by Mark
Mark
Thu Jul 03 11:09:29 CDT 2003
Ken,
Ah, by "queue it up", do you mean that you don't indicate
it up when you receive it? But do so later? If that's the
case, I think you need to do some special handling of the
Buffers linked to the packet descriptor. I guess this
depends on what value your ProtocolReceivePacket()
funciton returned to NDIS.
Look at the comment in the sample\mux\driver receive
indicate handling. It says you need to copy the buffers,
and the DDK man-page seems to suggest the same.
Is your queue handling a code-path only taken during
init? Or do you always queue packets prior to indicating
them?
That might explain why ndis doesn't like your
buffer ... ? (I.e. it can't determine the eth_header?).
>-----Original Message-----
>G'Day,
>
>Is your IM driver somehow injecting the packet into the
>receive-path and so indicating up a "made-up"
>ndis_packet? Or is it a packet that the underlying
>miniport has received and indicated up to you?
>
>Is this an NDIS5.0 driver? Or 5.1? Or ... ?
>
>Either way, if it normally works, then you are probably
>getting the re-packaging or packet-stack usage correct.
>
>I'm not sure exactly what you mena by "put it in a
queue"
>and indicate it up. Are you managing this queue OK? Even
>early on in the init stages of your driver?
>
>If it crashes during reboot (I assume you have a kernel
>stack trace and can see which funtions it crashes in),
is
>it possible that your IM driver is getting packets
>indicated from below, before you've actually got a
handle
>to indicate packets up on? I.e. are you passing in a
>valid MiniportAdapterHandle to NdisMIndicateReceive()?
>
>Are you using Verifier on your IM driver? Are you using
>Verifier on your underlying Miniport? Are you using
>Verifier on ndis.sys? It might provide additional info.
>to help you inestigate further.
>
>Are you using a Checked ndis.sys? It might more
>constructively complain rather than crashing if your IM
>driver passes it something it doesn't like ... ?
>
>If you place a breakpoint -- bu, not bp, not clicking-on-
>the-source-code line (so that the break point
>shouldstick over driver loads) at where you pass up the
>packet that leads to the crash you can manually verify
>that handle and packet look OK ...
>[[actually, I still don't trust the stick breakpoints,
so
>when debugging init-time stuff in my IM driver, I still
>place a DbgBreakPoint() in my IM's DriverEntry()and when
>I hit it set the breakpoints that I want (source-window
>or just bu/bp]]
>
>If you've already tried all that, then I don't know else
>to suggest ...
>
>~Mark
>
>>-----Original Message-----
>>I am writing a IM driver which put received packets
into
>>a queue and indicates it up. Most of the time it runs
>>fine but it seems that when I have the driver installed
>>and reboot it, it crashes when at
>>NdisMIndicateReceivePacket when I am trying to indicate
>a
>>UDP packet.
>>
>>I havent got much clue on this, I have looked at
>NDIS.com
>>and it says something about the first buffer have to
>>describe MAC Header and LookaheadData. How can I find
>>these?
>>
>>.
>>
>.
>