Fooling Around

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):

• pre-Vista OS: root of syste drive, typically C:\
• starting Vista, administrator with elevated privileges: CSIDL_COMMON_APPDATA, typically C:\ProgramData (note this directory is hidden by deafult)
• starting Vista, without elevated administrator privileges: CSIDL_LOCAL_APPDATA, typically C:\Users\$(UserName)\AppData\Local (note that AppData directory is hidden by deafult)

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.

In order to obtain a reference audio source and especially useful for debugging purposes, including:

• audio input device unrelated to physical device, to avoid conditions when device is already in use by someone else
• non-zero audio signal which is independent of certain speaker or broadcasting service, including one that makes capture, transmission or rendering issues easily perceptible by human
• configurable to provide different audio media types, including through well known DirectShow interfaces, such as IAMStreamConfig
• configurable to present in system as both regular DirectShow Filter, and as an Audio Capture Source which can be enumerated by applications
• to be able to check how exactly other applications are accessing and configuring audio capture source

I added a new filter to the Media Tools library, a Tone Source Filter. The filter generates PCM Audio data, either infinite sine waveform, or interrupted signal  of requested parameters:

The filter accepts connection on PCM media types with flexible sampling rates in range 8 KHz through 200 KHz, 8-bit audio and 1 channel. Media type is also configurable through or, if not configured this way, the first enumerated media type off the Output pin is also configurable through property page and/or persistent setting accessible via private IDispatch derived interface property.

Additionally, the filter may configured as a system-wide available audio input device, such as for example available to VLC Media Player or Media Player Classic:

In order to configure the filter as such device, the library exports function DoToneSourceFilterDevicePropertySheetModal, which can be called using rundll32 utility (“rundll32 Acquisition.dll,DoToneSourceFilterDevicePropertySheetModal” from command line):

A partial Visual C++ .NET 2008 source code is available from SVN, release binary included.

File and Class Summary

Acqusition.dll

Acqusition.dll (download) hosts the following classes:

• DirectShow Filters
  • Tone Source Filter, to generate reference/debug audio data

Class Overview

Tone Source Filter

The filter generates uninterrupted or interrupted reference sine waveform in form of PCM audio data.

• Filter Executable: Acquisition.dll
• Filter CLSID: __uuidof(ToneSourceFilter) {8002935A-B2EC-40ef-968C-E0358E5DED10}
• Filter Property Page CLSID: __uuidof(ToneSourceFilterGeneralPropertyPage), {EBD8ABB2-6DD3-4c54-A7F1-9FE4DA283EDF}, ToneSourceFilterPreferedFormatPropertyPage, {EE224187-4FA3-4c3f-9D5D-492694CCFEB7}
• Filter Merit: MERIT_DO_NOT_USE
• Filter Category: CLSID_LegacyAmFilterCategory (also configurable as CLSID_AudioInputDeviceCategory)
• Filter Interfaces: IPersistStreamInit, IPersistStream, ISpecifyPropertyPages, IPersistPropertyBag, IBaseFilter, IMediaFilter, IPersist, IAMovieSetup, IAMFilterMiscFlags, IToneSourceFilter, IDispatch
• Filter Pins: single ouput pin (Ouput)
• Output Pin Media Types: MEDIATYPE_Audio/MEDIASUBTYPE_PCM
• Output Pin Interfaces: IPin, IMemInputPin, IAMPushSource, IAMLatency, IAMBufferNegotiation, IKsPropertySet, IAMStreamConfig

Remarks

The hosting library (DLL) exposes DoToneSourceFilterDevicePropertySheetModal function which provides GUI to configure the filter as one or more audio capture source device, which can be enumerated by System Device Enumerator.

In order to better troubleshoot network cameras and other devices, I added a new DirectShow filter to write HTTP response headers and body into a single file, one file (actually a pairs of files, the second file contains UTF-8 formatted HTTP response headers) per HTTP response.

While troubleshootting JPEG artefact issue with I used the following graph:

which started M-JPEG streaming from a camera and had entire stream written into Response-01586228-0001-0001-Headers.txt (Headers) and Response-01586228-0001-0001.dat (Data) files, while parsed JPEG frames were also written into individual files and were available for comparison.

