This is a bit off-topic for this group, but there’s enough streaming
expertise here that maybe someone will have encountered it.
When Microsoft dropped the very useful default TWAIN wrapper for
AVStream devices in Vista, my clients complained, because their clients
were using that wrapper extensively. So, I wrote my own. It’s a TWAIN
data source that supports nearly any arbitrary web camera, although I
now artificially limit it to the client’s devices.
The data source creates and runs a simple DirectShow graph (camera to
decoder to sample grabber to standard renderer). It’s been working well
for many years. Recently, however, a client noticed a problem: if he
does a whole bunch of TWAIN grabs in one session, he starts running out
of resources. It turns out that the DirectShow graph is leaking threads
and handles.
I’m confident that my code is releasing all of the COM objects
properly. In those few cases where I can’t use CComPtr, I’m extra
careful. I’ve added trace code to monitor the reference counts, and
they all go neatly down to 0, on all of the filters and the graph
itself. When each grab is done, my entire data source DLL is properly
unloaded from memory, so I’m not even around any more. But after each
run, there are two dangling threads: one in
quartz!CBaseReferenceClock::AdviseThread, and one in
ksproxy!CKsQualityForwarder::QualityThread, both waiting infinitely on
events… The AVStream capture driver (which I also wrote) does grab a
reference to the master clock, but it gets released on the transition to
“stop” state, and I get the same result even if I don’t grab the clock.
Making it even worse, these threads do not ALWAYS leak. In maybe 1 in
10 tries, it will only leak one thread. One in 20 tries, it doesn’t
leak any. That implies a timing issue of some kind.
Now, I’m a fairly good hacker, but I’m not sure where to go next. Any
bright ideas?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.