Lately I have had a bug which has been making me scratch my head for a while.
To partly obfuscate a video file (XVID) we introduced extra data into the headers which causes the usual DirectShow Filters to fail, we then created our own which fixes this.
The file would happily play within Windows Media Player. It would play within a Windows Media Player object hosted within Internet Explorer, but would not when hosted within a Windows Media Player object hosted within a .Net WebBrowser object using the same HTML code handling the embedded Windows Media Player object.
The error was that it could not find the required codec. This had me stumped as it worked fine in IE using exactly the same HTML.
We tried different systems, Windows XP, Windows Vista, but it was Windows 7 which seemed to cause the issue.
So we knocked out the trusted sysInternals tools and set to work tracking the issue down.
When a media file loads, Windows Media Player polls various DirectShow filters initially based on the file extension whether or not they can play the file. What we found made us slap ourselves on the heads as we had forgotten to check something ever so simple.
x86 or x64
When compiling the DirectShow Filter we only wrote a 32bit version. Windows Media Player is 32bit, the Internet Explorer version we tried it initially through was 32bit but the WebBrowser Control and thus the internal WMP object was 64bit. It tried to load the non-existant 64bit Filter and failed, thus giving us the error.
The tell tail signs were the references to WOW64 in the attempted registry reads and the registry entries not found as we ran the Process Monitor while running our app.
In the end it came down to a simple fix of forcing our app to be compiled as x86 – which can be done via the drop down Build Configuration Options menu in Visual Studio.