There has been a number of posts on Internet, but none of the top ones appeared to be relevant.

The problem is reproduced extremely simple:

int _tmain(int argc, _TCHAR* argv[])
{
    ATLVERIFY(SUCCEEDED(CoInitialize(NULL)));
    {
        //CoLoadLibrary(L"C:\\Program Files (x86)\\Common Files\\System\\Ole DB\\oledb32.dll", TRUE);
        CComPtr<IDBInitialize> pDbInitialize;
        const HRESULT nResult = pDbInitialize.CoCreateInstance(L"Microsoft.Jet.OLEDB.4.0", NULL, CLSCTX_INPROC_SERVER);
        _tprintf(_T("nResult 0x%08x\n"), nResult);
    }
    CoUninitialize();
    return 0;
}

Oops, the code gives error REGDB_E_CLASSNOTREG 0×80040154 “Class not registered”. It looked like system was unable to locate one of the internally used DLLs – oledb32.dll, and if we help by uncommenting the line commented in the code snippet above, the error changes to  ERROR_MOD_NOT_FOUND 0×8007007e “The specified module could not be found”.

The problem appears to be that one of the system components, which is involved, “Microsoft OLE DB Data Conversion Library” is registered with the system using a REG_EXPAND_SZ value, to be located using path “%CommonProgramFiles(x86)%\System\Ole DB\oledb32.dll”. It is obvious that CommonProgramFiles(x86) is placeholder to be expanded, but does the expansion succeed?

On my system there was no such environment string, so expansion failed. There however was CommonProgramFiles, and it pointed to correct location. So, this hot fix makes it work right:

BOOL UpdateEnvironmentVariables()
{
    CString sCommonProgramFilesX86;
    sCommonProgramFilesX86.GetEnvironmentVariable(_T("CommonProgramFiles(x86)"));
    if(sCommonProgramFilesX86.IsEmpty())
    {
        CString sCommonProgramFiles;
        sCommonProgramFiles.GetEnvironmentVariable(_T("CommonProgramFiles"));
        if(!sCommonProgramFiles.IsEmpty())
        {
            ATLVERIFY(SetEnvironmentVariable(_T("CommonProgramFiles(x86)"), sCommonProgramFiles));
            return TRUE;
        }
    }
    return FALSE;
}

int _tmain(int argc, _TCHAR* argv[])
{
    ATLVERIFY(SUCCEEDED(CoInitialize(NULL)));
    {
        UpdateEnvironmentVariables();
        CComPtr<IDBInitialize> pDbInitialize;
        const HRESULT nResult = pDbInitialize.CoCreateInstance(L"Microsoft.Jet.OLEDB.4.0", NULL, CLSCTX_INPROC_SERVER);
        _tprintf(_T("nResult 0x%08x\n"), nResult);
    }
    CoUninitialize();
    return 0;
}

I am under impression that the problem is not specific to Windows 7. I remember similar symptoms on Windows XP system, but they were not critical and not investigated to solution. It rather seems that OLE DB component is registering itself using a reference to environment variable which is not present on a number of systems.

// Microsoft Most Valuable Professional Award

In an intention to accompany the post with useful DirectShow related information, here is the link list of most important DirectShow resources on the Internet:

• Microsoft:
  • DirectShow Reference (do not underestimate official documentation, it is well done and really covers minor but important details)
  • DirectShow Development Forum
• Social:
  • Microsoft.public.win32.programmer.directx.* Usenet Groups
  • DirectShow Forums in Russian
• Resources online:
  • Alessandro Angeli’s Programming FAQ – frequently asked questions and answers
  • The March Hare’s DShow Site – links, downloads, information
  • GDCL (Geraint Davies Consulting Ltd) by Geraint Davies – information and downloads, specifically popular for “bridge” solution (GMFBridge) for connecting multiple graphs
  • Chris P.’s Code Samples – especially audio related
  • Michel Roujansky, Multimedia & IT Consultant and Trainer – DirectX and DirectShow consulting
  • DirectShow.NET Library – for those who prefer interfacing to DirectShow from managed code, in particular C# (as the .NET questions keep being posted to other places, while they should go directly there)
  • Gabest’s Guliverkli Project – on SourceForge, a home of Media Player Classic and various filters
  • Monogram Multimedia and Igor Jánoš – with GraphStudio, an important alternative to Windows SDK GraphEdit, and a home of useful DirectShow filters
• Non-DirectShow but related:
  • Intel Integrated Performance Primitives Library – a library with basic media related functions built with performance in mind, provided with sample code that covers a wide range of existing multimedia algorithms and tasks

Microsoft MVP Award Souvenir and Certificate

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"

There was nothing worth a word until I reached the download screen which opened an extremely awful Java applet that pretended to be a download manager. It seemed to be a new spin of technology and sort of I don’t need a nice download manager anymore because direct HTTP links are out of fashion. It started pumping bytes (actually thanks for that) and I my attempt to copy/paste a direct link into my DownThemAll FireFox plugin was vain.

