Tested the dlls and seems like this happens when dui70.dll (version 6.1.7600.16385) is inside the same folder as DGIndexNV.dll
Since I'm not sure why that specific dll is inside the folder I'll simply rename it till I stumble over a filter that doesn't work anymore.
(No clue why that dll would interfere with DGDecNV.)
Cu Selur
[RESOLVED] DGIndexNV closing,... (DG 2053.0.0.172 + NV 419.35)
Re: DGIndexNV closing,... (DG 2053.0.0.172 + NV 419.35)
Why are you putting windows DLLs in the plugin dir? It makes no sense.
I don't know why a stand-alone Avisynth would need to copy windows DLLs. And if it must do so, then it's a very bad idea.
Of course any windows application is going to reference windows DLLs. If you put rogue DLLs in the same directory as the app, then it is very likely to cause problems as they will be loaded instead of the correct ones.No clue why that dll would interfere with DGDecNV.
Of course I know what DLLs my app explicity loads. For DGIndexNV they are windows DLLs and NVDec DLLs. Without the source code to windows, however, I don't know what child DLLs are loaded for standard things like opening a vanilla file open dialog. I expect there is a whole chain of them. And all these need to be correct and consistent. If you put a subset of unknown ("rogue") windows DLLs in the same directory as the app, then behavior will be undefined.I assumed that you should know which .dlls your compiled binary relies on and tries to load, but that doesn't seem to be the case.
I don't know why a stand-alone Avisynth would need to copy windows DLLs. And if it must do so, then it's a very bad idea.
Re: DGIndexNV closing,... (DG 2053.0.0.172 + NV 419.35)
Avisynth itself isn't the problem, but some older filters
Re: DGIndexNV closing,... (DG 2053.0.0.172 + NV 419.35)
Still hard to believe.