Published by Roman on 08 Feb 2010
This quick update for DirectShow Filter Graph Spy adds tracing for (deprecated) IAMFilterData interface, and also fixes problem with Media Player Classic – Home Cinema, when the player crashes in External Filters windows.
Partial Visual C++ .NET 2008 source code is available from SVN, release binary included (Win32, x64); installation instructions are in another post.
Published by Roman on 24 Dec 2009
DirectShow Filter Graph Spy was updated to add new functionality: spying over another DirectShow object – Filter Mapper. Filter Mapper object is used for filter registration purposes and also internally by DirectShow’s Intelligent Connect. IFilterMapper2 interface traces provide detailed description on steps DirectShow takes in order to connect and/or render filter pins. For example when trying to render MEDIATYPE_Audio pin, Filter Mapper suggested “RDP DShow Redirection Filter” and, then, “Default DirectSound Device”:
FilterMapperSpy.h(186): CFilterMapperSpy::EnumMatchingFilters: nFlags 0x0, bExactMatch 0, nMinimalMerit 0x00200001, bInputNeeded 1, nInputTypeCount 1, pInputPinCategory NULL, bRender 1, bOutputNeeded 0, nOutputTypeCount 0, pOutputPinCategory NULL FilterMapperSpy.h(191): CFilterMapperSpy::EnumMatchingFilters: nInputTypeIndex 0, MajorType {73647561-0000-0010-8000-00AA00389B71}, Subtype {00000000-0000-0000-0000-000000000000} FilterMapperSpy.h(212): CFilterMapperSpy::EnumMatchingFilters: pMoniker @device:sw:{083863F1-70DE-11D0-BD40-00A0C911CE86}\{AB9D6472-752F-43F6-B29E-61207BDA8E06} FilterMapperSpy.h(220): CFilterMapperSpy::EnumMatchingFilters: sFriendlyName "RDP DShow Redirection Filter", sDescription "", sDevicePath "" FilterMapperSpy.h(212): CFilterMapperSpy::EnumMatchingFilters: pMoniker @device:cm:{E0F158E1-CB04-11D0-BD4E-00A0C911CE86}\Default DirectSound Device FilterMapperSpy.h(220): CFilterMapperSpy::EnumMatchingFilters: sFriendlyName "Default DirectSound Device", sDescription "", sDevicePath ""
Important is that DirectShow’s internals are using the mapper through COM instantiation and this provides a safe method to override default behavior process wide in order to, for example, extend Intelligent Connect functionality onto custom, unregistered globally, private filters.
Also, the binary is renamed from FilterGraphSpy.dll to DirectShowSpy.dll.
Partial Visual C++ .NET 2008 source code is available from SVN, release binary included (Win32, x64); installation instructions are in another post.
Published by Roman on 01 Nov 2009
Today’s update for DirectShow Filter Graph Spy introduces 64-bit version (mind the beta state) and a mini-API for an external module to be involved into graph building process.
Filter Graph Spy is offering three new interfaces that provide extensibility of the spy:
The interfaces are contained in the type library and can be imported using #import directive. An implementation of one or more of these interfaces will receive hook style calls corresponding to respective Filter Graph Manager calls, system wide including in context of other applications.
A COM object may be registered as a hook object with Spy and NoThreadSpy COM classes under predefined registry keys:
Spy will instantiate the registered hook objects and forward them the calls it receive, before passing them to system Filter Graph Manager object. A hook object has an option to override default processing, including, for example, inserting its own filter in between. For example, IFilterGraph::Reconnect call is implemented the following way:
STDMETHOD(Reconnect)(IPin* pPin) throw() { _Z4(atlTraceCOM, 4, _T("...\n")); HOOK_PROLOG(CFilterGraphConnectHookHost) OnReconnect(pT, pPin, &bDefault); HOOK_EPILOG() return m_pInnerFilterGraph2->Reconnect(pPin); }
Before passing the call to original Reconnect method, spy is iterating through associated hooks, passing them IFilterGraphConnectHook::OnReconnect call. Setting bDefault parameter to FALSE will prevent spy from passing the call to original method.
Included BdaHooks project shows a sample implementation of the hooking COM classes (note .rgs registration).
Filter Graph Spy is compatible with all current Windows operating systems, 32-bit and 64-bit (x64), in particular including:
NOTE: DirectShow Filter Graph Spy is NOT suitable for production environment, it is NOT licensed to be redistributed to be a part of production state software item.
Partial Visual C++ .NET 2008 source code is available from SVN, release binary included (Win32, x64); installation instructions are in another post.
Published by Roman on 06 Oct 2009
Having hard time to connect to remote filter graph on Windows 7 machine, I suspected that some of the filters do not like being connected through marshaling and freeze. Or, actually more likely, it is SDK’s proppage.dll which hosts proxy stub pairs behaves itself in a not quite expected way and freezes remote application (Graph Edit or similar) during attempt to connect to remote graph.
As the goal was to find out details about connection media types between the filters being spied over, the spy received a new feature of logging graph details each time the graph is going to running state:
Filter 7: Name "[1BDADev]", Class {17CCA71B-ECD7-11D0-B908-00A0C9223196}, State 2
Pin 1: Name "MPEG2 Transport", Direction "Input", Peer "[0BDATnr].MPEG2 Transport"
Connection media type:
majortype {E436EB83-524F-11CE-9F53-0020AF0BA770}, subtype {E06D8023-DB46-11CF-B4D1-00805F6CBBEA}, pUnk 0x00000000
bFixedSizeSamples 0, bTemporalCompression 0, lSampleSize 1
formattype {8DEDA6FD-AC5F-4334-8ECF-A4BA8FA7D0F0}, cbFormat 24, pbFormat 0x00350868
[0x0000] BC 00 00 00 38 9A 00 00 00 00 00 00 00 00 00 00
[0x0010] 00 00 00 00 00 00 00 00
Pin 2: Name "MPEG2 Transport", Direction "Output", Peer "Infinite Pin Tee Filter[BDATsIft].Input"
Connection media type:
majortype {E436EB83-524F-11CE-9F53-0020AF0BA770}, subtype {F4AEB342-0329-4FDD-A8FD-4AFF4926C978}, pUnk 0x00000000
bFixedSizeSamples 1, bTemporalCompression 0, lSampleSize 39480
formattype {0F6417D6-C318-11D0-A43F-00A0C9223196}, cbFormat 0, pbFormat 0x00000000
Filter 8: Name "[0BDATnr]", Class {17CCA71B-ECD7-11D0-B908-00A0C9223196}, State 2
Pin 1: Name "Input0", Direction "Input", Peer "Microsoft Network Provider[NwPvd].Antenna Out"
Connection media type:
majortype {71985F41-1CA1-11D3-9CC8-00C04F7971E0}, subtype {E436EB8E-524F-11CE-9F53-0020AF0BA770}, pUnk 0x00000000
bFixedSizeSamples 0, bTemporalCompression 0, lSampleSize 1
formattype {0F6417D6-C318-11D0-A43F-00A0C9223196}, cbFormat 0, pbFormat 0x00000000
Pin 2: Name "MPEG2 Transport", Direction "Output", Peer "[1BDADev].MPEG2 Transport"
Connection media type:
majortype {E436EB83-524F-11CE-9F53-0020AF0BA770}, subtype {E06D8023-DB46-11CF-B4D1-00805F6CBBEA}, pUnk 0x00000000
bFixedSizeSamples 0, bTemporalCompression 0, lSampleSize 1
formattype {8DEDA6FD-AC5F-4334-8ECF-A4BA8FA7D0F0}, cbFormat 24, pbFormat 0x00350868
[0x0000] BC 00 00 00 38 9A 00 00 00 00 00 00 00 00 00 00
[0x0010] 00 00 00 00 00 00 00 00
Partial Visual C++ .NET 2008 source code is available from SVN, release binary included; installation instructions are in another post.
Published by Roman on 23 Jul 2009
There was a question asked about how IAMGraphBuilderCallback interface is used to prevent from particular filter insertion during Intelligent Connect.
First of all, there is sample code at The March Hare’s website:
The IAMGraphBuilderCallback class can be used to remove problematic dshow filters when building a graph with intelligent connect. This sample does not provide the UI to blacklist filters but will give you a better head start than the information in the documentation. See the header file for an example of how to use it in your code. Add your own code to the SelectedFilter or CreatedFilter methods to remove any unwanted filters.
The idea behind the method can be easily illustrated with a code snippet. Each time Filter Graph Manager considers trying a filter, before its instantiation it calls (if provided) IAMGraphBuilderCallback::SelectedFilter method, where there is an option to reject it (before it even was instantiated using CoCreateInstance).
The code snippet below checks selected filter and instructs to reject it if it is an FFDshow Audio Decoder filter.
// IAMGraphBuilderCallback STDMETHOD(SelectedFilter)(IMoniker* pMoniker) throw() { ATLTRACE(atlTraceCOM, 4, _T("...\n")); _ATLTRY { ATLASSERT(pMoniker); const CStringW sMonikerDisplayName = _FilterGraphHelper::GetMonikerDisplayName(pMoniker, NULL); ATLTRACE(atlTraceGeneral, 4, _T("sMonikerDisplayName %ls\n"), sMonikerDisplayName); static const LPCTSTR g_pszFfdshowAudioDecoderClassIdentifier = _T("{0F40E1E5-4F79-4988-B1A9-CC98794E6B55}"); if(sMonikerDisplayName.Find(CStringW(g_pszFfdshowAudioDecoderClassIdentifier)) >= 0) return E_FAIL; // Die! } _ATLCATCH(Exception) { return Exception; } return S_OK; }
Published by Roman on 22 Jun 2009
I have been receiving comments that Filter Graph Spy tool does not work with Microsoft Vista operating system. I never had a moment to check until recently, and this time I realized that it really does not work. I am definitely aware of dramatic changes introduced with this operating system, and in particular UAC feature, virtualization and changes in security. No wonder this was the first guess that security was the cause, however the investigation showed there was a trail of issues underneath…
Investigation details deserve a separate post, while this one briefly outlines the issues and also accompany the repository update with a version compatible with Vista OS.
First of all, COM registration of the DLL (which definitely requires privilege elevation) succeeded on Vista. This means the registration procedure did not encounter any errors on the way, or poorly written code ignored the problem. It appeared that the source of the problem was CoTreatAsClass API, which failed to do the requested action, however returned status code indicating successful operation. This definitely looks like a bug and further comments on this particular behavior are expected to appear on Windows Applications Security MSDN forum, where I opened a topic on the matter.
With a COM TreatAs feature activated, the class’s behavior to instantiate instead of DirectShow’s CLSID_FilterGraph is restored, and in particular the DLL generates FilterGraphSpy.log log file on filter graph activity. Note that log file location is OS dependent (due to Vista’s permissions and file system virtualization):
Still even with the log file generated and indicating activation of the spy, it was unable to connect to remote graph through the running object table (ROT). It appeared that the ROT entires are there where expected, it was OK to get an object from ROT and the problem came from QueryInterface code:
CComPtr<IUnknown> pFilterGraphUnknown; ATLENSURE_SUCCEEDED(pRunningObjectTable->GetObject(pMoniker, &pFilterGraphUnknown)); CComQIPtr<IMyFilterGraph> pFilterGraph = pFilterGraphUnknown; // E_NOINTERFACE
The call reached the original object but COM subsystem was unable to marshal the interface through apartments to enable interprocess communication on it. The reason for this is absence of PSFactoryBuffer class (CLSID {92A3A302-DA7C-4A1F-BA7E-1802BB5D2D02}), which provides proxy/stub pairs for marshaling well known DirectShow interfaces in the Vista’s version of quartz.dll. As mentioned by Microsoft’s Mike Wasson, this class was moved from quartz.dll into Vista SDK’s proppage.dll, so in order to obtain connectivity to remote DirectShow graphs starting Vista, one needs to install this DLL with Windows SDK, or otherwise have it registered with the operating system.
Also note that DirectShow-enabled applications that have their filter graphs published on ROT will need an utility application such as GraphEdit started with the same permissions (elevated or not) in order to be able to access ROT entires.
A partial Visual C++ .NET 2008 source code is available from SVN, release binary included.
Published by Roman on 11 Jun 2009
With a lot of DirectShow Filter Graphs published on Running Object Table, especially those automatically published by Filter Graph Spy utility, it might be a bit tricky to locate your graph of interest in the list.
Filter graphs are published with a textual moniker item name of predefined format, which is recognized by GraphEdit or GraphStudio, or similar utilities as an item corresponding to a filter graph. A template for such a string is “FilterGraph %08x pid %08x“, which obviously only contains raw pointer address and process identifier, which only help a bit in looking up for proper graph interactively. However, it is important how exactly applications are recognizing filter graph related names. For example, GraphStudio does it the following way:
rot->EnumRunning(&emon); emon->Reset(); while (emon->Next(1, &moniker, &f) == NOERROR) { // is this a graph object ? LPOLESTR displayname; moniker->GetDisplayName(bindctx, NULL, &displayname); CString name(displayname); if (name.Find(_T("!FilterGraph")) == 0) {
The items that match are then listed in GUI with an original string, which means that it is possible to provide an informational suffix to be able to locate the graph in a more convenient way, e.g. with a process image name, not only identifier (”; process: …” was appended to the item name):
GraphEdit is using another method and is more strict in selecting among available items. AFAIR earlier versions did not allow custom suffixes in item names, however the latest version still picks the items up from the global list. However, GraphEdit does not show graph’s original item name, so suffixes are merely useless with GraphEdit.
Filter Graph Spy utility was updated to automatically append process name suffix, which should be OK for both GrapEdit and GraphStudio. Still, the feature can be disabled through registry DWORD value named “Enable ROT Moniker Item Name Suffix” under HKEY_LOCAL_MACHINE\SOFTWARE\Alax.Info\Utilities. The value of zero, or missing, is the default behavior to enable suffixes. The value of 1 disables the feature, the value of 2 makes sure it is enabled.
static CConstIntegerRegistryValue g_nEnableRotMonikerItemNameSuffix(_T("Enable ROT Moniker Item Name Suffix")); // 0 Default, 1 Disable, 2 Enable if(g_nEnableRotMonikerItemNameSuffix != 1) { TCHAR pszPath[MAX_PATH] = { 0 }; _W(GetModuleFileName(NULL, pszPath, DIM(pszPath))); CString sItemName = AtlFormatString(_T("%s; process: %s"), m_RunningFilterGraph.GetDefaultMonikerItemName(GetControllingUnknown()), FindFileName(pszPath)); m_RunningFilterGraph.SetFilterGraph(GetControllingUnknown(), CStringW(sItemName)); } else m_RunningFilterGraph.SetFilterGraph(GetControllingUnknown())
A partial Visual C++ .NET 2008 source code is available from SVN, release binary included.