At some 20% the download froze without a notice. The download did not even ungray the resume buttons before I restarted FireFox process and then any attempt to resume led to weird message boxes. Frankly at this point I almost lost the desire to actually complete the download. But left a last chance to have it completed by IE. Internet Explorer (expectedly!) preferred ActiveX control to Java applet. It’s GUI was a bit less scary and it took over incomplete download and…

An attached debugger showed a call stack (oops, I did not save exact call stack) in Manager.exe process in C runtime module, in a CString class method… It went no further than this crashing at exactly the same point until I manually deleted the incomplete download, when it again repeated a weird message box and then finally restart the download from the start. That was enough for me and found a .torrent with the exactly the same file on thepiratebay.org, which I am quite sure will download without a problem.

Isn’t it incredibly stupid that significant amount of work was invested into unnecessary task, ugly user interface, buggy implementation (freeze, incapable download manager, weird messages, crash) with a solid residual of inability to conveniently download the thing, while the file could be just put onto regular MS download service?

This is the reference code for the feature:

const volatile INT g_nValueA = 0;
const volatile INT g_nValueB = 0;

#pragma optimize("y", off)

__declspec(dllexport) __declspec(noinline) BOOL STDMETHODCALLTYPE A(const volatile INT& nValue = g_nValueA)
{
	return nValue != 0;
}

#pragma optimize("y", on)

__declspec(dllexport) __declspec(noinline) BOOL STDMETHODCALLTYPE B(const volatile INT& nValue = g_nValueB)
{
	return nValue != 0;
}

int _tmain(int argc, _TCHAR* argv[])
{
	A();
	B();
	return 0;
}

The code is to be compiled in Release and function A is to be not optimized while B is subject for optimization and omitting the frame pointer.

Disassembly shows for A:

__declspec(dllexport) __declspec(noinline) BOOL STDMETHODCALLTYPE A(const volatile INT& nValue = g_nValueA)
{
00401000  push        ebp
00401001  mov         ebp,esp
	return nValue != 0;
00401003  mov         eax,dword ptr [nValue]
00401006  mov         ecx,dword ptr [eax]
00401008  xor         eax,eax
0040100A  test        ecx,ecx
0040100C  setne       al
}
0040100F  pop         ebp
00401010  ret         4

and for B:

__declspec(dllexport) __declspec(noinline) BOOL STDMETHODCALLTYPE B(const volatile INT& nValue = g_nValueB)
{
	return nValue != 0;
00401020  mov         eax,dword ptr [esp+4]
00401024  mov         ecx,dword ptr [eax]
00401026  xor         eax,eax
00401028  test        ecx,ecx
0040102A  setne       al
}
0040102D  ret         4

and the difference is what was actually expected. It looked as it finally got to work but a check with Visual Studio versions 2003 and 2005 shown that optiomization makes a difference on older versions too.

Things, however, definitely went a different way with hardware still on the shelves and no firmware upgrades available on the website. Our customer got into trouble having already recommended his customer the buggy thing in amount of X and forwarded us the question of getting everything working. As we decided to make a step towards, I needed to “write some code” to settle the problem.

However, the story was about a different thing. So in order to put a comment into code that explains what kind of problem we are dealing with, I copy/pasted a fragment of HTTP request/response content from Wireshark into source file being edited within MS Visual Studio .NET IDE. Wireshark copies text with some weird line endings, I knew that. I removed extra empty lines from pasted text and actually did not expect anything to go wrong. However who appeared to be wrong was me.

Initially there seemed to be no problem, I tried to compile code, fixed some compiler errors, even started application. I was somewhat confused that the application did not hit my breakpoint while it should. Then I noticed it did not even generate code for this line. As these things do happen with development environment, I re-opened IDE, deleting .NCB for the project and Rebuilt All. The problem however did not go. After further code modification, the compiler started giving errors and shown wrong lines in build output, which did not match source code line numbers.

This started being completely stupid: I was to look at wrong identifier, search through entire source file for occurrences, see if this particular occurrence might be actually a problem for compiler and so on. I made it compiled successffully but under debugger there were still wrong line numbers which made it impossible to debug and set breakpoints.

At this point I remembered Wireshark and line endings. Just removing the comments did not worked. And since visually everything was OK with the source, there should be an easy way found to normalize text. And what I did was the following: I started new message in Mozilla Thunderbird and copy/pasted entire source file content into Thunderbird’s editor. Then copy/pasted back into Visual Studio and finally got the things fixed.

Regardless of whose the bug is, it seems to me that it is the Microsoft’s one, both are sophisticated applications of a large scale while RSS thing is just nothing in comparison. Was it really difficult to make the darn thing work?

MS WYSIWYG post editor can stand no criticism at all, it is one entire bug under FireFox browser. What I recently start getting is a view of the forum which seems to exclude weeks of recent data: