Hi folks,
Any and all suggestions / guesses / inspiration would be welcomed - I’m
a bit stuck.
I’m reluctant to blame MS code when I know that the likelihood is that
I’ve messed up, but I just can’t see how. I hasten to add that all the
code seems to work fine on 99% of our test machines, it’s just some IBM
hyperthreaded dual xeons that appear to be giving traumas.
It looks superficially similar to this problem :
http://support.microsoft.com/default.aspx?scid=kb;en-us;812035
However, I’ve seen it on an XP service pack 2 machine with DirectX 9c,
and a stream.sys with a later date than that mentioned in the KB report.
To reproduce the problem, I have to work the machine fairly hard:
transferring 50 MBit IFrame MPEG on one capture driver at the same time
as 2 uncompressed YUV streams working out at about 40 MByte /second.
Which, depending on the PCI speed & 32/64 bit might be getting a bit
close for slower PCI hardware.
In addition, I can only seem to make it happen on hyperthreaded machines
- turn the hyperthreading off, and it works.
Symptoms: capture minidriver running under stream.sys is capturing two
streams of video.
-
We receive SRB’s to fill with data, and we put them in a queue. - We
check when putting into the queue that:
a) pSrb->NumberOfBuffers is 1.
b) pSrb->CommandData.DataBufferArray[0].Data points to a valid buffer. -
At some point later, we take the SRB out of the queue, and try to
fill it with data. We find that:
a) pSrb->NumberOfBuffers is 1.
b) pSrb->CommandData.DataBufferArray[0].Data is NULL.
Step 2 is done in a worker thread that the minidriver has created (to
workaround a bug with StreamClassCallAtNewPriority, see
http://tinyurl.com/6j9w9 ).
I checked that:
- The minidriver isn’t getting calls to cancel the SRB’s in the queue.
- The mindriver doesn’t play with the data pointer (or any other part
of the SRB) whilst it’s in the Queue. - The minidriver doesn’t play with the data pointer, period.
So, our minidriver decides it can’t really handle this, logs an error,
and returns the SRB to the stream class driver as STATUS_UNSUCCESSFUL.
The stream class driver then chokes in the following manner:
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: f789f018, The address that the exception occurred at
Arg3: f7334c48, Exception Record Address
Arg4: f7334944, Context Record Address
FAULTING_IP:
STREAM!SCProcessCompletedDataRequest+e6
0008:f789f018 8b4010 mov eax,[eax+0x10]
eax=00000000 ebx=86a617a0 ecx=86a142a8 edx=00000000 esi=83c263d8
edi=00000000
STACK_TEXT:
f7334d24 f78a0a73 83c263d8 00000000 86ab9590
STREAM!SCProcessCompletedDataRequest+0xe6
f7334d40 f6d6c73b 00000003 83cc7d58 83c263d8
STREAM!StreamClassStreamNotification+0x5f
f7334d54 f6d6777d 83c263d8 00000003 00000000
!MINI_CompleteStreamSRB+0x6b
f7334d80 f6d7473f 83cc7eac 00000002 86a974d4
!VID_AttemptProcessing+0x1ad
f7334dac 805ce794 86a974c4 00000000 00000000
!WT_ThreadFn+0x21f
f7334ddc 805450ce f6d74520 86a974c4 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
At this point, the contents of SRB and IRP are as follows. (I have a
full memory dump if it will aid debugging).
0: kd> ??*pSrb
struct _HW_STREAM_REQUEST_BLOCK
+0x000 SizeOfThisPacket : 0x83e545e0
+0x004 Command : 1 ( SRB_WRITE_DATA )
+0x008 Status : -1073741435
+0x00c StreamObject : 0x83cc7d58
+0x010 HwDeviceExtension : 0x86a973f4
+0x014 SRBExtension : 0x83c26480
+0x018 CommandData : _CommandData
+0x01c NumberOfBuffers : 1
+0x020 TimeoutCounter : 0xf
+0x024 TimeoutOriginal : 0xf
+0x028 NextSRB : (null)
+0x02c Irp : 0x86a142a8
+0x030 Flags : 3
+0x034 HwInstanceExtension : 0x83e4855c
+0x038 NumberOfBytesToTransfer : 0x83c2640c
+0x038 ActualBytesTransferred : 0x83c2640c
+0x03c ScatterGatherBuffer : 0x83c26494
+0x040 NumberOfPhysicalPages : 0
+0x044 NumberOfScatterGatherElements : 0x83ce8a30
+0x048 Reserved : [1] 0x83c140c0
0: kd> ??pSrb->CommandData.DataBufferArray[0]
struct KSSTREAM_HEADER
+0x000 Size : 0x86a39b98
+0x004 TypeSpecificFlags : 0
+0x008 PresentationTime : KSTIME
+0x018 Duration : 0
+0x020 FrameExtent : 0
+0x024 DataUsed : 0
+0x028 Data : (null)
+0x02c OptionsFlags : 0x200
0: kd> ??*pSrb->Irp
struct _IRP
+0x000 Type : -2288
+0x002 Size : 0x83e0
+0x004 MdlAddress : (null)
+0x008 Flags : 0
+0x00c AssociatedIrp : __unnamed
+0x010 ThreadListEntry : _LIST_ENTRY [0x86a142b8 - 0x86a142b8]
+0x018 IoStatus : _IO_STATUS_BLOCK
+0x020 RequestorMode : 1 ‘’
+0x021 PendingReturned : 0x1 ‘’
+0x022 StackCount : 2 ‘’
+0x023 CurrentLocation : 4 ‘’
+0x024 Cancel : 0 ‘’
+0x025 CancelIrql : 0 ‘’
+0x026 ApcEnvironment : 0 ‘’
+0x027 AllocationFlags : 0x4 ‘’
+0x028 UserIosb : 0x008c34a4
+0x02c UserEvent : 0x86a760a8
+0x030 Overlay :__unnamed
+0x038 CancelRoutine : (null)
+0x03c UserBuffer : 0x008be850
+0x040 Tail : unnamed
0: kd> ??pSrb->Irp->AssociatedIrp
union unnamed
+0x000 MasterIrp : 0x86a617a0
+0x000 IrpCount : -2035935328
+0x000 SystemBuffer : 0x86a617a0
0: kd> ??pSrb->Irp->Overlay
union unnamed
+0x000 AsynchronousParameters : unnamed
+0x000 AllocationSize : _LARGE_INTEGER 0x8c34a4`00000000
0: kd> ??pSrb->Irp->Overlay.AsynchronousParameters
struct __unnamed
+0x000 UserApcRoutine : (null)
+0x004 UserApcContext : 0x008c34a4
0: kd> ??pSrb->Irp->Tail
union__unnamed
+0x000 Overlay : _unnamed
+0x000 Apc : KAPC
+0x000 CompletionKey : 0x00300012
0: kd> ??pSrb->Irp->Tail.Overlay
struct unnamed
+0x000 DeviceQueueEntry : _KDEVICE_QUEUE_ENTRY
+0x000 DriverContext : [4] 0x00300012
+0x010 Thread : 0x869c5824
+0x014 AuxiliaryBuffer : 0x804f484c “j,hH???”
+0x018 ListEntry : _LIST_ENTRY [0x8057f97c - 0x0]
+0x020 CurrentStackLocation : (null)
+0x020 PacketType : 0
+0x024 OriginalFileObject : 0x86b9ab50
MH.
This email and any attachments is confidential, may be legally privileged and is intended for the use of the addressee only. If you are not the intended recipient, please note that any use, disclosure, printing or copying of this email is strictly prohibited and may be unlawful. If received in error, please delete this email and any attachments and confirm this to the sender.