I've a DS filter sitting in the LegacyAmFilterCategory and use it in my filter graph as video source. I've adjusted the PlayCap example to add the filter to the graph and it works as expected. If I use exactly the same code to create the filter graph in my application, the call for BindToObject() while getting the filter fails with a COMException (HRESULT: 0x800701E7) which indicates a wrong address access. The only difference I can think of is the fact that the PlayCap application is a stand alone application while my filter graph creation is done in a C# DLL.
My application worked for the last few years and this problem was introduced with a Windows update (KB969897) for the IE8 from June 2009. If I uninstall the update, the exception is gone and if the update gets installed again, also the exception is raised again.
Can somebody think of a solution for this problem because I have already tried all my kung fu on this problem (MS is already working to find a reason why this update might cause this strange behaviour).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As an alternative, have you tried AddSourceFilterForMoniker?
Second of all, .Net gets cranky about cross threaded operations. There are pretty strict COM rules about how you are supposed to do this. Rules which c++ tends to ignore (of course), but c# enforces. Check to see if various operations are occurring on more than 1 thread. If so, I've got a link for you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tried the AddSourceFilterForMoniker() functions with the exact same result: Error 8007017E
All functions regarding COM and DirectShow are situated in a single DLL which doesn't get called from different threads. There is only one thread at the time the error occurs. I'll now start to move the code out of the DLL into my main application which is in VB.NET. Perhaps that sheds some light on this problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, getting the code out of the DLL in my main application didn't changed anything. I did a DLL comparison (what DLLs are loaded by my application if it is started) with the SysInternals tool ListDlls.exe and found out that only three DLLs differ in their version number if I install/uninstall the KB969897 update:
C:\Windows\System32\iertutil.dll
C:\Windows\System32\urlmon.dll
C:\Windows\System32\wininet.dll
MS must have changed something in these DLLs with the update (is also stated in the update details) because my test application (adjusted PlayCap example) doesn't need these DLLs and works fine regardless if the update is installed or not.
Seem like I have to talk to MS about this problem because I already tried more than five different ways to get the filter working but never succeeded.
I'll keep you guys posted about the progress.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Finally I found the reason causing this problem: It was burried in the compiler settings for my DirectShow filter. I don't know the reason why this setting was changed but setting the value for "Linker/Advanced/Fixed Base Address" to "Image must be loaded at a fixed address" was responsible for not allowing to load the filter driver. I changed it to "Default" and everything works. Anyway thanks for your help, it's much appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've a DS filter sitting in the LegacyAmFilterCategory and use it in my filter graph as video source. I've adjusted the PlayCap example to add the filter to the graph and it works as expected. If I use exactly the same code to create the filter graph in my application, the call for BindToObject() while getting the filter fails with a COMException (HRESULT: 0x800701E7) which indicates a wrong address access. The only difference I can think of is the fact that the PlayCap application is a stand alone application while my filter graph creation is done in a C# DLL.
My application worked for the last few years and this problem was introduced with a Windows update (KB969897) for the IE8 from June 2009. If I uninstall the update, the exception is gone and if the update gets installed again, also the exception is raised again.
Can somebody think of a solution for this problem because I have already tried all my kung fu on this problem (MS is already working to find a reason why this update might cause this strange behaviour).
Also see thread here for history:
http://social.msdn.microsoft.com/Forums/en-US/windowsdirectshowdevelopment/thread/83c7cd7d-52df-416b-bdb9-6cd772ece02c
As an alternative, have you tried AddSourceFilterForMoniker?
Second of all, .Net gets cranky about cross threaded operations. There are pretty strict COM rules about how you are supposed to do this. Rules which c++ tends to ignore (of course), but c# enforces. Check to see if various operations are occurring on more than 1 thread. If so, I've got a link for you.
Tried the AddSourceFilterForMoniker() functions with the exact same result: Error 8007017E
All functions regarding COM and DirectShow are situated in a single DLL which doesn't get called from different threads. There is only one thread at the time the error occurs. I'll now start to move the code out of the DLL into my main application which is in VB.NET. Perhaps that sheds some light on this problem.
OK, getting the code out of the DLL in my main application didn't changed anything. I did a DLL comparison (what DLLs are loaded by my application if it is started) with the SysInternals tool ListDlls.exe and found out that only three DLLs differ in their version number if I install/uninstall the KB969897 update:
MS must have changed something in these DLLs with the update (is also stated in the update details) because my test application (adjusted PlayCap example) doesn't need these DLLs and works fine regardless if the update is installed or not.
Seem like I have to talk to MS about this problem because I already tried more than five different ways to get the filter working but never succeeded.
I'll keep you guys posted about the progress.
Thanks for keeping us updated.
Finally I found the reason causing this problem: It was burried in the compiler settings for my DirectShow filter. I don't know the reason why this setting was changed but setting the value for "Linker/Advanced/Fixed Base Address" to "Image must be loaded at a fixed address" was responsible for not allowing to load the filter driver. I changed it to "Default" and everything works. Anyway thanks for your help, it's much appreciated.
Wow. I would never have thought to muck with that. Can't think why that would make a difference.