It is a stack overflow. It is not related to the depth of the stack. It
happen because one particular function consumed most of the stack space.

f6ed4cd8 f6e47c16 f8105bc4 f6ed4d18 00000001
NDIS!ethFilterDprIndicateReceivePacket+0x1a0
f6ed6d20 f6e671b6 804f4e72 00000000 00000000 spm!FlushRxPacketQueues+0x1c6
[f:\projects\shoutdev\spm\spm.c @ 1280]

The most left numbers shows the stack address. This call consumed f6ed6d20 -
f6ed4cd8 = 0x2048 bytes out of 0x3000 bytes available.

Alexei.

"Hannes" <hannes@nospam.nospam> wrote in message
news:9455B5CB-FC81-45DB-B679-48F75170EDA6@microsoft.com...
(50 levels deep), why I assume this is a "stack overflow" crash. Am I
correct on that?
packet, and it wreaks such havoc on the system.
appears to be involded in the stack trace.
***
***

Thanks, that was the kind of clue I needed. I was not aware the first column shows the stack addresses. My last function does indeed allocate several kilobytes on the stack, which obviously is bad practice. I will correct by allocationg/freeing heap memory instead.

Thanks for you help,

/ Hannes.