Other changes include:

• new HTTP Stream File Renderer Filter (details are below)
• attachable media types on internally used memory allocators, which enable filters to effectively reagree media types in running state
• workaround for Panasonic BL-C140 camera (may be also helpful for other models), details here

There also seems to be a bug in Intel IPP 6.0 JPEG decoder that leaves bottom right image block incorrectly decoded, only when a sequence of images is decoded and the frame is not the first in the sequence.

A partial Visual C++ .NET 2008 source code is available from SVN, release binary included.

Continue Reading »

Having DirectShow Filter Graph Spy installed in the system, I noticed a new and weird effect that when Media Player Classic plays a list of files and each MP3 file being currently decoded shows decoder’s system tray icon, a switch to a new file leaves an old icon in place and adds a new icon for a new decoder.  I thought this might be also a decoder’s problem which I also recently updated to a new version, but then I noticed other artifacts, with other software and again with Media Player Classic, that if I drop a new file onto the player and it starts playing it, old file is still being played as if player just releases all referenced to the graph and never calls IMediaControl::Stop to force stop of playback.

It was clear at that point that it is related to filter graph spy and the problem needs a fix. The problem definitely looked like the spy leave outstanding references to the filter graph and when the application releases graph and it is supposed to be automatically destroyed, it is still being alive and possibly, such as in case of Media Player Classic, even running.

The first clue was that being published to running object table (ROT), the object gets more than one additional reference on it and as such it never gets removed from ROT until application terminates as ROT keeps a reference to the graph and there is noone to remove it. By original design spy published filter graph on ROT and removed one reference immediately after that to compensate the ROT’s reference (one only) making it a weak reference. So when all references are released from the filter graph but ROT reference, the graph gets destroyed and in FinalRelease class on the COM object we re-add the reference back and automatically remove the object from ROT as well. The whole scheme works in assumption that ROT adds one reference only, if there are more then the object is referenced by the ROT forever.

Debugging however showed that ROT adds a single reference and there is no problem from this side. However I immediately noticed  another weird behavior in the same method FinalConstruct. An underlying (real) filter graph object, i.e. CFilterGraph from quartz.dll, is adding a reference on the outer COM object when being queried for a private interface from implicit (also known as main, raw) IUnknown when created as aggregated object. And it is not exactly the behavior one would expect from aggregated object because it basically break proper reference counting. I realize that aggregating is a rather rare technique and DirectShow COM base is one of the very first COM bases at all which then stopped being developed, so perhaps this problem was not identified on time and later left unfixed at all, so in present situation there should rather be a workaround.

It is also worth mentioning that there are two scenarios involved. My CSpy object creates DirectShow CFilterGraph as an aggregated object. And CSpy in its turn may be created as aggregated too. For example, Windows Media Player creates (as most applications in this universe do) filter graph object the regular way, as a standalone COM object. However it appears that Media Player Classic creates filter graph as aggregated, for whatever it needs it for. Because of the discovered problem inner CFilterGraph adds an outstanding reference on the top level “controlling IUnknown”, which is either CSpy’s private IUnkown in case of Windows Media Player, or higher level IUnknown in case of Media Player Classic.

So the proper workaround is to release unwanted references from controlling unknown rather than self:

CComPtr<IUnknown> pUnknown;
ATLENSURE_SUCCEEDED(pClassFactory->CreateInstance(pControllingUnknown, __uuidof(IUnknown), (VOID**) &pUnknown));
// NOTE: DirectShow FilterGraph is incorrectly implementing COM aggregation adding outer reference to interfaces queried from private IUnknown
CComQIPtr<IFilterGraph2> pFilterGraph2 = pUnknown;
ATLENSURE_THROW(pFilterGraph2, E_NOINTERFACE);
pFilterGraph2.p->Release(); // <<--------------------------

It looked like the problem is finally worked around but in aggregated creation scenario it brought another problem up. Since instantiation of inner CFilterGraph takes place in FinalConstruct and CSpy is also being instantiated as aggregated, it appears that outer COM object is sensible to manipulation with its reference counter. CFilterGraph added a reference it should not, CSpy released it in compensation but on this early stage the compensating Release might zero reference counter and might initiate unexpected object destruction. It is not necessarily this way as it depends on outer COM object base, but it seems that Media Player Classic does not do DECLARE_PROTECT_FINAL_CONSTRUCT or its equavalent and things go the worst scenario.

