Как отмечается в комментариях, программа пользовательского режима не может вызывать синий экран.Только компонент уровня ядра может вызвать BSOD.Наиболее вероятно, что ваша программа отправляет данные определенным образом, который сетевой драйвер не может обработать, и это вызывает BSOD.Это не ошибка ваших программ.ВСЕ драйверы ядра должны использовать защитные методы программирования.Так что, если происходит BSOD, это ошибка драйверов.Это одна из основных особенностей разделения kerenel / usermode.Пользовательский режим не должен делать что-либо, что может BSOD.
Я понимаю, что приведенный выше совет не всегда полезен, когда вы просто пытаетесь решить проблему.Поэтому лучше всего открыть дамп в windbg и запустить! Analyse -v.Это даст вам разумную трассировку стека (для неуправляемого кода), и вы сможете увидеть, какой драйвер вызывает проблему.
Если вы хотите увидеть, какой поток вызвал проблему, я боюсь, что ваш SOL.По сути, невозможно точно определить, какой поток вызвал проблему, поскольку, скорее всего, пакет был помещен в очередь, а затем обработан позднее.К тому моменту, когда окно BSOD укажет, что поток, помещающий пакет в очередь, уже отключился и занялся другими делами.
Но если вам очень повезло, и все звезды соединились, то, возможно, у вас может бытьпоток все еще находится в том же месте, в котором он помещал пакет в очередь, и вы можете увидеть, используете ли windbg с dll SOS.
Разумный помощник для начала работы с управляемой отладкой с помощью windbg находится здесь: http://blogs.msdn.com/b/alejacma/archive/2009/07/07/managed-debugging-with-windbg-introduction-and-index.aspx
Это не ответит на все ваши вопросы, но это неплохое начало, и поиск в Google поможет вам большую часть оставшегося пути.