Something went terribly wrong in x64 build of Windows Media Video 9 Decoder

Unfortunately, 64-bit version of Windows Media Video 9 Decoder is not as good as its 32-bit sister. 32-bit version is user an order of magnitude more frequently and does not give troubles, nevertheless 64-bit version offers similar feature set it is pretty hard to see it in action since it takes a 64-bit media application to host it and most of media applications are 32-bit (there is often a good reason for this), and even Windows SDK 7.0 topoedit comes pre-built as Win32 application only (provided with source code though, so one can built x64 peer – after fixing buildability issues and adding x64 configuration manually).

Decoder is available as dual DMO/MFT which enabled it for both DirectShow and Media Foundation APIs and similarly exposes the problem in both as well.

Once in a while, 64-bit version of the decoder might be producing incorrect output, adding white dots where they are not supposed to be.


Because the problem resides supposedly in the decoder itself, it affects everything decoding Windows Media Video of this flavor, including

  • Windows Media Player 64-bit
  • GraphEdit x64 from Windows SDK
  • TopoEdit x64 from Windows SDK (built manually)

The only exception is DXVA-accelerated decoding where bug is worked around by hardware assisted decoding and the output is correct.


One of the ways to easily see and reproduce the problem in action is to re-encode the content in 64-bit version of GraphEdit into anything else: video decoder there will decode in software and burn the artifacts in.

See also:

NTFS Links: x64 build

Per user request, here goes 64-bit version of NTFS Links utility, which provides shell UI for NTFS Junction Points.

As 64-bit version of Windows operating systems provide two versions of shell explorer, and support both Win32 and x64 platform applications, it is typical to install both 32-bit and 64-bit versions of the utility to cover/extend applications of both platforms. Note that 32-bit (Win32) applications can only load and directly interact with 32-bit builds of libraries (DLLs), so 64-bit (x64) applications need a corresponding matching version of the shell extension available.

As the utility provides a shell extension for directory property pages, here comes a curiosity exercise: how Windows 7 uses junction points to cross-map directories under user profile directory, e.g. C:\Users\<username>\Local Settings directory is actually a shortcut to C:\Users\<username>\AppData\Local.

Current version of Alax.Info NTFS Links can be downloaded from:

Resource Tools: 64-bit build

I rebuilt the Resource Tools utility in 64-bits to, supposedly, be able to be good with resources on 64-bit binaries (actually 32-bit code might be dealing with those fine also?). Anyway, the build is here and the tool available in both 32-bit and 64-bit versions.

In particular, both 32-bit and 64-bit JavaScript scripts hosted by Windows Scripting Host (respectively, 32-bit from C:\Windows\syswow64 or 64-bit from C:\Windows\system32 – in 64-bit Windows) can leverage the tool in file manipulation.

This utility is specifically helpful in automating steps which involve resource updates, such as to apply OEM branding, or resource-based file operations. The code snippet below archives a copy of DLL and PDB files for published release into a .7z archive named using current file version of the DLL itself (that is, it created a ResourceTools.dll- archive file out of ResourceTools.dll and corresponding ResourceTools.pdb files):

image = new ActiveXObject("AlaxInfo.ResourceTools.Image");
image.Initialize(inputDirectory + fileName);
productVersion = image.VersionInfo.ProductVersionString;
fileVersion = image.VersionInfo.FileVersionString;
WScript.Echo(" Product Version: " + productVersion);
WScript.Echo(" File Version: " + fileVersion);
shell = WScript.CreateObject("WScript.Shell");
currentDirectory = shell.CurrentDirectory;
shell.CurrentDirectory = currentDirectory + "\\" + inputDirectory;
try {
    shellExec = shell.Exec(
        "\"" + toolDirectory + "7z" + "\" " +
        "a -t7z " +
        "\"" + currentDirectory + "\\" + outputDirectory + "ResourceTools.dll-" + fileVersion + ".7z" + "\" " +
        "ResourceTools.dll" + " " +
        "ResourceTools.pdb" + " " +
    while (shellExec.Status == 0)
    if (shellExec.ExitCode != 0)
        throw new Error("7-Zip Exec failed, .ExitCode " + shellExec.ExitCode.toString());
    WScript.Echo(" Output File: " + "ResourceTools-" + fileVersion + ".7z");
finally {
    shell.CurrentDirectory = currentDirectory;

Title: Alax.Info Resource Tools
Version: 1.0.6
Download Links: ResourceToolsSetup.msi (Win32, 32-bit) and ResourceToolsSetup-x64.msi (x64, 64-bit)

Obtaining number of thread context switches programmatically

Previous post on thread synchronization and context switches used number of thread context switches as one of the performance indicators. One might have hard times getting the number from operating system though.

The only well documented access to amount of context switches seems to be accessing corresponding performance counters. Thread performance counter will list available thread instances and counters “Thread(<process-name>/<thread-number>)/Context Switches/sec” will provide context switch rate per second.

While access to performance counters is far not the most convenient API, to access data programmatically one would really prefer absolute number of switches rather than rate per second (which is still good for interactive monitoring).

A gate into kernel world to grab the data of interest is provided with NtQuerySystemInformation function. Although mentioned in documentation, it is marked as unreliable for use, and Windows SDK static library is missing it so one has to obtain it using GetModuleHandle/GetProcAddress it explicity.

typedef NTSTATUS (WINAPI *NTQUERYSYSTEMINFORMATION)(SYSTEM_INFORMATION_CLASS SystemInformationClass, PVOID SystemInformation, ULONG SystemInformationLength, PULONG ReturnLength);
NTQUERYSYSTEMINFORMATION NtQuerySystemInformation = (NTQUERYSYSTEMINFORMATION) GetProcAddress(GetModuleHandle(_T("ntdll.dll")), "NtQuerySystemInformation");
ATLVERIFY(NtQuerySystemInformation(...) == 0);

Having this done, the function is capable of providing SystemProcessInformation/SYSTEM_PROCESS_INFORMATION data about running processes.

Continue reading →

DirectShow Filter Graph Spy: 64-bit version and hook API

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:

  • IFilterGraphAddRemoveHook
  • IFilterGraphConnectHook
  • IFilterGraphStateControlHook

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:

Registering a DirectShow Filter Graph Spy Hook

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"));
        OnReconnect(pT, pPin, &bDefault);
    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:

  • Windows 7
  • Windows Server 2008
  • Windows Vista
  • Windows Server 2003
  • Windows XP
  • Windows 2000

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.