Ø This is potentially a issue in the speed.sys but yet have to confirm.
Ø As far as I know this issue is extremely rare only happens when you have very high load of serial communication.
Following is the analysis details.
ba79d409 8b480c mov ecx,dword ptr [eax+0Ch] ds:0023:0000000c=????????
Will raised the IRQL to Device IRQL ( 5 here ) to Mask all the interrupt to IRQL such that the function speed!SerialFinishOldWait and ISR ( Interrupt service subroutine ) of that Device are not executed asynchronously. Because ISR as well as speed!SerialFinishOldWait most probably accessing the device registers ( reading and writing to it ). Also interrupt handle should probably be avoid when programming the device.
So the bottom line is when calling speed!SerialFinishOldWait Irql is 5 and no paging and scheduling is enabled. And we will get this bug check if that function try to access any paged locations in the system.
But I was not convinced by above points as the address which was trying to access was 0000000c due to following reason.
Even if the IRQL was 0 which is passive or user mode it would have caused AV - ( which is page fault in kernel mode ). So I went via the following analysis.
8830f050 8830eb10 00000000 00000000 0000304c ..0.........L0..
To go further we need the symbols for speed.sys which is not available externally. Following is what I found from further analysis with internals symbols for speed.sys.I did a dt on the 8830f0f8 and found the field which is going zero. The field happen to be an associate IRP which is zero and the code is not checking if it is null while accessing it.
Now following points worth mentioning.
Ø This is not a IRQL issue.
Ø Although the IRQL is high null reference is the root cause.
Ø If the developer of speed.sys is checking this pointer and after that some other thread is modifying it this is a timing issue. But can be in "other thread"
Ø Otherwise the developer of speed.sys should check the pointer for null before accessing it.