It's not a C/Asm forum and I think this is of very little interest to most folks here, but you're seemingly keen and I love to prattle so why not...
The answers to most of your questions stem from the distinction between privileged (ring 0, "kernel-mode") and non-privileged (ring 3, "user-mode") operation. The code running in ring 0, including low-level portions of the OS and many drivers, exist only to do the bidding of the various user-mode apps. To do that, they frequently need data supplied by the app, such as for example the name of a file which is to be opened.
If an app crashes in user-mode, no big deal as far as the other apps are concerned. They just continue to run. Kernel-mode crashes are much more serious because they take out everything, and thus kernel-mode code has to be very careful to protect itself against being fed bad data by an app. As a simple example, if an app indicates that the contents of a file are to be copied to a particular buffer, and that memory pointer is bogus (a zero maybe), the entire OS could crash if the interface between user-mode and kernel-mode failed to detect the bad memory pointer being supplied. That would be considered an OS bug - it failed to protect itself against non-privileged code - even though the bad pointer was supplied by the app. The self-protection mechanism works like one of those security drawer devices in banks... you put the documents into a steel tray which the teller then slides over to their side and examines in safety before deciding whether it all looks OK and whether they should therefore fulfill your request.
For performance reasons, that kind of error checking is minimal in between the various components in kernel-mode. It's all considered privileged code and it had better be good, because it would simply cost too many processor cycles to continuously validate every bit of info passed from one driver to another. The machine would crawl. Hence, it's up to every computer owner/administrator to be judicious about what they install on their machine,
especially if the package they're installing contains one or more kernel-mode drivers.
uTorrent does not contain kernel-mode code. It's an app which calls Winsock APIs in the OS, and they in turn make the U/K transition down to the AFD.SYS Winsock driver. Hence, almost by definition uTorrent and other similar apps cannot cause a BSoD. (If an app runs with admin privileges it can theoretically sink a driver down into kernel-mode to do its bidding, but that's beside the point.)
On to !analyze. It's not perfect. Although it does an excellent job of trying to guesstimate the cause of a crash, there is SO MUCH complexity down there, and crashes can happen in so many ways - including paths which wipe out most traces of the culprit, that it cannot possibly hope to always be right. In fact, even the best driver developers/debuggers on Earth cannot always find the root cause of every crash from looking at a crash dump. Take dump 03 as an example. There's no prizes for figuring out the direct cause of the crash:
2: kd> .trap fffffa60`068f2270
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa60068f25d8 rbx=0000000000000000 rcx=fffffa8007632c70
rdx=fffffa60068f2498 rsi=fffff80001faf160 rdi=fffffa600432dd98
rip=fffffa6004335f18 rsp=fffffa60068f2400 rbp=fffffa60068f2498
r8=0000000000000001 r9=0000000000000006 r10=0000000000000001
r11=0000000000000014 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
afd!AfdGetTransportInfo+0x28:
fffffa60`04335f18 ff158281feff call qword ptr [afd!_imp_ExEnterCriticalRegionAndAcquireResourceShared (fffffa60`0431e0a0)] ds:3180:fffffa60`0431e0a0=000000000006316e
2: kd> ln .
(fffffa60`04335ef0) afd!AfdGetTransportInfo+0x28
The OS crashed because afd!AfdGetTransportInfo attempted to gain shared access to a critical region protected by a synchronisation mechanism. There was a CALL to a memory address stored at fffffa60`0431e0a0, and since we're running in kernel-mode at the time that function pointer must reference more kernel-mode code, except in this case it doesn't:
2: kd> dd fffffa60`0431e0a0 l2
fffffa60`0431e0a0 0006316e 00000000
It points to 0x6316e and that is a completely invalid address somewhere up in user-mode. Was AFD the driver which crashed the box? Absolutely. Is it responsible for the breakdown? Almost certainly not, because all it did was to CALL to an offset which is expected to contain a legit pointer, but that memory had been corrupted before AFD got there. Tracing things back to the real culprit can be fun and frustrating, and even impossible, sometimes all at the same time.
In the second dump the same type of breakdown manifests itself as a DEP error, but that's again a side-effect rather than the cause. It just so happens that the bad pointer in the second crash was into a region of kernel-mode memory tagged as NO_EXECUTE, so instead of BSoDing because of a wild pointer to user-mode, the OS crashed because DEP stepped in and said "no-no, you can't execute that". The original bad memory reference is the problem, not the DEP kicking in post factum.
Trust me, it's almost certainly SYMTDI in this case
I have tried few things so far, 
Jackal
.