LoadPlugin("x.dll") worked OK, but won't do now

[Gargamel]

Hello,

Recently (some days?), probably after a mistake (but I don't see where), an error pop-up message tells me that Avisynth cannot load the plugins which are listed in some "old" scripts, like this:

Avisynth open failure:
LoadPlugin: unable to load "Deflicker.dll", error=0x7e

All those scripts ran perfectly before, and were not modified.
The plugin-DLLs are in the same folder than the script.

Copying them in C:\Program Files\Avisynth\plugins : no success.
Full uninstall (using Revo Uninstaller) + reinstall Avisynth : no success.

I use AviSynth 2.6 MT, on a XP-SP3 machine; no recent changes.
Yesterday, Microsoft made some automatic updates, but a backup 'before' didn't resolve the problem.

That issue is really new for me.
OK, if each path is writen, like this:
LoadPlugin("E:\Fred_restore\Deflicker.dll")
the script works well... But I'd like understand that new behaviour ;-)
All advices welcome, thank you.

[Overdrive80]

Hello,

Recently (some days?), probably after a mistake (but I don't see where), an error pop-up message tells me that Avisynth cannot load the plugins which are listed in some "old" scripts, like this:

Avisynth open failure:
LoadPlugin: unable to load "Deflicker.dll", error=0x7e

All those scripts ran perfectly before, and were not modified.
The plugin-DLLs are in the same folder than the script.

Copying them in C:\Program Files\Avisynth\plugins : no success.
Full uninstall (using Revo Uninstaller) + reinstall Avisynth : no success.

I use AviSynth 2.6 MT, on a XP-SP3 machine; no recent changes.
Yesterday, Microsoft made some automatic updates, but a backup 'before' didn't resolve the problem.

That issue is really new for me.
OK, if each path is writen, like this:
LoadPlugin("E:\Fred_restore\Deflicker.dll")
the script works well... But I'd like understand that new behaviour ;-)
All advices welcome, thank you.

Reinstall avisynth, and try it again.

[StainlessS]

Revo uninstaller probably would leave all plugins intact, as not part of install to begin with.
Suggest copy plugins elsewhere, ie empty plugs directory and retry. Also might want to try
a system cleanup with CCleaner (google, by I think, Pirisoft, stands for Crap Cleaner).

EDIT: Afterwards, as Overdrive said,reboot, re-install Avisynth, and retry.

[Gargamel]

Thank you for your quick answer, Overdrive80 and StainlessS... but I did so.

Plugins were archived on another HD, then wiped from Avisynth\plugins, before uninstall Avisynth.
And I launched CCleaner...

But I can do again, sure.

[StainlessS]

Let us know if successful, I cant think of anything else off hand but someone else may.
EDIT: If I hit any kind of problem like that, I just reinstall the system from a good image, ie Ghost
image, snapshot of an earlier working system (I refuse to use system restore stuff).
EDIT: Another user made a post suggesting that latest MT could be the problem and suggested rolling back to an earlier version,.
but then deleted the post, dont know why deleted or whether a good suggestion but try avisynth original install
rather than MT.

[Gargamel]

Alas, no Ghost image here ;-(

I have to go now, but to-morrow morning I'll reinstall Avisynth.
Then I'll come back here, to tell you the news.

Ha, I see the MT suggestion. I can try another version too (but my problem came, without I modify my installation, neither my existing MT).
Thank you again.

[Keiyakusha]

Yeah at first I though the problem is similar, but after re-reading 1st post of this thread I decided that it is unlikely after all, thus deleted the post in hope that no one saw it yet. ^__^

[IanB]

winerror 0x7e 126 ERROR_MOD_NOT_FOUND

You are missing a needed support module (library?) for Deflicker.dll

[StainlessS]

winerror 0x7e 126 ERROR_MOD_NOT_FOUND

You are missing a needed support module (library?) for Deflicker.dll

0x7.. I nearly suggested that but was not quite sure. Mr B is the man that can.

[TheFluff]

0x7.. I nearly suggested that but was not quite sure. Mr B is the man that can.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms681381%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/dd542642%28v=vs.85%29.aspx

[Gargamel]

Many thanks to everybody, wasting some time to help me !

I tried again to re-install AviSynth, but the same message appears when running a script:

http://img231.imageshack.us/img231/8804/vderror0x7edflckr.jpg (http://imageshack.us/photo/my-images/231/vderror0x7edflckr.jpg/)

These scripts are used to stabilize, clean etc some transfers of old Super 8 films.- They are based on videoFred's scripts, without a change here since a long time (when they ran well).

EDIT : http://forum.doom9.org/showthread.php?t=144271

That "VirtualDub error 0x7e" appears for the first plugin in a list to be loaded (not especially Deflicker, which is just an example), and disappears if I write the path of the DLL.

Usually, these scripts worked without a problem, even with such a part:

[...]
LoadPlugin("Deflicker.dll")
Loadplugin("Depan.dll")
LoadPlugin("DepanEstimate.dll")
Loadplugin("removegrain.dll")
LoadPlugin("removedirt.dll")
LoadPlugin("MVTools.dll")
LoadPlugin("MVTools2.dll")
Loadplugin("mt_masktools.dll")
Loadplugin("warpsharp.dll")
LoadPlugin("MT.dll")
LoadPlugin("autolevels.dll")
Import("03_RemoveDirtMC.avs")
[...]

Today, for the same script, I have to use (and then, no error message):

[...]
LoadPlugin("E:\Fred_restore\Deflicker.dll")
Loadplugin("E:\Fred_restore\Depan.dll")
LoadPlugin("E:\Fred_restore\DepanEstimate.dll")
Loadplugin("E:\Fred_restore\removegrain.dll")
LoadPlugin("E:\Fred_restore\removedirt.dll")
LoadPlugin("E:\Fred_restore\MVTools.dll")
LoadPlugin("E:\Fred_restore\MVTools2.dll")
Loadplugin("E:\Fred_restore\mt_masktools.dll")
Loadplugin("E:\Fred_restore\warpsharp.dll")
LoadPlugin("E:\Fred_restore\MT.dll")
LoadPlugin("E:\Fred_restore\autolevels.dll")
Import("E:\Fred_restore\03_RemoveDirtMC.avs")
[...]

And each line can be concerned...
For instance:

[...]
LoadPlugin("E:\Fred_restore\Deflicker.dll")
Loadplugin("E:\Fred_restore\Depan.dll")
LoadPlugin("E:\Fred_restore\DepanEstimate.dll")
Loadplugin("E:\Fred_restore\removegrain.dll")
LoadPlugin("removedirt.dll")
LoadPlugin("E:\Fred_restore\MVTools.dll")
LoadPlugin("E:\Fred_restore\MVTools2.dll")
Loadplugin("E:\Fred_restore\mt_masktools.dll")
Loadplugin("E:\Fred_restore\warpsharp.dll")
LoadPlugin("E:\Fred_restore\MT.dll")
LoadPlugin("E:\Fred_restore\autolevels.dll")
Import("E:\Fred_restore\03_RemoveDirtMC.avs")
[...]

will give the same error 0x7e, but for removedirt.dll, and so on :

http://img266.imageshack.us/img266/4366/vderror0x7ermvdrt.jpg (http://imageshack.us/photo/my-images/266/vderror0x7ermvdrt.jpg/)

For all scripts, the exact part between quotes is concerned.
So, in another script by videoFred:

[...]
LoadPlugin("plugins/Deflicker.dll")
[...]

will give the same message, for "plugins/Deflicker.dll" :

http://img822.imageshack.us/img822/6805/vderror0x7eplgnsdflckr.jpg (http://imageshack.us/photo/my-images/822/vderror0x7eplgnsdflckr.jpg/)

Well, I'll "update" (?) my scripts, with full path indication.
It's probably not too serious ;-))

Thanks again !

[StainlessS]

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

Thanks TheFluff, got a list of those error codes somewhere, but not a clue where.

@Gargamel,
It looks like videoFred's script using eg "LoadPlugin("Deflicker.dll")" without full path
was loading the dll's from the default plugins directory (as set in registry, which would be
unnecessary as plugins in default plugins directory are auto loaded anyway, along with avsi scripts).

When you say this works "LoadPlugin("E:\Fred_restore\Deflicker.dll")", it is possible that
you changed the default Avisynth plugins dir to "E:\Fred_restore\" and reinstalling Avisynth
reset the default dir to "C:\Program Files\AviSynth 2.5\plugins" which is now perhaps empty
(as you stripped dll's from it). OR, perhaps you edited VideoFred's script yourself, removing the path
and using the standard Avisynth default plugins directory, again reloading the already autoloaded plugins
would not be necessary.

The path in regedit (Start/Run/Regedit on XP) for standard Avisynth is

HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth

and should have a

plugindir2_5 REG_SZ C:\Program Files\Avisynth 2.5\plugins

setting as standard.

As for the 0x7E error, as IanB said, you seem to be missing a CPP runtime.

I have installed on my system, cpp runtimes for vs6(98), vs 2005, vs 2008, vs 2010

As I also run into problems with missing dll's for some utilities, I also copied
files:

mfc70.dll
mfc71.dll
mfc80.dll
msvcp70.dll
msvcp71.dll
msvcp80.dll
msvcr70.dll
msvcr71.dll
msvcr80.dll

into my System32 directory, if any already exist, omit that file (not sure if xxx8 files should be in there).

I think I originally got above files from and earlier version of Nero Burning Rom.
I dont have the redistributable cpp runtimes installer for that version which I take to be
needed for MS vcpp 2003 or MS vcpp Toolkit 3.

Check you have all of the above redistirbutable runtimes installed.

By the way, Deflicker from 2004 was compiled with TK3 so probably/maybe needs the above mentioned files.
http://avisynth.org.ru/deflicker/deflicker.html

EDIT: List of some dll files beginning msvc in my system32 (XP32)

msvcp50.dll
msvcp60.dll
msvcp60d.dll
msvcp70.dll
msvcp71.dll
msvcp80.dll
msvcr100_clr0400.dll
msvcr70.dll
msvcr71.dll
msvcr80.dll
msvcrt.dll
msvcrt20.dll
msvcrt40.dll
msvcrtd.dll

[Gavino]

As for the 0x7E error, as IanB said, you seem to be missing a CPP runtime.
Not necessarily - you also get the 0x7E error if the plugin DLL itself cannot be found, which appears to be Gargamel's problem.

LoadPlugin() calls the standard Windows API function LoadLibrary() to load the DLL. This is supposed to search the current directory (among other places - see here (http://msdn.microsoft.com/en-gb/library/windows/desktop/ms682586%28v=vs.85%29.aspx)), which here is the one containing the script. However, I have had problems with this in the past and always make a point of using the full path for LoadPlugin().

[StainlessS]

Darn, forgot altogether that current_directory is also searched.
Would perhaps be beneficial to check if an alternative to VD produces similar error ?
(something prevents current dir seach or changes current dir).
EDIT: Perhaps an autoload avsi changes WorkingDir, would that have effect ?

[Gargamel]

StainlessS:

Thank you a lot, for these details about your XP.
Here, I have MS Visual C++ 2005 Redistributable, three "2008 - x86" (9.0.21022, 9.0.30729.17, 9.0.30729.4148), and one "2010" (10.0.40219) installed.

Among your file list, my \\System32 contains mfc71.dll, msvcp70.dll, msvcp71.dll, msvcr71.dll
But no mfc70.dll, neither mfc80.dll, msvcp80.dll, msvcr70.dll, msvcr80.dll, msvcp60d.dll, msvcrtd.dll

But no recent uninstall...

The lines in HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth are OK.

And no script with a wrong GetWorkingDir...

Gavino:

Thank you too. The more I re-install and verify my Avisynth, the more I begin to suppose it's my Windows XP that could have a little problem.

As I have no specific message directly from Windows ("x dll missing"), before trying to install other C++ runtimes, I'll study the "DLL Search Order" page that you linked: maybe I'll understand a bit more ;-)
I see that yourself << have had problems with this in the past and always make a point of using the full path for LoadPlugin().>>

Well, I'm not alone !!!

[clsid]

You need to add the plugin dir to %PATH% environment variable.

[StainlessS]

You need to add the plugin dir to %PATH% environment variable.

Think a reboot or logoff/on would be necessary in that case (not sure).

But no mfc70.dll, neither mfc80.dll, msvcp80.dll, msvcr70.dll, msvcr80.dll, msvcp60d.dll, msvcrtd.dll

If you search your "Program Files" directory, you will probably find several sets of such there.

[Gargamel]

Whouahouw !

Adding the plugin dir of Avisynth to %PATH% environment variable, as suggested by clsid, resolved the problem for a lot of my scripts.
Bravo, and thank you !

Now, I have my issue with special scripts only (for instance, by videoFred) which list some lines like:
LoadPlugin("plugins/xyz.dll")

The script is inside a specific folder (like E:\Fred_A) which contains a subfolder (plugins); all the DLL are in that subfolder.

In the past, Avisynth found itself the good path to load these plugins.

OK, now I'll replace each
LoadPlugin("plugins/xyz.dll")
by a
LoadPlugin("xyz.dll"),
assuming of course I copy xyz.dll in the Avisynth "plugins" folder.

At least, now, Avisynth knows how to open these damned DLL !

Thanks a bunch...

[Gavino]

OK, now I'll replace each
LoadPlugin("plugins/xyz.dll")
by a
LoadPlugin("xyz.dll"),
assuming of course I copy xyz.dll in the Avisynth "plugins" folder.
If it's in the plugins folder, you don't need LoadPlugin at all, as it should be loaded automatically.

[Gargamel]

OK, if I understand, on my system, LoadPlugin doesn't work at all... :-( , but the %PATH% specification allows Avisynth to load the DLLs in stock, and to run :-)

EDIT:
- No, LoadPlugin works, but has to be used only when the DLLs aren't stocked in the Avisynth plugins folder. And I have then to write the whole path of the DLLs.
- But if these DLLs are in that specific folder, no need of LoadPlugin...

[clsid]

When 'safe' DLL loading is enabled in the parent application, or globally in Windows, then the working directory is not searched when loading a DLL. This is a security feature.
So you either need to supply the full path for each DLL, or add the location of the DLLs to %PATH%.

[StainlessS]

or globally in Windows

Would that be a group policy/local security type setting ?

@Gargamel, Have you recently updated VD ?

[Gargamel]

When 'safe' DLL loading is enabled in the parent application, or globally in Windows, then the working directory is not searched when loading a DLL. This is a security feature.
So you either need to supply the full path for each DLL, or add the location of the DLLs to %PATH%.

On the MS page about Dynamic-Link Library Search Order, they say that for Windows XP: "Safe DLL search mode is enabled by default starting with Windows XP with Service Pack 2 (SP2)." Then, "the App Paths key is not used when computing the DLL search path."

So, how can Avisynth load DLLs which are just near of the script we launch, in the same folder? I suppose that is the critical point.
As suggested by StainlessS, maybe there is a special security setting for Avisynth search...

EDIT: Sorry for my mistake. I thought (wrongly??) that, as soon as an AVS script was launched, in any folder, the DLLs placed in the same folder were automatically loaded by LoadPlugin...
All my plugins were in the Avisynth plugins folder. But I don't know why the program ceased to search inside it (or why its PATH flew away).- My Windows may be corrupted a bit (reinstalled Visual C++ 2005-SP1 and 2010-SP1; no change)...


@Gargamel, Have you recently updated VD ?

I use VD.1.10.2 since last June. No problem so far.

[Gavino]

When 'safe' DLL loading is enabled in the parent application, or globally in Windows, then the working directory is not searched when loading a DLL. This is a security feature.
According to the link I mentioned earlier
http://msdn.microsoft.com/en-gb/library/windows/desktop/ms682586%28v=vs.85%29.aspx
the working directory is still searched - it is just placed later in the search order, after the 'system' and 'windows' directories.

[StainlessS]

Text at end of this MS page http://msdn.microsoft.com/en-gb/library/windows/desktop/ff919712%28v=vs.85%29.aspx

"To use Process Monitor to examine DLL load operations in your application"

might prove interesting.

[clsid]

According to the link I mentioned earlier
http://msdn.microsoft.com/en-gb/library/windows/desktop/ms682586%28v=vs.85%29.aspx
the working directory is still searched - it is just placed later in the search order, after the 'system' and 'windows' directories.
True, but some apps clear the value of the working dir internally. For example MPC-HC.

[StainlessS]

I've just noticed a problem perhaps related to yours.
Have recently installed ffms2-r725-2 (Have never really tried it before).

With ffms2 plugin (& ffms2.avsi script, ffmsindex.exe) in plugins dir:

Script not using above ffms2 plugin, opened script with VDMod, opens OK.
Same script opened in VDMpeg2, OK.
Same script opened in VD 1.9.11 build 32824,
Gives this message:

"Avisynth Open failure:
Unable to load C Plugin: "ffms2.dll, error=0x7e
(FFMS2.avsi, line 3)"

VD 1.10.2 build 34807 (latest), same error.

Removed ffms2 (and related stuff) from plugins:

Works ok, no errors in all version of VD.

VD seems to be culprit, but ffms2 may not be blame free either.

EDIT: A script as simple as


Colorbars()


produces the problem.

EDIT: VDub v1.8.8 gives same error too.
EDIT: Has to be a combination problem (both VD and ffms2), cannot believe that VD is totally responsible
as it is such a long time since VD 1.8.8 was released.

Anybody able to confirm similar error ?

[Gargamel]

Hello StainlessS,

Congratulations ! You had the idea to test another VD versions.

First, of course, everybody prefers a pure VirtualDub error, than a Windows failure... but that seemed too beautiful...

Second, a try of my VD.1.9.11.0 resolved all my problems, at once. With any script. Without a %PATH% specification. Perfect.

Third, a quick try of VD.1.10.3b9 was OK too.

I thought that the VD version was the culprit. But when testing VD.1.10.2 with its folders "plugins" and "plugins32" renamed to be deactivated, OK again to load the DLLs.

I have now to deactivate each (different) plugin, one after other, to know were the conflict is.

I have to thank you for your investigation and tests, for a reinstall of Visual C++ 2005-SP1 and 2010-SP1 was unsuccessful here... you spare me a heavy Windows repair (which wouldn't troubleshoot that VD problem!).

EDIT:
=> Here, the culprit seems to be "FFInputDriver.vdplugin" (from "ffinputdriver-bin-0.7-32.zip").
When it's copied in \VirtualDub\plugins32 folder, the error message pops up. As well for VD v.1.9.11, v.1.10.2, v.1.10.3 ... And the scripts run OK with each version, when that item is wiped out.

[StainlessS]

Ah, think VD plugins32 came into effect @ vd v1.8.0 (EDIT: VDMod & VDMpeg2 dont have plugins32)

Just removed FFInputDriver.vdplugin from my VD plugins32 dir (and kept ffms.dll etc in Avisynth plugins)
and tried colorbars script from VD 1.10.2beta again, and ...

would you believe it, works OK now. :)

Its got to be (my problem above) some kind of conflict between VD FFInputDriver.vdplugin and Avisynth ffms.dll.


Thought I'de just downloaded latest VD beta, did not see VD.1.10.3b9, does not seem to be available on sourceforge.

EDIT: FFInputDriver.vdplugin version I have seems to be latest from 12 Jan 2012:
http://code.google.com/p/ffinputdriver/downloads/list

[Gargamel]

Happy end is coming now !

Concerning the last version of VD, it's the "VirtualDub-1.10.3-test9.zip" that I renamed VD.1.10.3b9 :
http://forums.virtualdub.org/ -> VirtualDub -> Testing / Bug Reports -> first page of "Pinned: Virtaldub 1.10.3 Test Thread"

I copied my "ffinputdriver-bin-0.7-32.zip" from http://codecpack.co/download/FFInputDriver.html
They say : Latest version: 0.7 (26 Jan 2012), but the "FFInputDriver.vdplugin" is 22 Jan 2012 dated (and the four ffDLL, 17 Jan 2012 dated) .

[StainlessS]

Thanks, got the VD 1.10.3beta9 now.

Was wrong about vd plugin version date (was date of download, I think), mine seems to be Aug 2011,
have downloaded linked version and will see what happens.

EDIT: looks like FFInputDriver.vdplugin is screwing up current directory, and in my case, the ffms.avsi loads
ffms.dll without path, so is a problem. In your case, it is your script that wants to load current dir relative,
and so screws up. It is the same problem with slightly different symptoms.
Presumably, it changes current working directory to ffdlls directory inside of the VD plugins32 directory.
Also presumably, some versions of VD keep the current directory as set by FFInputDriver.vdplugin, instead
of setting the current directory to that of the loading Avisynth script (possibly, maybe, perhaps).

EDIT: With latest VD 1.10.3beta9 and your linked VD FFInputDriver.vdplugin, all other VD plugins removed, colorbars problem persists.