CSpy is an inner object and we don’t have any external instance to hold a temporary reference for us while outer COM object is being created, so a workround for this is to temporarily hold a circular reference to an outer object to let it complete its instanatiation and pass another reference higher up to the controlling application. At which point we are going to be safe to release the temporary reference and normalize reference counters.

if(m_bIsAggregated)
{
    pControllingUnknown.p->AddRef();
    const ULONG nReferenceCount = pControllingUnknown.p->Release();
    if(nReferenceCount == 1)
        m_pTemporaryUnknown = pControllingUnknown;
}

The only thing is left is to release the temporary reference early enough, but we have a filter graph, don’t we? What is typically done with a filter graph, adding a filter right? And it is a controlling application which has its own reference, who adds filters so we are safe to release temporary reference in IFilterGraph::AddFilter or IGraphBuilder::AddSourceFilter (actually it would not hurt to add this in other methods as well):

STDMETHOD(AddFilter)(IBaseFilter* pFilter, LPCWSTR pszName) throw()
{
    _Z4(atlTraceCOM, 4, _T("pszName \"%s\"\n"), CString(pszName));
    ReleaseTemporaryUnknown(); // <<--------------------------
    return m_pInnerFilterGraph2->AddFilter(pFilter, pszName);
}

Additionally, the spy also implements now IMediaControl interface and traces calls to log file, it is convenient.

A partial Visual C++ .NET 2008 source code is available from SVN, release binary included.

reg-FilterGraphSpy.dll.bat and unreg-FilterGraphSpy.dll.bat files in SVN are convenient batch files to register and unregister the spy with the operating system.

At the time of original implementation I intentionally left off a variation of Filter Graph Manager that runs on application thread, CLSID_FilterGraphNoThread. MSDN says:

CLSID_FilterGraphNoThread creates the Filter Graph Manager on the application’s thread. If you use this CLSID, the thread that calls CoCreateInstance must have a message loop that dispatches messages; otherwise, deadlocks can occur. Also, before the application thread exits, it must release the Filter Graph Manager and all graph objects (such as filters, pins, reference clocks, and so forth).

I have never needed to use this CLSID (by the way Windows SDK has one more CLSID – CLSID_FilterGraphPrivateThread – but it does not seem to be documented) and for this reason I left it for the time a need in it comes up. However it appeared that this CLSID was not created just for fun, there was a need in it. Filter graphs of Windows Media Player playing well known Windows’ clock.avi appeared to be not published on Running Object Table. Why?

Process Monitor showed clearly that Windows Media Player created filter graph through CLSID_FilterGraphNoThread and quite obviously it was not intercepted by Filter Graph Spy (still I wonder what made it different previous time when I could see WMP’s graph).

Continue Reading »

Inspired by a post on DirectShow Development Forum, it is sometimes useful to find out how certain application is using DirectShow to capture live video and/or audio, or play certain file etc. Filter graph topology, details about media types on the pins, used interfaces and call order. There is quite an easy step for the developer to spy over running filter graphs system wide by connecting Component Object Model (COM) “Treat As” feature with filter graph remoting through Running Object Table and connecting to remote process graphs using GraphEdit utility.

Who could imagine Windows Media Player to build such a filter graph for a video and audio Windows Media file? SRS Wow DMO, equalizer, analyzer and stuff?

Continue Reading »

A good old task to easily minimize to system tray icon to not clog the application bar and without too much thinking about it. How To with WTL?

The key points are:

• manage NOTIFYICONDATA structure (obviously!), where non-zero .cbSize will be an indication of created icon
• create an icon in WM_SYSCOMMAND/SC_MINIMIZE handler and hide instead default minimization
• handle icon’s WM_LBUTTONDBLCLK to restore and WM_RBUTTONUP to pop up a menu
• use default dialog menu to avoid having private one, handle SC_RESTORE and SC_CLOSE system commands to restore and close from system tray icon popup menu

Relevant source code from application main window (dialog) class:

Continue Reading »