Fooling Around

Another example of a negligence with a cost of incompatibility and enormous amount of support time. Ahead Nero installs a number of DirectShow filters into $(Program Files)\Common Files\Ahead\DSFilter directory. One of the files is NeResize.ax and it hosts a Nero Resize filter. Let us take a closer look:

CLSID: {30002E0C-C574-481E-A5DE-90AE54A79E10}
Merit: 0×00400000 (MERIT_UNLIKELY)
Input Pin’s Media Type: major type GUID_NULL, subtype GUID_NULL
Output Pin’s Media Type: major type GUID_NULL, subtype GUID_NULL

The filter is clearly a video filter:

So the filter register itself under a merit that allows taking it during Intelligent Connect, it registers using media type wildcard which is clearly widely than the filter can affectively operate with and the most interesting part is: with certain video media types the filter crashes (memory access violation) during pin connection negotiation process. That is, inaccurate filter may be crashing third party software it has nothing to deal with at all.

*** Unhandled Exception
Process: 0x000001d4, Thread: 0x00000ce4, Date: 6/29/2009, Time: 11:20:56 AM, Application: C:\Program Files\...
Module: C:\..., Product Version: 1.7.1.1, File Version: 1.7.1.20014, File Time: 23.06.2009, 19:02
Code: 0xc0000005, Flags: 0x00000000, Address: 0x05fc6c65
Parameters: 0x00000001, 0x15be9030

** Call Stack
NeResize!05fc6c65 DllUnregisterServer +21909 @05fc0000
NeResize!05fc7888 DllUnregisterServer +25016 @05fc0000
NeResize!05fc7204 DllUnregisterServer +23348 @05fc0000

Additionally to that the filter does not allow its insertion in debugging environment, and it seems even with Visual Studio running without a debugging session active. Which means that developer may be unaware of issues until incompatibility comes up at a later stage such as testing, or at production site.

It is not the first Nero filter which is bringing real problems. Basically any user who want to keep his system far from issues while still having Nero installed, needs to do find $(Program Files)\Common Files\Ahead\DSFilter directory and immediately rename it to some ~DSFilter in order to invalidate all Nero filters registration.

A few quotes from Guidelines for Registering Filters:

Avoid specifying MEDIATYPE_None, MEDIASUBTYPE_None, or GUID_NULL in the AMOVIESETUP_MEDIATYPE information for a pin. IFilterMapper2 treats these as wildcards, which can slow the graph-building process.

Nero Resize does specify and obviously slows the system down.

Choose the lowest merit value possible. Here are some guidelines:
…
Special purpose filter; any filter that is created directly by the application: MERIT_DO_NOT_USE

Nero Resize uses higher value and thus affects proper applications.

Software developers will be safer to prevent from DirectShow Filter Graph Manager considering the buggy filter to be used during Intelligent Connect by implementing IAMGraphBuilderCallback interface.

If you drag a file over Windows Live Messenger’s My Sharing Folders shell name space item, it would immediately interrupt dragging with an error message box, even if you never planned to drop onto this folder:

This should definitely be rather implemented a different way. If you ever tried to drag something using slow PC touchpad, you probably have an idea of how annoying such an interruption could be.

Windows Live Messenger was pre-installed. To disable shared folders feature, I wanted to find a proper setting in options, but it did not appear to be easy enough: Help button, Show the menu bar, Tools, Options, Sharing Folders on the left, oops! it was not helpful.

Going another way of finding DLL that hosts the shell extension revealed file named: C:\Program Files\Windows Live\Messenger\fsshext.8.5.1302.1018.dll. Once unregistered, the folder went away from the shell (process restart needed, typically logoff/logon):

C:\>regsvr32 /u "C:\Program Files\Windows Live\Messenger\fsshext.8.5.1302.1018.dll"

One thing is worth special mentioning in connection with previous post on DirectShow Filter Graph Spy on Microsoft Vista system: ATL’s CSecurityDesc class caused to waste some time.

CRegKey Key;
ATLENSURE_SUCCEEDED(HRESULT_FROM_WIN32(Key.Open(HKEY_CLASSES_ROOT, pszKeyName, READ_CONTROL | WRITE_OWNER)));
CSecurityDesc AdministratorsOwnerSecurityDescriptor;
AdministratorsOwnerSecurityDescriptor.SetOwner(Sids::Admins());
ATLENSURE_SUCCEEDED(HRESULT_FROM_WIN32(Key.SetKeySecurity(OWNER_SECURITY_INFORMATION, &AdministratorsOwnerSecurityDescriptor)));

The code compiles fine, but on runtime it gives error 87 (ERROR_INVALID_PARAMETER, E_INVALIDARG) in the last line, returned from RegSetKeySecurity API call. My first guess was that ATL’s CSecurityDesc class for some reason prepared wrong descriptor which resulted in rejecting it as an argument. From the first glance it looks (not sure) that this class deals, to some extent, with structures itself rather than using API functions, so it could be that it results in something looking differently from expected by API calls.

Still the problem is in class itself and its cast from CSecurityDesc& to required SECURITY_DESCRIPTOR* type. The class only implements operator to automatically cast to const SECURITY_DESCRIPTOR* type, so the following line would not be passed by compiler:

Key.SetKeySecurity(OWNER_SECURITY_INFORMATION, AdministratorsOwnerSecurityDescriptor)

However &AdministratorsOwnerSecurityDescriptor is another level of indirection and hence SECURITY_DESCRIPTOR** type, which is passed by compiler, but results in indeed invalid argument.

So in order to correctly convert CSecurityDesc& to SECURITY_DESCRIPTOR* it can be done this way:

CRegKey Key;
ATLENSURE_SUCCEEDED(HRESULT_FROM_WIN32(Key.Open(HKEY_CLASSES_ROOT, pszKeyName, READ_CONTROL | WRITE_OWNER)));
CSecurityDesc AdministratorsOwnerSecurityDescriptor;
AdministratorsOwnerSecurityDescriptor.SetOwner(Sids::Admins());
ATLENSURE_SUCCEEDED(HRESULT_FROM_WIN32(Key.SetKeySecurity(OWNER_SECURITY_INFORMATION, const_cast<SECURITY_DESCRIPTOR*>((const SECURITY_DESCRIPTOR*) AdministratorsOwnerSecurityDescriptor))));

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.

Alax.Info DHCP Server was updated to provide user interface and show a list of issued DHCP leases, including:

• hardware (MAC) address and IP address correspondence
• latest date and time of DHCP lease issue
• sortable list to be able to conveniently arrange entries and lookup items of interest

Other changes include:

• stores latest lease issue date and time in registry to be able to locate recently issued leases
• indicates Windows service status through system tray icon (running or stopped)
• minor fixes

Release information:

• Updated Version: 1.0.4
• Download Link: AlaxInfoDhcpServerSetup.msi (368K)
• Registration Cart: http://www.shareit.com/product.html

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.