[tocsjung]

First of all, I really thank you for your advices.

I’ve already checked whether ctx->old_handler is NULL or not.
If NULL, I returned STATUS_CONNECTION_REFUSED without calling PTDI_IND_CONNECT.
That is, if(ctx->old_handler == NULL) return STATUS_CONNECTION_REFUSED;

I think that there are structural problems in the tdifw.
Whenever a problem occurs, it aways related with DelayedAcceptConn operation of
the tdifw.
According to the
analysis(http://pennerslife.blogspot.com/2009/04/drvier-crash-dump-analysis.html)
of the problem similar to mine, AcceptIrp had been already freed even though
ClientEventConnect event handler returned STATUS_MORE_PROCESSING_REQUIRED.
AcceptIrp is the last output parameter of the PTDI_IND_CONNECT function.

I wonder that the tdifw isn’t handling STATUS_MORE_PROCESSING_REQUIRED
correctly.
If then, how can I fix the problem?

Next, is the following scenario available?
Before calling PTDI_IND_CONNECT function, I will check the validity of AcceptIrp
by calling MmIsAddressValid function.
If not valid, I will just return STATUS_CONNECTION_REFUSED without calling
PTDI_IND_CONNECT.
That is, if(!MmIsAddressValid(*AcceptIrp)) return STATUS_CONNECTION_REFUSED;
I wonder that this can be a solution to the problem.

Ask advice!

[Author]

Posts