I’m making a filter that uses TreatAs to hook an existing IBaseFilter derived filter using the same approach as your example (load lib, reflect calls, etc.), and it all works great as long as I return the inner filter’s IBaseFilter (and its base interfaces) when queried (all other queries are passed to the inner object).

With an access violation during destruction, the most likely cause is reference counting. You should probably see how you are destroying your object and then receive another call on its interface. And when you return original IBaseFilter you probably don’t have any reflecting code remained, other than instantiation and QueryInterface. Are you aggregating the filter you are hooking? Basically BaseClasses are not 100% COM compliant (they are coming from long ago and nobody cared to fix this compliance since then).

So if you are aggregating, the might be some [small] issues in COM aggregation compliance, and if you are not aggregating, or the filter you are hooking does not support aggregation, then you must hook all interfaces of interest so that you never expose original one, including those of pins.

The difference between applications might be in an order of calls. For example, some application can obtain pin’s interface and then through it get owner filter interface and keep it so that it is released the last. If you are not aggregating, this can lead to situation when you already have no interface pointers outstanding and your filter is destroyed, while application still hold a reference to your inner object.

Also, why does your CSpy reflect the IMediaControl interface? Is this just to get more info, or is there another reason?

It is not essential to hook this interface for ROT stuff, but additionally to ROT the spy logs all graph calls to log file and here is where it is also convenient to log IMediaControl method calls: Run, Stop etc.

I.e. this works:
…
COM_INTERFACE_ENTRY_FUNC(IID_IBaseFilter, NULL, CFilter::GetBaseFilter)
COM_INTERFACE_ENTRY_AGGREGATE_BLIND(m_pInnerUnknown)
…
static HRESULT WINAPI GetBaseFilter(void* pv, REFIID riid, LPVOID* ppv, DWORD dw) throw()
{
CFilter* pFilter = reinterpret_cast(pv);
*ppv = m_pInnerBaseFilter;
return S_OK;
}

But if I return the reflecting IBaseFilter interface when queried, it works fine in GraphStudio and GraphEdit, but crashes in WMPlayer when the graph is released.

I.e. this doesn’t work:

…
COM_INTERFACE_ENTRY(IBaseFilter)
COM_INTERFACE_ENTRY(IMediaFilter)
COM_INTERFACE_ENTRY(IPersist)
COM_INTERFACE_ENTRY_AGGREGATE_BLIND(m_pInnerUnknown)
…

// reflected interface methods…
STDMETHODIMP EnumPins(IEnumPins **ppEnum)
{ return m_pInnerBaseFilter->EnumPins(ppEnum); }

… etc.

In both cases, I’m using the same mechanism to load and query the interface on the inner filter object in FinalContruct:

CComQIPtr pBaseFilter = pUnknown;
pBaseFilter.p->Release();

m_pInnerUnknown = pUnknown;
m_pInnerBaseFilter = pBaseFilter;

It look like a refcount is off, but I’ve tried bumping the counts to avoid a delete, and it still crashes. Btw, when I bump the counts, GraphEdit reports unreleased objects.

Do you have any insights as to why the filter might work fine in one app, but not in another?

Also, why does your CSpy reflect the IMediaControl interface? Is this just to get more info, or is there another reason?

Several of your projects include “roatltrace.h” your replacement for . Where is this file, or what are the differences between yours and the original?

This my file I never yet published.

however I can no longer debug my direct show components with visual studio I have tried unregistering filter spy. Does any one have an idea how I can get the debugger to atache to the running graph again?

regsvr32 /u FilterGraphSpy.dll

from command line, then try to delete file (if it is still locked, reboot and delete after that). If this does not help, you have other issues in your system that result in your inability to debug.

