I install my NDIS IM driver on a laptop that has an intel wireless adapter
and pretty soon it starts blue screening. When I check the crash dump there
is nothing in it about my driver ... the crash is happening inside the NIC
driver (s24trans.sys)

How on earth do I debug this? Even though it is not my driver that crashes,
my driver must be partially responsible, because the other driver only begins
to crash when mine is installed. I've thought about the idea of installing a
checked build of xp on the crashing system and then hopefully the crash dumps
might contain more information ... but ultimately I'll still be staring at a
bunch of assembler written by MS or Intel!

Any ideas?

"mirage2k2" wrote:
S24trans.sys is not the NIC driver, it is a NDIS protocol installed
by some Intel utility, perhaps to send custom OIDs to the miniport.
So your IM sits between the miniport and this protocol
and does something that makes it crash.
You can remove it by unchecking "WLAN Transport" in the connection
properties and see what will crash next

Good luck,
--PA

"mirage2k2" <mirage2k2@discussions.microsoft.com> wrote in message
news:B3EA9D7D-AA40-4A44-8738-FD5EFCA04983@microsoft.com...
Tough one...

Often the debugger stack trace lists the NDIS calls that were being made
that led up to the crash. Sometimes these give a clue as to what "area"
(send, receive, requests) that is related to the crash.

Have you run NDIS tester on your driver? Often this will flush out defects
that you may have overlooked in your own testing.

Have you run DriverVerifier against your driver during its operation?
DriverVerifier can sometimes provide additional insight into operations that
could lead to a crash.

You probably do not need the complete checked build to debug this. Get the
checked version of Ndis.sys and install it on the free build (Be sure to
stash the free version somewhere. Read about System File Protection...). The
DDK tells how to turn on NDIS debugging features.

When a driver developer says "starts blue screening", then most of us on the
list know that you haven't really done your part of the work. Specifically,
you need WinDbg attached to the system instead of debugging dumps
post-mortem.

Good luck,

Thomas F. Divine, Windows DDK MVP
http://www.pcasua.com