Здравствуйте, Zoya_Pobeda, Вы писали:
Вы так и не написали ни место где произошел BSOD, ни даже его кода. Кроме того, Вы скорее свего не включали Driver Verifier — а он мог бы показать более точную причину ошибку. Поэтому, придется угадывать причину ошибки. Конечно мы попробуем

, но это может продолжать очень долго.
Итак, первая возможная причина.
1. В коде ф.ServerWorkerThread есть такие строки:
pIrp = TdiBuildInternalDeviceControlIrp(TDI_ACCEPT,
Context->pTDIClient->pTcpDevObj,
Context->pTDIClient->pTDIClnConnArr->pConnFileObj,
&Context->pTDIClient->pTDIClnConnArr->AccEvent,
&IoStatus
);
Context->pTDIClient->pIrpAccept = pIrp;
Это Вы загодя создаете Irp. Причем этот объект довольно хитрый — он связан с очередью потока, поскольку TdiBuildInternalDeviceControlIrp — всего лишь макрос-оболочка над IoBuildDeviceIoControlRequest ( обязательно читаем описание!!! ). Теперь, мы принимаем входящее соединение ( ф.TDISrvEventConnect ) и производим с Irp некое действие:
TdiBuildAccept(pDevExt->pIrpAccept,
pDevExt->pTcpDevObj,
pLclConn->pConnFileObj,
TDIClnIoCompRtnAcc,
pDevExt,
pClientConn,
NULL
);
Я так понял, что pIrpAccept это Irp, созданный вызовом TdiBuildInternalDeviceControlIrp? Тогда с ним поступили довольно нехорошо — подменили процедуру завершения, указанную при создании и контекст. При этом на мой взгляд все, что происходит дальше — это неопределенное поведении и BSOD не удивителен. Что нужно было сделать? Нужно было в ф.TDISrvEventConnect создать собственный Irp простым вызовом IoAllocateIrp и инициализировать его через макрос TdiBuildAccept. В ф. TDIClnIoCompRtnAcc — освободить через вызов IoFreeIrp, там же взвести нотифицирующее событие.