Stream.sys is Stream Class driver written by MS and shipped with Windows.
It has nothing to do with AVStream except that they are both based on KS architecture.
What I don’t understand is that OP says he connected Capture pin to Render pin on the same
instance of the filter. What does it mean?
Stream Class is much more limited than AVStream when it comes down to supported filter topologies.
However the fact that it all works most of the time indicates that this particular topology is
most likely supported and should work fine all the time.
From the bug check data it is almost certain that allocator properties requested by OP on pins are
nonpaged. To OP: make sure that you require buffers from nonpaged pool when providing allocator
requirements.
– Max.
— Mats Petersson wrote:
> Sam,
>
> I didn’t see any reply to this in the 70 odd messages fromt this list this
> morning, but here’s my take on it:
>
> The bugcheck code says it, really: You have accessed a buffer that is either
> not locked (i.e. it can be paged out) or invalid.
>
> In reality, this means that you either used the wrong memory allocation
> flags (didn’t ask for it to be non-pageable) when you allocated the memory
> for the buffer. Or, perhaps, you’re accessing outside the allocated buffer.
>
> You can probably build a check for each of those: Add a little piece of code
> to “check if non-paged”. The easy way to do this is to:
> 1. Add a function to do memory allocation/free.
> 2. In your memory allocation/free function, maintain a list of allocated
> memory and the “non-page” status. Also keep track of size of each
> allocation.
> 3. When you get called in the StreamClassDmaCallback, call a function to
> check the status of the memory allocated. Also pass the offset into the
> buffer and check that it’s within the valid size. If not a valid
> combination, then print error message and stop.
>
> Of course, you may not have the source code for the “stream.sys”, in which
> case you’ll have to track what you send in to Stream.sys instead.
>
> Thinking a bit more about it, it’s unlikely that it’s a “wrong allocation”
> type, it’s more likely that you’re accessing outside the buffer, or that the
> buffer gets de-allocated during the process.
>
> Try using !pool and/or !pte on the memory address. This will show you what
> the status is of the memory that was used. !pool will show who allocated the
> buffer, and what size it is (at least, it will show the tag, which following
> some of the other messages, can be traced back to the original owner). !pte
> will show if it’s a valid address or not.
>
> Best of luck.
>
> –
> Mats
>
> > -----Original Message-----
> > From: Sam Tertzakian [mailto:xxxxx@hotmail.com]
> > Sent: Friday, December 12, 2003 6:38 PM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Stream.sys error when connecting capture pin
> > to render
> > pin on SAME filter
> >
> >
> > Hi,
> >
> > I have a KS Filter driver which exposes a video capture pin
> > and a video render pin.
> >
> > Driver passes all WHQL tests.
> >
> > But when I connect the capture pin to the render pin the
> > driver crashes after a couple of minutes.
> >
> > If I have driver verifier installed this is what I see after
> > a few minutes:
> >
> > ======================================================================
> >
> > BugCheck D1, {a2bf5000, 2, 1, f9954d16}
> >
> > Probably caused by : STREAM.SYS ( STREAM!StreamClassDmaCallback+56 )
> >
> > Followup: MachineOwner
> > ---------
> >
> > nt!RtlpBreakWithStatusInstruction:
> > 80515aa4 cc int 3
> > kd> !analyze -v
> > *********************************************
> >
> > *
> > *
> > * Bugcheck Analysis
> > *
> > *
> > *
> > *********************************************
> >
> >
> > DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> > An attempt was made to access a pageable (or completely
> > invalid) address at an
> > interrupt request level (IRQL) that is too high. This is usually
> > caused by drivers using improper addresses.
> > If kernel debugger is available get stack backtrace.
> > Arguments:
> > Arg1: a2bf5000, memory referenced
> > Arg2: 00000002, IRQL
> > Arg3: 00000001, value 0 = read operation, 1 = write operation
> > Arg4: f9954d16, address which referenced memory
> >
> > Debugging Details:
> > ------------------
> >
> >
> > WRITE_ADDRESS: a2bf5000 Special pool
> >
> > CURRENT_IRQL: 2
> >
> > FAULTING_IP:
> > STREAM!StreamClassDmaCallback+56
> > f9954d16 8908 mov [eax],ecx
> >
> > DEFAULT_BUCKET_ID: DRIVER_FAULT
> >
> > BUGCHECK_STR: 0xD1
> >
> > LAST_CONTROL_TRANSFER: from 8062d1a4 to f9954d16
> >
> > TRAP_FRAME: f9c3fa3c – (.trap fffffffff9c3fa3c)
> > ErrCode = 00000002
> > eax=a2bf5000 ebx=a2bf4ff8 ecx=00057c08 edx=00000000
> > esi=a2bf4a50 edi=810df558
> > eip=f9954d16 esp=f9c3fab0 ebp=f9c3fad4 iopl=0 nv up
> > ei pl nz na pe nc
> > cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> > efl=00010202
> > STREAM!StreamClassDmaCallback+0x56:
> > f9954d16 8908 mov [eax],ecx
> > Resetting default scope
> >
> > STACK_TEXT:
> > f9c3fad4 8062d1a4 81468768 00000000 deadf00d
> > STREAM!StreamClassDmaCallback+0x56
> > f9c3faf8 806a039e 81468768 00000000 00000000 nt!VfAdapterCallback+0x4e
> > f9c3fb24 804e5bfa 814803d8 8146879c 00000051
> > hal!HalAllocateAdapterChannel+0x124
> > f9c3fb3c 8062d831 814803d8 81468768 00000051
> > nt!IoAllocateAdapterChannel+0x28
> > f9c3fb68 f9954fd0 814803d8 81468768 00000051
> > nt!VfAllocateAdapterChannel+0x9f
> > f9c3fb88 f99554c7 81468768 a2bf4a50 9c69ae00 STREAM!SCSetUpForDMA+0x28
> > f9c3fba8 f9959364 00468820 9c69ae00 a2bf4a50
> > STREAM!SCIssueRequestToDevice+0x9f
> > f9c3fbe8 f995c03d 81468820 9b816f90 00000001
> > STREAM!SCProcessDataTransfer+0x1cc
> > f9c3fc30 f9537a95 81468768 a3f80f00 f9c3fc64
> > STREAM!StreamDispatchIoControl+0xab
> > f9c3fc40 f9955859 81468768 a3f80f00 81468768 ks!KsDispatchIrp+0xa3
> > f9c3fc64 804e6185 81468768 a3f80f00 8069d454
> > STREAM!StreamClassPassThroughIrp+0xef
> > f9c3fc74 80624d10 a3f80fd4 a3f80ff8 8147b2f0 nt!IopfCallDriver+0x31
> > f9c3fc98 8062eee5 8147b238 81373040 80510e00 nt!IovCallDriver+0x9e
> > f9c3fca8 804e6185 8147b238 a3f80f00 8069d454
> > nt!ViDriverDispatchGeneric+0x27
> > f9c3fcb8 80624d10 814005a8 a3f80f00 80510e38 nt!IopfCallDriver+0x31
> > f9c3fcdc f9533006 9c80afb0 9b816f58 00000000 nt!IovCallDriver+0x9e
> > f9c3fcf0 f9957b99 8147b238 9b816f68 00000000 ks!KsStreamIo+0x160
> > f9c3fd50 f9957c11 9c80ae00 00000000 f9534ac0 STREAM!IoWorker+0x135
> > f9c3fd5c f9534ac0 9c80ae00 81080f78 80541000 STREAM!IoWorkerRead+0xb
> > f9c3fd74 8052089e 81080f78 00000000 81560020 ks!WorkerThread+0x1e
> > f9c3fdac 805a2ec8 81080f78 00000000 00000000 nt!ExpWorkerThread+0xfe
> > f9c3fddc 8052c6a2 805207a0 00000000 00000000
> > nt!PspSystemThreadStartup+0x34
> > 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
> > ==============================================================
> > ==========
> >
> > In my driver I have turned off synchronization. Besides this
> > problem there are no other issues and everything works.
> >
> > This problem occurs both when I connect capture to render on
> > the same instance of the filter, or if I create two instances
> > of the same filter in GraphEdt.
> >
> > Is there a problem in my code or is having render and capture
> > pin on same filter not supported in non AVStream model?
> >
> > Thank you for your help
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@yahoo.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/