As noted in the comments, the usermode program cannot invoke the bluescreen screen. Only a kernel-level component can invoke a BSOD. Most likely, it happens that your program accidentally sends data in a certain way that the network driver cannot process, and that causes the BSOD. This is not your program. All kernel drivers must use protective programming methods. Therefore, if a BSOD occurs, this leads to a driver failure. This is one of the main features of the kerenel / usermode separation. It is assumed that usermode cannot do anything that can BSOD in a field.
I understand that the above tip does not always help when you are just trying to fix a problem. Therefore, it would be best to open a dump in windbg and run -v analysis. This will give you a reasonable stack trace (for unmanaged code) and you will see which driver is causing this problem.
If you want to know which thread caused this problem, I'm afraid of your SOL. In principle, it is impossible to know exactly which thread caused this problem, because most likely the packet was stuck in the queue and then processed later. By the time the BSOD box, the thread that queues the packet has already left and done other things.
But if you are super lucky and all the stars are aligned, perhaps you can still have the stream in the same place where the packet was placed in the queue, and you can see if windbg uses SOS dll.
A reasonable helper for getting started with managed debugging with windbg is here: http://blogs.msdn.com/b/alejacma/archive/2009/07/07/managed-debugging-with-windbg-introduction-and-index. aspx
This will not answer all your questions, but it is a decent start and a search on Google, you will get most of the time.