I've just upgraded from Visual Studio 6 to Visual Studio 2005. I've got the latest DirectShow stuff (in the platform SDK) and am using it. Everything builds and runs fine on my development machine (which has Visual Studio 2005 installed) but when I try:
"regsvr32 "myfilter.ax"
on a different machine (without Visual Studio 2005, both machines are WinXP Pro and up to date AFAIK), I get the error:
LoadLibrary ("myfilter.ax") failed - This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
This happens even when I use, say, the "dump" example filter (compiled using the source files from DirectShow in Platform SDK but using the example project workspace from DirectX 9).
Does anyone have any ideas what's causing the problems Or does anyone have a set of successful filter project configurations I *think* it might be to do with msvcr80.dll being needed (it gets listed when I run it through Dependency Walker) but am not sure how to get rid of this.
Thanks.
Pam
LoadLibrary (regsvr32) fails without Visual Studio 2005
VinceVega
If you were making it all the way to the DllRegisterServer call in the filter, I believe you would get a different error, so I don't believe the error is in there. However iirc, LoadLibrary also fires any static constructors.
Do you have anything special there
Jim Teeuwen
I had the same problem. I installed .NET Framework 2.0 on the target machine, and everything worked fine.
Cheers!
CougarKitE
I had a very similar problem. John's solution of setting "Minimize CRT use in ATL" to "Yes" worked for me.
Thanks John
Yaron Becker
You could build both your filter and the base classes with Multithreaded runtimes instead of Multithreaded Dll. Or you could redistribute the runtime dll msvcr* with your filter.
G
RobSmith
Have you run depends on the test machine to see if it will list the missing dependency
Shaun
Installing .NET Framework 2.0 on the target machine is also not an option for me.
The project settings were already set to "Not using ATL". Changing the "Minimize CRT Use in ATL" to "Yes" had no effect on my problem.
I've wimped out and reverted to MSVC6 - I still have my .dsw and it has no apparent problems other than I can't statically link to the very latest version of one of the libs I use because it's been compiled with something later than VC6 and gives the "security cookie" unresolved external symbol.
Thanks.
Dhananjay
I had the same problem. I installed the .NET FrameWork 2.0 on the target machine and everything started to work.
Cheers!
Nicholas Wagner
Ok, then I guess my problem is NOT with msvcr80.dll. My project settings ("Properties" in MSVC2005) include msvcrt.lib in the linker input already. If I put msvcr80.dll in the same folder on my test machine, I still get the error:
"LoadLibrary (<filter name>) failed - This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem"
Does anyone know what could be causing this error message Does anyone have a set of project settings for a DirectShow filter that works with Visual Studio 2005 That is, a DirectShow filter that can register on a machine that doesn't have Visual Studio 2005 on it.
Thanks.
Autechrian
Thanks, but everything is already "Multithreaded" only. I only mentioned msvcr80 because I looked at Dependency Walker and it showed it there. I have a DMO which registers fine on all the machines and it didn't show dependency on msvcr80 but the DirectShow filter did. It *may* be unrelated or I could be reading Dependency Walker's results wrongly.
I'm actually using the sample "dump" filter - I had the old "filters" dsw and have converted it to a sln and then updated the project properties so that the filter builds: That is: changed the additional path for includes so that I don't get the PVOID64 error and #defined _CRT_NO_SECURE_DEPRECATE. I also lifted the later cpp, def, h, rc files from the Platform SDK. The rest is all still default.
Thanks.
raj.ramesh
Well, there are several things to understand here.
First of all, you (and I) need to start learning about manifests. They are (apparently) the wave of the future. Check out http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=255074&SiteID=1
However, if you REALLY want to get rid of msvcr80.dll, you can do it by using static links of the dlls. This means removing msvcrt from the library and using libcmt.lib (I also had to add user32.lib, ole32.lib, oleaut32.lib, advapi32.lib, uuid.lib, strsafe.lib). There may be other implications here:
"Because a DLL built by linking to a static CRT will have its own CRT state, it is not recommended to link statically to the CRT in a DLL unless the consequences of this are specifically desired and understood. "
Sometimes there are no easy answers.
Maikel H
I had the same problem with a COM library that I upgraded to VS 2005: unable to register on another XP system with LoadLibrary failed even when you copy necessary dependencies (e.g. atl80.dll and msvcr80d.dll).
I then created a completely new test ATL project in VS 2005 using the Wizard and added a ATL Simple Object. Amazingly, same problem.
I was able to resolve the problem (unsatisfactorily but it worked) by by setting "Minimize CRT Use in ATL" to "Yes" in the project settings.
I suspect the problem is something to do with the manifest (yes, it is embedded) , but I would have thought that the VC++ project wizard would ensure that the manifest specified the runtime library correctly if that is what's now required.
Having to have the .NET Framework 2.0 installed on a target system is not an option.
Anyone on the VS C++ team care to comment on what's going on here
JorgeRoca
The first way is to place a msvcr80.dll to the same folder
The second way - try to find a lib version of msvcr80 and link it to your *.ax file statically
escorpi
kmoreto
Interesting - thanks for the suggestion. Dependency Walker reported msvcr80.dll as missing, so I copied it across. Then it repored msjava.dll as missing, so I copied it across (all going into the same folder). Copying the dlls is just a temporary hack - I don't know why it needs them when the MSVC6 compiled version didn't need them at all and the linker options haven't really changed. Now it's reporting problems with mpr.dll and these I don't understand. It says that:
"Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module"
And the function that seems to be causing the problems is WNetRestoreConnectionA in mpr.dll.
I'm actually just using the "dump" example filter now, so I don't *think* there's anything in the source code (constructors etc) that could affect things. I'm pretty sure it's project settings (I got the project settings by just opening the samples dsw in VS2005 so it did an auto conversion).
Thanks.