I can’t find some heaher file when I compiled the “FilterGraphSpy”.
Such as (#include “roatlbase.h”
#include “roatlvariants.h”
#include “roatlcom.h”
#include “roatlpersist.h”
#include “roatlmisc.h”
#include “roatlexceptionfilter.h”
#include “rowtlapp.h”
#include “rowtlcrack.h”
#include “rodialogs.h”
#include “rocontrols.h”)

Where can I find these files. Can you help me.

I have not published them, please use binary – it is also in SVN.

First of all, I wanna thank you
for ur help to solve some of my prbs with Seeking

Do I need to do anything extra to make my filter seek for windows media player
coz my filter is performing well for other players
but for windows Media player its not performing the seeking operations
can U guide me regarding this?

other players are seeking
bt windows media player is not performing
I tried to debug it
bt when I seek the control never goes into those methods
what could be the reason?

First of all, Windows Media Player might be inserting another filter, which other players don’t insert, and this breaks WMP seeking. You can see WMP’s filter graph using my Filter Graph Spy utility.

A second possible reason is that you don’t fully (for some reason) implement seeking, in which case you should have some weird method called on your filter, what other players don’t do. Or – another interface is queried from your filter, you don’t implement it and return E_NOINTERFACE and that’s all, you don’t receive other calls.

i’ve just read your post on graph spy

it really sounds very useful

however i’m not shure how to use it

i’ve regsvr32 it, but i haven’t figure it out how use it with other apps’s graphs

Yes you need to regsvr32 and from this point all new filter graphs should be available on running object table so that you connect to them as to remote graphs using GraphEdit

no additional steps are needed ?
i’ve started some applications and graph edit doesn’t detect any remote graph

maybe rebooting the machine ?

I don’t think so, but there is another possible cause. Did you at all see any remote graphs using Graph Edit? After upgrading to XP SP3 you might need to run “regsvr32 quartz.dll” to get the ability for GraphEdit to see remote graphs back again

yes, i have some of my own apps with a ROT reference. If i remove the ROT reference from my code i’m still unable to reach the remote graph

ok, so try regsvr32 quartz.dll from windows\system32 folder and see it this is helpful for both my dll and your apps

ok. btw, i forgot to mention that i’m using Vista SP1

if you can’t see your own graphs with graphedit through ROT, then there is definitely some problem… as for my dll, except for ROT you can check generated log file in C:\ProgramData (this is hidden dir) if you see it’s populating then my dll is intercepting filter graph instantiations

2009-01-29 12:28:01 0700 4184 dllmain.h(29): CFilterGraphSpyModule::CFilterGraphSpyModule: this 0×63b6327c
2009-01-29 12:28:01 0700 4184 Spy.h(53): CSpy::UpdateRegistry: bRegister 1
2009-01-29 12:28:04 0700 4184 dllmain.h(33): CFilterGraphSpyModule::~CFilterGraphSpyModule: this 0×63b6327

this is the log from your dll

I have executed apps several times and i believe it only logged twice. I regsvr32ed quartz.dll and i believe it made no diference. I guess it isn’t populating..

OK, there may be something different on Vista (I am using XP but I was pretty sure it is the same way on Vista) or wrong with the system since you don’t see remote graphs
BTW you need to regsvr32 from elevated admin command prompt (this is to make sure).

yes,i did it on an admin console. I going to try on XP…

ok, i installed your dll on a xp system, executed SDP download, still can’t access the remote graph, however the FilterGraphSpy.log is diferent

2009-01-29 17:50:13 13684 13576 dllmain.h(29): CFilterGraphSpyModule::CFilterGraphSpyModule: this 0×0098327c
2009-01-29 17:50:13 13684 13576 Spy.h(53): CSpy::UpdateRegistry: bRegister 1
2009-01-29 17:50:14 13684 13576 dllmain.h(33): CFilterGraphSpyModule::~CFilterGraphSpyModule: this 0×0098327c
2009-01-29 17:51:57 14080 13896 dllmain.h(29): CFilterGraphSpyModule::CFilterGraphSpyModule: this 0×00de327c
2009-01-29 17:51:57 14080 13896 Spy.h(75): CSpy::CSpy: this 0×00e03d78
2009-01-29 17:51:57 14080 13896 Spy.h(142): CSpy::EnumFilters: …
2009-01-29 17:52:11 14080 13896 Spy.h(79): CSpy::~CSpy: this 0×00e03d78
2009-01-29 17:52:11 14080 13864 dllmain.h(33): CFilterGraphSpyModule::~CFilterGraphSpyModule: this 0×00de327c
2009-01-29 17:52:48 13716 13772 dllmain.h(29): CFilterGraphSpyModule::CFilterGraphSpyModule: this 0×0098327c
2009-01-29 17:52:48 13716 13772 Spy.h(53): CSpy::UpdateRegistry: bRegister 0
2009-01-29 17:52:49 13716 13772 dllmain.h(33): CFilterGraphSpyModule::~CFilterGraphSpyModule: this 0×0098327c

e.g. there is “CSpy::EnumFilters: …” which means that it actually worked
there is no other way for these lines to appear in the log other than if the graph is hooked by my dll and it is intercepting all filter graphs

BTW if you run MEdia Player Classic, it also publishes its graph on ROT
and with my DLL you will have two entries there, both point to the same graph

ok
on the xp system i don’t have the wmp classic installed,
i have the 11.0.57. version only
i’m reaching the remote graph with graphedit
i don’t quite know if this your dll responsability
i guess not
your log remains the same