David,
Thank you for pointing my mind in right direction, I have found the
issues with code in
MiniportQueryInformation, the IM passed down incoming request by
performing NdisRequest,
than NdisRequest return NDIS_STATUS_ADAPTER_NOT_FOUND or other
unsuccessful status,
then I have called NdisMQueryInformationComplete and return indicated
invalid status from
MiniportQueryInformation. But I must return NDIS_STATUS_PENDING when
performing
asynchronous request completion.
I have found that this subject is not so clear in DDK documentation.
And another amazing things that this code worked w/o any fault in other
situation, when missed some
OID or request failed. But crash cured only on resuming from hibernate
or standby mode.
Anyway thank you for pointing me to right direction.
PS: It's was hard for us to find some computers with com port to debug
such issue. Hope 1394 will
work on vista and later system w/o such problem.
Best regards,
Andrew Rukavishnikov
Sunbay Innovations Ltd.
David R. Cattley пишет:
Andrew,
It's a crash. The system is trying to access some address. The address is
either some bit of information that was returned by your driver, stomped on
by your driver, or incorrectly freed by your driver.The NDIS Request mechanism should not be blowing up because an OID request
returns an error. More than likely, it is because your IM driver is not
handling the error correctly (or not handling requests correctly in
general).Connect a live debugger with a serial port (because resuming from
hibernation is rather a PITA to debug over firewire) and get a live crash.
Go pick through the trace output from your IM driver and correlate the
address that causes the exception to some value or side-effect of your
driver processing the request.It sucks. It might be hard. You might need to set a couple of break-points
so that you can step through the most interesting of the requests. You
might want to look at how your IM driver handles request completion (since I
can see from your debug output that sometimes the requests come back
NDIS_STATUS_PENDING and sometimes they do not).But really, nobody but you can figure this out from that debug output. I
have no idea what your code looks like and at what point that debug output
is being generated in the nominal request processing flow. That is the
thing about instrumentation, without sharing with us lots of details about
where it is 'plugged in', well, it frankly is not all that useful to the
outside observer.Based on the output, however, it looks as if your IM driver 'filters' both
the request presentation and completion. Since this request appears to be
failing 'synchronously' I am going to guess that your code calls the
completion 'filtering' synchronously from the 'presentation' filtering in
that case. Look carefully at what you do here. Make sure you don't both
complete the request and return a non NDIS_STATUS_PENDING result from
MiniportQueryInformation(). That tends to result in the caller's request
structure being freed by the completion routine and then referenced by the
calling activity. Sort-of what might be happening with your situation.Also, I see some evidence that you might have a 'thread' involved. Make
sure you are properly synchronizing its interaction. NDIS5 Miniports are
'synchronized' by internal NDIS locking and have specific rules for
NdisRequest() processing and completion. Don't break the rules. Bad stuff
happens.Lastly, IM drivers in particular have some rough edges with respect to power
state management. Since I can see from the debug output that your driver
appears to be written as C++ classes, I am guessing that it's lineage from
PASSTHRU is, well, rather stretched. Making sure that you handle the
Protocol edge PnP notifications correctly is pretty important.