AviSynth+ thread Vol.2 [Archive] - Page 63

View Full Version : AviSynth+ thread Vol.2

Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 [63] 64 65 66 67 68 69 70 71 72 73 74 75

LeXXuz

16th February 2025, 15:08

There must be a ConvertStacked.DLL in your Program Files (x86)/Avisynth+/plugins64+ (or plugins+ on 32-bit) folder

MeGUI again. :mad: It somehow disliked my updated files and replaced/renamed them on its own. I guess it's about time to switch to a different frontend. :rolleyes:

Thanks pinterf, works fine now. :thanks:

gispos

16th February 2025, 19:28

Runtimes are probably needed, but I cannot check since I already have them on my machine because of the tests. The Intel build should be quicker. In this case, the XP builds are using the Visual Studio 2017 compiler, so they probably lack all the 2019 and 2022 Microsoft compiler optimizations. Even if the Intel build were equal to an MSVC 2022 build, the XP builds using 2017 technology are probably slower. However, this may be an urban legend. I guess, the actual speed gain is negligible unless you do synthetic tests using only internal Avisynth functions without using external scripts.
The Intel build behaves very strangely on my PC.
Before installing the runtimes, AvsPmod worked perfectly with the Intel build.
But I could not open a script with any other program.

After installing this Intel® oneAPI DPC++/C++ Compiler Runtime for Windows* 2025.0.0 (https://www.intel.com/content/www/us/en/developer/articles/tool/compilers-redistributable-libraries-by-version.html), every program I try to open a script with crashes. Also AvsPmod does not run anymore.
What is the error?

VDub2 chrash:

Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'VirtualDub64'...

...reading address 0000000000000000.

Edit:
I uninstalled the runtimes and AvsPmod is running again with the Intel build. But no other program.

tormento

17th February 2025, 19:13

Please notice that the latest Intel Runtimes are not 2025.0.0 but here (https://www.intel.com/content/www/us/en/developer/tools/oneapi/runtime-versions-download.html?runtimes=cpp-win).

isidroco

18th February 2025, 02:41

I hope those intel runtimes won't be required for future 3.74 version, as most of users don't have them installed.

Offtopic: Is there a way to manual install AviSynth 3.7.3+ (is there a .reg file to do it?) Thanks!

FranceBB

18th February 2025, 05:05

I hope those intel runtimes won't be required for future 3.74 version, as most of users don't have them installed.

as long as you pick the MSVC builds you won't need them.
Those are in the x86 x64 folders (v143) or x86_xp x64_xp (v141). ;)

real.finder

18th February 2025, 11:16

Offtopic: Is there a way to manual install AviSynth 3.7.3+ (is there a .reg file to do it?) Thanks!

try https://forum.doom9.org/showthread.php?t=172124

gispos

18th February 2025, 16:20

I have linked the runtimes that Ferenc has linked and that is 2025.0.0
Tormento links version 2025.0.4

With 2025.0.0 every program crashes and I'm annoyed that I now have the garbage left on my system.
I can't believe that 2025.0.4 should behave differently than the 2025.0.0 linked by Ferenc.

Can someone make a clear statement about this before I install another 800mb.
Thanks

tormento

18th February 2025, 19:49

Can someone make a clear statement about this before I install another 800mb.
With 2025.0.0 I had crashes when encoding and everything seems fine now with 2025.0.4.

But perhaps it's just a coincidence or a solar flare.

I never had any other sort of problems but the encoding part, perhaps as it's very intensive.

If you don't want to install 800 MB crap, simply use the MSVC version. :p

DTL

19th February 2025, 06:20

"I'm annoyed that I now have the garbage left on my system."

Old intel compilers builds do not need to install (register) anything in OS. You only need to add required .dlls in the path (put in the same folder as the AVS .dll or plugin .dll) so that OS executable file loader can find them. It is typically only a pair of dlls. So for 'uninstall' you only delete that .dlls if required.
They are typically libmmd.dll and svml_dispmd.dll . May be it is 'illegal' for freeware software developers to include required intel .dlls in the distributtion (upload to github in release archive ?). But official intel redistributable (with executable installer) may install something more and it can affect other software.

pinterf

19th February 2025, 10:24

Oh sorry, I didn't know that it causes so much trouble. Neither know why Intel do not refresh their page with their latest 2025.0.4 version.
I think next time it's better to do the Intel stuff using static linked libraries.

StvG

19th February 2025, 16:52

Old intel compilers builds do not need to install (register) anything in OS. You only need to add required .dlls in the path (put in the same folder as the AVS .dll or plugin .dll) so that OS executable file loader can find them. It is typically only a pair of dlls. So for 'uninstall' you only delete that .dlls if required.
They are typically libmmd.dll and svml_dispmd.dll .

It's the same for the new Intel compilers too.

isidroco

20th February 2025, 14:41

You only need to add required .dlls in the path ...
They are typically libmmd.dll and svml_dispmd.dll .
Manually extracted those DLL from latest intel_w_dpcpp_cpp_runtime_p_2025.0.4.1522 and copied both to SYSTEM32 and Plugins64 folders. But new avisynth doesn't work.
After previous comments, I refuse to install intel redistributable and will stick with previous AvisynthPlus_3.7.3post_20240131_test14 which doesn't require other "risky" installations.

FranceBB

20th February 2025, 16:10

will stick with previous AvisynthPlus_3.7.3post_20240131_test14 which doesn't require other "risky" installations.

Why?
Just use the x86_xp or x64_xp builds, they were compiled with MSVC as usual (i.e the Microsoft v141_xp compiler).

DTL

23rd February 2025, 11:19

Manually extracted those DLL from latest intel_w_dpcpp_cpp_runtime_p_2025.0.4.1522 and copied both to SYSTEM32 and Plugins64 folders. But new avisynth doesn't work.

Asd-g recommend software for analyse for required dependencies - https://github.com/lucasg/Dependencies/releases . May be other .dlls are required for latest builds with ICX compiler.

At Win10 host it shows only libmmd.dll is missing -
https://i.postimg.cc/SxWZ6wCv/2025-02-23-132346.png
https://i.postimg.cc/SxWZ6wCv/2025-02-23-132346.png

Though libmmd.dll may depend on other Intel .dlls - may be needed to add all one by one.

pinterf

24th February 2025, 12:27

Aside from the 2025.0.0 vs 2025.0.4 issue:

The only Intel-specific DLL that the Intel-built AviSynth requires is libmmd.dll, which is a "high performance multithreaded math library." This library likely implements non-standard Intel intrinsics like _mm_sin_ps or _mm_atan2_ps, as well as their 64-bit double versions for trigonometric and other functions.

On my machine, libmmd.dll is located in:
C:\Program Files (x86)\Common Files\intel\Shared Libraries\intel64\
For AvsPMod I had to move this DLL next to avisynth.dll in C:\Windows\System32 to get it to work.

For testing, I loaded AviSynth with:

ctypes.WinDLL('C:\Windows\system32\AviSynth.dll')

It failed to load the Intel-built Avisynth.dll when the libmmd.dll was not next to it.

Seems like this DLL load method does not search the PATH for DLL dependencies.

However I was able to load AviSynth.dll using a different method (altered search path), like this:

import ctypes
from ctypes import wintypes

LOAD_WITH_ALTERED_SEARCH_PATH = 0x00000008

kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)
LoadLibraryExW = kernel32.LoadLibraryExW
LoadLibraryExW.argtypes = [wintypes.LPCWSTR, wintypes.HANDLE, wintypes.DWORD]
LoadLibraryExW.restype = wintypes.HMODULE

def load_library_with_altered_search_path(dll_path):
return kernel32.LoadLibraryExW(dll_path, None, LOAD_WITH_ALTERED_SEARCH_PATH)

handle = load_library_with_altered_search_path(path)
if not handle:
raise ctypes.WinError(ctypes.get_last_error())

avidll = ctypes.WinDLL("", handle=handle)

Anyway, my advice is that if someone is using the Intel build with AvsPMod, they should move the necessary libmmd.dll next to Avisynth.dll.

This is applicable if we build it with the /MD option, which requires dynamic linking of the runtime libraries. If we use the /MT option for building Avisynth, it statically links all necessary components into the executable, i can see no extra dependencies.

Probably next time, folks.

StvG

24th February 2025, 13:14

This is applicable if we build it with the /MD option, which requires dynamic linking of the runtime libraries. If we use the /MT option for building Avisynth, it statically links all necessary components into the executable, i can see no extra dependencies.

You can keep /MD and add libmmds.lib/svml_disp.lib to the additional linker dependencies - you have MSVC dynamic runtimes with Intel static runtimes. This is how the Intel builds are created here (https://gitlab.com/uvz/AviSynthPlus-Builds).

pinterf

24th February 2025, 14:15

You can keep /MD and add libmmds.lib/svml_disp.lib to the additional linker dependencies - you have MSVC dynamic runtimes with Intel static runtimes. This is how the Intel builds are created here (https://gitlab.com/uvz/AviSynthPlus-Builds).
Thanks, so far I just blindly used Avisynth's CMake build ready made out-of-box.

pinterf

24th February 2025, 16:18

AviSynth+ r4198

Enjoy the life.

https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4198

gispos

24th February 2025, 18:11

AviSynth+ r4198

Enjoy the life.

https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4198
Unfortunately I have no luck with the r4198 icx build
No program wants to open an avs.

https://i.postimg.cc/zXSwwh0Y/Avisynth-r4198icx-error.jpg (https://postimages.org/)

Am I missing something else?
I think I have all the normal runtimes installed, at least every other Avisynth version has worked so far.

DTL

24th February 2025, 18:51

"optional AVX2 code paths"

From the end of 2024 we have 'full-blood' 512bit AVX512 processing in the Zen5 desktop AMD CPUs for end-users. If it is runtime-selectable it may be good to add also AVX512 auto-optimizations by Intel compiler (in the same file or in separate build).

"I have no luck with the r4198 icx build"

Zero address crash is not simple 'missing .dll' error - it is something more complex. Can you run with debugger attached to show if it is crash in VirtuaDub module and not in avisynth.dll module ? You can first run VirtualDub and attach debugger to its PID and next try to open .avs.

With VirtualDub 1.10.4 at Win7 x64 and E7500 CPU I got not crash but some unknown error in Avisynth :
https://i.postimg.cc/bYQsbZ3H/image-2025-02-24-210210972.png
https://i.postimg.cc/bYQsbZ3H/image-2025-02-24-210210972.png

If attempt to open "version" script (or any other script too ?).

Looks like this error message from AVS core https://github.com/pinterf/AviSynthPlus/blob/57fa8f9e5fe5e871b0658a486d17ea061b096a8e/avs_core/core/main.cpp#L957 . So it loads all libraries OK but something else not working.

Avisynth.dll from "x64_xp_or_better" folder is working.

pinterf

24th February 2025, 20:00

I was trying the famous rife script with this intel build and the latest avspmod. What can be the difference? I'm on w11pro, 11th gen i7. It worked fine.

gispos

24th February 2025, 20:48

VirtualDub2_64
The Avisynth.dll is loaded and after the VCRUNTIME140_1.dll is loaded the error starts.
Is it possible that the VCRUNTIME140 is not compatible with the Intel runtimes? Or are there newer VC runtimes after all?
Note: Fehler = Error

Ereigniszeit Ereignisart Thread-ID Speicheradresse Dateinam
00:01:32.426 DLL laden 6264 00007ff9`a43c0000 C:\Windows\SYSTEM32\AviSynth.dll
00:01:32.427 DLL laden 6264 00007ff9`f0010000 C:\Windows\System32\imagehlp.dll
00:01:32.427 DLL laden 6264 00007ff9`ac020000 C:\Windows\SYSTEM32\MSVCP140.dll
00:01:32.428 DLL laden 6264 00007ff9`e2d80000 C:\Windows\SYSTEM32\VCRUNTIME140.dll
00:01:32.428 DLL laden 6264 00007ff9`e9d30000 C:\Windows\SYSTEM32\VCRUNTIME140_1.dll
00:01:32.429 Fehler 6264 00007ff9`ac033028 Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000
00:01:32.430 Fehler 6264 00007ff9`ee31b699 Fehlercode: 0xe06d7363, Parameter: , 0x19930520, 0x004fe740, 0x200905f0, 0x1fc70000
00:01:32.478 Fehler 6264 00007ff9`ac033028 Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000
00:01:32.478 Fehler 6264 00007ff9`ac033028 Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000
00:01:36.003 Thread beenden 7304 Austrittscode: 0xc0000005

pinterf

24th February 2025, 21:34

"optional AVX2 code paths"

With VirtualDub 1.10.4 at Win7 x64 and E7500 CPU I got not crash but some unknown error in Avisynth
E7500 is good up to SSE4.1, I examined and searched the Intel compiler switches again, but they tell that the base "Not Set" processor level is for SSE2, and the /QaxCORE-AVX2 defines the alternative code path.

I don't know this VirtualDub version, where is it from? I'm using VirtualDub2 44282, please try with it, or with an even newer one.

pinterf

24th February 2025, 21:37

DTL

24th February 2025, 22:58

VirtualDub 1.10.4 is build 35491. It is from some old decades 201x or 200x . With build 44282 it is really crashed but make more valuable crashlog with some call stack info:

VirtualDub2 crash report -- build 44282 (release-AMD64)
--------------------------------------

Disassembly:
7fee0052e20: 4883c108 add rcx, 08h
7fee0052e24: e93f880200 jmp e007b668
7fee0052e29: cc int 3
7fee0052e2a: cc int 3
7fee0052e2b: cc int 3
7fee0052e2c: 48895c2418 mov [rsp+18h], rbx
7fee0052e31: 56 push esi
7fee0052e32: 57 push edi
7fee0052e33: 4156 push esi
7fee0052e35: 4883ec40 sub rsp, 40h
7fee0052e39: 488b0558380700 mov rax, [e00c6698]
7fee0052e40: 4833c4 xor eax, esp
7fee0052e43: 4889442430 mov [rsp+30h], rax
7fee0052e48: 8b01 mov eax, [rcx]
7fee0052e4a: 4c8bf2 mov r14, edx
7fee0052e4d: 0fbaf008 btr eax, 08h
7fee0052e51: 488bf1 mov rsi, ecx
7fee0052e54: 83f801 cmp eax, 01h
7fee0052e57: 752c jnz e0052e85
7fee0052e59: ff1541230400 call dword ptr [e00951a0]
7fee0052e5f: 394648 cmp [rsi+48h], eax
7fee0052e62: 7419 jz e0052e7d
7fee0052e64: 488d4e08 lea rcx, [rsi+08h]
7fee0052e68: 488b01 mov rax, [rcx]
7fee0052e6b: 488b00 mov rax, [rax]
7fee0052e6e: ff15ac270400 call dword ptr [e0095620]
7fee0052e74: ff1526230400 call dword ptr [e00951a0]
7fee0052e7a: 894648 mov [rsi+48h], eax
7fee0052e7d: ff464c inc dword ptr [rsi+4ch]
7fee0052e80: e9f3000000 jmp e0052f78
7fee0052e85: 4d85f6 test esi, r14
7fee0052e88: 7524 jnz e0052eae
7fee0052e8a: ff1510230400 call dword ptr [e00951a0]
7fee0052e90: 394648 cmp [rsi+48h], eax
7fee0052e93: 0f849d000000 jz e0052f36
7fee0052e99: 488d4e08 lea rcx, [rsi+08h]
7fee0052e9d: 488b01 mov rax, [rcx]
7fee0052ea0: 488b00 mov rax, [rax] <-- FAULT
7fee0052ea3: ff1577270400 call dword ptr [e0095620]
7fee0052ea9: e988000000 jmp e0052f36
7fee0052eae: 48833a00 cmp qword ptr [rdx], 00h
7fee0052eb2: 7c62 jl e0052f16
7fee0052eb4: 7506 jnz e0052ebc
7fee0052eb6: 837a0800 cmp dword ptr [rdx+08h], 00h
7fee0052eba: 7e5a jle e0052f16
7fee0052ebc: ba01000000 mov edx, 00000001
7fee0052ec1: 488d4c2420 lea rcx, [rsp+20h]
7fee0052ec6: e8b5080000 call e0053780
7fee0052ecb: 488b442420 mov rax, [rsp+20h]
7fee0052ed0: 493b06 cmp eax, [r14]
7fee0052ed3: 7c0c jl e0052ee1
7fee0052ed5: 757d jnz e0052f54
7fee0052ed7: 418b4608 mov eax, [r14+08h]
7fee0052edb: 39442428 cmp [rsp+28h], eax
7fee0052edf: 7d73 jge e0052f54
7fee0052ee1: ff15b9220400 call dword ptr [e00951a0]
7fee0052ee7: 394648 cmp [rsi+48h], eax
7fee0052eea: 744a jz e0052f36
7fee0052eec: 488b4608 mov rax, [rsi+08h]
7fee0052ef0: 488d542420 lea rdx, [rsp+20h]
7fee0052ef5: 498bce mov rcx, esi
7fee0052ef8: 488b5810 mov rbx, [rax+10h]
7fee0052efc: e86f070000 call e0053670
7fee0052f01: 8bd0 mov edx, eax
7fee0052f03: 488d4e08 lea rcx, [rsi+08h]
7fee0052f07: 488bc3 mov rax, ebx
7fee0052f0a: ff1510270400 call dword ptr [e0095620]
7fee0052f10: 84c0 test al, al
7fee0052f12: 7522 jnz e0052f36
7fee0052f14: eba6 jmp e0052ebc
7fee0052f16: ff1584220400 call dword ptr [e00951a0]
7fee0052f1c: 394648 cmp [rsi+48h], eax
7fee0052f1f: 74 db 74h

Built on Anton4 on Fri Mar 20 00:39:05 2020 using compiler version 1500

Windows 6.1 (Windows 7 x64 build 7601) [Service Pack 1]
Memory status: virtual free 8388407M/8388608M, commit limit 7895M, physical total 3199M

RAX = 0
RBX = 7fede4c5e2b
RCX = 3c219d0
RDX = 0
RSI = 3c219c8
RDI = 3c21930
RBP = 31bf40
R8 = 31c050
R9 = ffffffffffffee21
R10 = 0
R11 = 286
R12 = ffffffff
R13 = 0
R14 = 0
R15 = 31c708
RSP = 31beb0
RIP = 7fee0052ea0
EFLAGS = 00010286

Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'VirtualDub64'...

...reading address 0000000000000000.

Pointer dumps:

RBX 7fede4c5e2b: 65757274 75725400 6f630065 6e69746e 68006575 61767865 0065756c 3a726f66
RCX 03c219d0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
RSI 03c219c8: 00000002 00690057 00000000 00000000 00000000 00000000 00000000 00000000
RDI 03c21930: 3f4ccccd 00000000 03c21800 00000000 00000000 00000000 03c2cd90 00000000
RSP 0031beb0: 00054be9 00000000 000f1983 00000000 001ed691 00000000 0013a7d1 00000000
0031bed0: 00f7fa0a 00000000 0040bf94 00000000 670cb5e9 000071af 00159000 00000000
0031bef0: 03c219c8 00000000 03c21930 00000000 0031c050 00000000 dd90fd6f 000007fe
0031bf10: 0000237f 00000000 0187f000 00000000 de4c5e2b 000007fe 0005e4f0 00000000
RBP 0031bf40: 03c21930 00000000 31f8b800 00000000 03c1af00 00000000 000505e0 00000000
0031bf60: 0031bff0 00000000 dd91bcd5 000007fe 03c21930 00000000 001555b0 00000000
0031bf80: 001555b0 00000000 03c21930 00000000 001207d8 00000000 00000040 00000039
0031bfa0: c7e2e000 00000000 54be9000 00000000 ed691000 00000001 fbd0e000 00000000
R8 0031c050: 00000062 00000039 00000001 00000000 54be9000 00000000 ed691000 00000001
R15 0031c708: 0031ea40 00000000 00000000 00000000 f56864a9 000007fe dd9f94ce 000007fe

Thread call stack:
7fee0052ea0: MSVCP140!_Thrd_yield [7fee0040000+12d60+140]
7fedd90fd6f: AviSynth!001ffd6f
7fedd91bcd5: AviSynth!avs_get_error [7fedd710000+2025c0+9715]
7fef1dd383f: ucrtbase!__stdio_common_vswprintf_s [7fef1dd0000+37a0+9f]
7fedd9121ec: AviSynth!CreateScriptEnvironment2 [7fedd710000+2021b0+3c]
7fedf7569f8: scripted!000069f8
7fedf7a3e43: scripted!VDGetPluginInfo [7fedf750000+8d40+4b103]
7fedf75fa6c: scripted!VDGetPluginInfo [7fedf750000+8d40+6d2c]
7fedf75fa6c: scripted!VDGetPluginInfo [7fedf750000+8d40+6d2c]
7fedf75fa6c: scripted!VDGetPluginInfo [7fedf750000+8d40+6d2c]
7fedf7d314b: scripted!VDGetPluginInfo [7fedf750000+8d40+7a40b]
7fedf7d314b: scripted!VDGetPluginInfo [7fedf750000+8d40+7a40b]
7fedf756898: scripted!00006898
7fedf752282: scripted!00002282
7fedf754b1d: scripted!00004b1d
7fedf751f45: scripted!00001f45
7782f615: USER32!SystemParametersInfoW [77820000+f4f0+125]
7782f5e7: USER32!SystemParametersInfoW [77820000+f4f0+f7]
77836850: USER32!IsDialogMessageW [77820000+166d0+180]
7782f668: USER32!SystemParametersInfoW [77820000+f4f0+178]
77a8d8f5: ntdll!KiUserCallbackDispatcher [77a40000+4d8d6+1f]
7fedf754e63: scripted!00004e63
77839ae6: USER32!TranslateMessageEx [77820000+19974+172]
778337b6: USER32!GetWindowLongPtrA [77820000+13794+22]
7fedf755191: scripted!00005191
13f355f09: VirtualDub64!000c5f09
13f5975c2: VirtualDub64!003075c2
77a8fa48: ntdll!RtlAllocateHeap [77a40000+4f8d0+178]
13f586790: VirtualDub64!002f6790
13f56b765: VirtualDub64!002db765
7fef56864a9: VCRUNTIME140!_set_se_translator [7fef5680000+62e0+1c9]
13f340f90: VirtualDub64!000b0f90
77a8d351: ntdll!RtlRestoreContext [77a40000+4d06f+2e2]
13f340f90: VirtualDub64!000b0f90
7fefdc62851: ole32!CoUninitialize [7fefdc40000+21324+152d]
7fefdc685c3: ole32!CoCreateInstance [7fefdc40000+274a0+1123]
7fefdc73fff: ole32!ObjectStublessClient4 [7fefdc40000+33de0+21f]
77933a3d: kernel32!RegOpenKeyExW [77920000+13a20+1d]
7fefdc685c3: ole32!CoCreateInstance [7fefdc40000+274a0+1123]
7fefe22d7a1: USP10!UspFreeMem [7fefe210000+1d740+61]
7fefdc53feb: ole32!CoGetTreatAsClass [7fefdc40000+13e90+15b]
13f340f90: VirtualDub64!000b0f90
77a690dd: ntdll!RtlDecodePointer [77a40000+28fb0+12d]
77a583db: ntdll!RtlUnwindEx [77a40000+18050+38b]
7fedd9f9069: AviSynth!DllCanUnloadNow [7fedd710000+2e6aa0+25c9]
13f340f90: VirtualDub64!000b0f90
13f340f90: VirtualDub64!000b0f90
7fedd9f9069: AviSynth!DllCanUnloadNow [7fedd710000+2e6aa0+25c9]
7fedd9f9069: AviSynth!DllCanUnloadNow [7fedd710000+2e6aa0+25c9]
77aba5eb: ntdll!RtlIsDosDeviceName_U [77a40000+55ac0+24b2b]
13f340f90: VirtualDub64!000b0f90
7fefdc62851: ole32!CoUninitialize [7fefdc40000+21324+152d]
7fefdc685c3: ole32!CoCreateInstance [7fefdc40000+274a0+1123]
7fefdc73fff: ole32!ObjectStublessClient4 [7fefdc40000+33de0+21f]
77933a3d: kernel32!RegOpenKeyExW [77920000+13a20+1d]
7fefdc685c3: ole32!CoCreateInstance [7fefdc40000+274a0+1123]
7fefe22d7a1: USP10!UspFreeMem [7fefe210000+1d740+61]
7fefdc53feb: ole32!CoGetTreatAsClass [7fefdc40000+13e90+15b]
7795051e: kernel32!RtlUnwindEx [77920000+30500+1e]
13f340f90: VirtualDub64!000b0f90
13f562b49: VirtualDub64!002d2b49
13f31e361: VirtualDub64!0008e361
7fefd8c3150: KERNELBASE!GetProcAddress [7fefd8c0000+30f0+60]
7fedd9f9069: AviSynth!DllCanUnloadNow [7fedd710000+2e6aa0+25c9]
7fef5686843: VCRUNTIME140!_set_se_translator [7fef5680000+62e0+563]
7fef568656a: VCRUNTIME140!_set_se_translator [7fef5680000+62e0+28a]
7fedd9f9069: AviSynth!DllCanUnloadNow [7fedd710000+2e6aa0+25c9]
13f56afae: VirtualDub64!002dafae
7fefdc77242: ole32!IsEqualGUID [7fefdc40000+34810+2a32]
7fedd9f9069: AviSynth!DllCanUnloadNow [7fedd710000+2e6aa0+25c9]
77a68e9e: ntdll!RtlLookupFunctionTable [77a40000+28df0+ae]
13f56afc7: VirtualDub64!002dafc7
13f5625f1: VirtualDub64!002d25f1
13f56afae: VirtualDub64!002dafae
13f56b96e: VirtualDub64!002db96e
13f56afc7: VirtualDub64!002dafc7
13f562530: VirtualDub64!002d2530
13f5625f1: VirtualDub64!002d25f1
13f56bc28: VirtualDub64!002dbc28
13f56b2aa: VirtualDub64!002db2aa
13f56c292: VirtualDub64!002dc292
13f56c611: VirtualDub64!002dc611
13f340f90: VirtualDub64!000b0f90
13f562773: VirtualDub64!002d2773
77a6905d: ntdll!RtlDecodePointer [77a40000+28fb0+ad]
77a58c0f: ntdll!RtlUnwindEx [77a40000+18050+bbf]
13f340f90: VirtualDub64!000b0f90
7fefdc5159a: ole32!CLSIDFromString [7fefdc40000+10680+f1a]
7fefdc516a7: ole32!CLSIDFromString [7fefdc40000+10680+1027]
13f31e361: VirtualDub64!0008e361
77936074: kernel32!RegGetValueW [77920000+15ed0+1a4]
77a8d948: ntdll!KiUserExceptionDispatcher [77a40000+4d91a+2e]
7fee0052ea0: MSVCP140!_Thrd_yield [7fee0040000+12d60+140]
77a59008: ntdll!RtlRaiseException [77a40000+18fc0+48]
77a59208: ntdll!RtlRaiseException [77a40000+18fc0+248]
7fefd8cb16d: KERNELBASE!RaiseException [7fefd8c0000+b130+3d]
77a8f9b8: ntdll!RtlAllocateHeap [77a40000+4f8d0+e8]
13f56afc7: VirtualDub64!002dafc7
13f565dc2: VirtualDub64!002d5dc2
13f56dff2: VirtualDub64!002ddff2

-- End of report

https://i.postimg.cc/157RM2d3/image-2025-02-25-010207178.png

Disassembly looks correct - RAX is zero and reading from zero address cause crash.

pinterf

25th February 2025, 09:26

I've created ReleaseWithDebug builds. These have the same speed as release builds (if they work :) ), but they may help to show where it crashes.

I've put together a zip file with four Intel ICX builds of Avisynth.dll and Avisynth.pdb. Each build comes with its corresponding PDB debug info file. Please copy both the DLL and PDB files into the System32 directory.

The variants are as follows (see folder names):

SSE2
SSE2 + AVX2
AVX2
AVX2 + AVX512 (for Ice Lake - 10th/11th gen i7 processors, for example)

You can download them from the link (the base pack is still there).
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4198

Thanks.

tormento

25th February 2025, 10:38

I've created ReleaseWithDebug builds..
As I am —still— an AVX user, do you think an Intel AVX build could be of any utility to have a small speed bump?

tebasuna51

25th February 2025, 10:46

pinterf

25th February 2025, 10:47

As I am —still— an AVX user, do you think an Intel AVX build could be of any utility to have a small speed bump?

No.
AVX is floating point only.
Unless you have a full-32-bit float workflow, which is using exclusively Avisynth internal filters.

pinterf

25th February 2025, 11:05

For me, and for users even more ignorant than me, please can you explain the limits and advantages of each compilation of Avs+?

There are the xp_or_better, the intel_icx (with 4 variants) but also Clang and intelLLVM (https://gitlab.com/uvz/AviSynthPlus-Builds/) builds.

If there are a stable build of Avs+ 3.8.0 for xp_or_better please do it, and after try better (saying for what) compilations of these versions.

You might only see a slight improvement, perhaps just a few percentage points. A typical script, which is a bit more complex than:

ColorBars.ConvertBits(32).ThisAndThatResize(4096,2048).ConvertBits(8, dither=1)
and is probably using many external filters, won't be processed visibly quicker. Personally, I wouldn't bother with them (though I don't use Avisynth myself; I'm just a developer). However, since using a faster option is free, why not give it a try?

I just note, since the additional builds require more time (5-30 minutes per build type) and computer power, I don't bother creating versions other than the stock XP-to-Win11 regular version in the early tests. More untested options lead to more user reports. The more choices given, the more requests: "Why not a special build for my i7-k18236812 or ZX-Spectrum?" :)

Jamaika

25th February 2025, 11:21

The variants are as follows (see folder names):
SSE2
SSE2 + AVX2
AVX2
AVX2 + AVX512 (for Ice Lake - 10th/11th gen i7 processors, for example)

Little green man. In avisynth and many add-ons, ALIGN is set for 64 memory, i.e. only for AVX512. What variants for older computers?
I wonder what will be soon for AVX10 and ALIGN 128.
As for Intel add-ons, I am surprised that I managed to add for gcc/mingw64. The general ones are for MSVCRT and the add-ons are paid.

Emulgator

25th February 2025, 14:06

Success here !
Win10P64, i9-11900K (AVX512) 128GB, RTX3080 16GB
Feeding AvsPmod64 2.7.9.2, or VD64 44282, or Topaz 2.6.4 all AviSynth64 builds 4198 work nice here:
20250224 WinXP or better, Intel ICX
20250225 ICXBase, ICXBase+AVX2, ICX AVX2, ICX AVX2+AVX512.
Untested by me so far: WinXP32, Win7x64
Under my environment all build versions seem compatible, no speed differences worth mentioning.
(I wasn't expecting any, given that my scripts and called plugins may not use higher AVX at all.)
Many thanks again, Ferenc !

P.S. That successfully testing system had MSVC Runtimes 14.42.34433.0
As found out by others in following posts, it may well be that these AviSynth+ICX builds only run under these more recent runtimes.
Will repeat tests soon with a similar mid-2024 frozen Win10P64 system (hopefully still) containing earlier runtimes.
P.P.S. An older Win7U64 system with runtimes from 2022 immediately reports access violation with the ICX Base build.

tebasuna51

25th February 2025, 14:19

My speed test:
W10 v1607, Ryzen 5 1600X, RAM 8 GB
Simple QTGMC(Preset="Fast", EZDenoise=2.0) over a DV.avi

AVSMeter 3.0.9.0 (x64), (c) Groucho2004, 2012-2021
AviSynth+ 3.7.3 (r4198, master, x86_64) (3.7.3.0)

Number of frames: 40430
Length (hh:mm:ss.ms): 00:13:28.600
Frame width: 720
Frame height: 572
Framerate: 50.000 (50/1)
Colorspace: YV12

xp-in-W10 r4198 icx-avx2 r4198 Clang r4198 intelLLVM r4198
----------------- ----------------- ----------------- -----------------
Frames processed: 40430 (0 - 40429) 40430 (0 - 40429) 40430 (0 - 40429) 40430 (0 - 40429)
FPS (min | max | average): 27.18|91.18|58.84 36.49|89.11|59.39 34.46|88.18|58.40 35.10|91.90|59.18
Process memory usage (max): 365 MiB 357 MiB 367 MiB 364 MiB
Thread count: 29 29 29 29
CPU usage (average): 28.6% 28.7% 28.5% 28.5%

Time (elapsed): 00:11:27.124 00:11:20.760 00:11:32.247 00:11:23.202
Seems for me the icx-avx2 is the winner, but only by 1% fast over the xp.

StvG

25th February 2025, 14:37

My speed test: ...

I hope you tested every variant at least 3 times (or at least twice) and used average/median for the final results in order to have more reliable test.

pinterf

25th February 2025, 15:23

I hope you tested every variant at least 3 times (or at least twice) and used average/median for the final results in order to have more reliable test.
Sometimes, I can see more than 1% difference between runs. Note also that the processor clock is not constant either. It's strange, but it also depends on how the memory was allocated, how the cache behaved, and how lucky the stars were at that moment of allocation. When the average starts showing a consistent 2% or more difference, one can be happy.

StvG

25th February 2025, 16:13

Sometimes, I can see more than 1% difference between runs. Note also that the processor clock is not constant either. It's strange, but it also depends on how the memory was allocated, how the cache behaved, and how lucky the stars were at that moment of allocation. When the average starts showing a consistent 2% or more difference, one can be happy.

You can add antivirus soft (if any), Windows SysMain (SuperFetch) to the equitation.

In some PC hardware forums when doing benches (Cinebench, Geekbench...) - antivirus is stopped and the bench app is assigned to the highest CPU priority. Several runs and the average/mean is taken.
Some folks go further and use a clean Windows installation just for the benches.

But when one see more than 5% difference, it's more likely caused by the different builds.

DTL

25th February 2025, 16:41

I've created ReleaseWithDebug builds.
I've put together a zip file with four Intel ICX builds of Avisynth.dll and Avisynth.pdb. Each build comes with its corresponding PDB debug info file. Please copy both the DLL and PDB files into the System32 directory.

Some good test results and some not very good:

1. At the 'fresh and rarely used' Win 7 x64 installation Base versions are working. The AVX2 and AVX2+AVX512 not crash but return some not very clear error in VirtualDub:

File open error (window title)
AVI Import Filter error: (Unknown) (80040154)
https://i.postimg.cc/v8nNDkzw/above-SSE.png

Also the 'main' release r4198 from 'x64_intel_icx' working too (in this Win 7 installation).

I use this Win7 installation mostly for rare things with MSVC2019 (and 2017) installed.

2. After reboot to my everyday used Win 7 x64 :
Base and initial release r4198 from 'x64_intel_icx' cause VirtualDub crash and AVX2 and AVX512 do not crash and display same
File open error (window title)
AVI Import Filter error: (Unknown) (80040154)
https://i.postimg.cc/v8nNDkzw/above-SSE.png

error message.

Unfortunately I do not have modern Visual Studio with x64 debugger installed in my 'everyday used' Win7 so can not use provided .pdb files. Any small and possibly portable x64 debugger for Win 7 can be recommended ? I do not have space to install Visual Studio in that Win 7 installation or it even can not run because of some damaging of system files (?). I do not remember why I uninstall it.

So the main test result: ICX builds can run in some 'fresh or very low/rare used' installations of Win 7 x64 but can cause Virtual Dub crash in some 'some time used or even some damaged' Win 7 x64 installations.

DTL

25th February 2025, 17:27

In avisynth and many add-ons, ALIGN is set for 64 memory, i.e. only for AVX512. What variants for older computers?
I wonder what will be soon for AVX10 and ALIGN 128.

It is not only for AVX512. It is up to AVX512 (and the case you have 8bit single byte samples in some planar format).

It is back compatible with AVX256 and SSE.

The more alignment used - the more RAM wasted at the end of rows for some row widths. But 64bytes alignment also still not enough for AVX512 if you process 16 or 32bit per sample formats.

Also it is not enough if we have row processing loops reading/storing >1 512bit dataword per loop iteration.

It was old idea to have plugin-requested row stride and alignment for frame buffers so the plugin can use faster and more simple in design SIMD loops without special end part for processing remaining samples not possible to read/write with main loop using many SIMD datawords read-writes if single SIMD dataword is long enough.

Any increased row stride and alignment (by power of 2) is back compatible with old plugins (I hope). But too large stride and alignment will waste too much RAM with small frame sizes.

So other idea was to make user-configurable from script command row stride and alignment. But it must be supported by internal plugin design to get some benefit on fast hosts with AVX(all families) CPUs or modern CPUs. So plugin can check at plugin init the provided by AVS core row stride and alignment and can select better SIMD processing functions (processing larger data blocks if possible for single data burst exchange between register file and caches or host RAM).

gispos

25th February 2025, 18:20

None of the 3 icx variants work for me, all programs crash.
I have no problems with xp_version, IntelLVM and Clang.

Also cannot use the pdb file. VDub2 shows the same RAX error with all three variants.

Jamaika

25th February 2025, 20:34

It is not only for AVX512. It is up to AVX512 (and the case you have 8bit single byte samples in some planar format).

It is back compatible with AVX256 and SSE.

The more alignment used - the more RAM wasted at the end of rows for some row widths. But 64bytes alignment also still not enough for AVX512 if you process 16 or 32bit per sample formats.

Also it is not enough if we have row processing loops reading/storing >1 512bit dataword per loop iteration.

It was old idea to have plugin-requested row stride and alignment for frame buffers so the plugin can use faster and more simple in design SIMD loops without special end part for processing remaining samples not possible to read/write with main loop using many SIMD datawords read-writes if single SIMD dataword is long enough.

Any increased row stride and alignment (by power of 2) is back compatible with old plugins (I hope). But too large stride and alignment will waste too much RAM with small frame sizes.

So other idea was to make user-configurable from script command row stride and alignment. But it must be supported by internal plugin design to get some benefit on fast hosts with AVX(all families) CPUs or modern CPUs. So plugin can check at plugin init the provided by AVS core row stride and alignment and can select better SIMD processing functions (processing larger data blocks if possible for single data burst exchange between register file and caches or host RAM).
There is no possibility of automatic alignment in Avisynth.
There is no record for different processors. And it is not only about the alignment value in the malloc function.
This value in avisynth is constant and is 64. In other functions it is converted to 64. For AVX2/AVX it is 32. So old processors do not have to work.

Example plugins RIFE:
#if NCNN_AVX512
#define NCNN_MALLOC_ALIGN 64
#elif NCNN_AVX
#define NCNN_MALLOC_ALIGN 32
#else
#define NCNN_MALLOC_ALIGN 16
#endif

static NCNN_FORCEINLINE void* fastMalloc(size_t size)
{
#if _MSC_VER
return _aligned_malloc(size, NCNN_MALLOC_ALIGN);
#elif (defined(__unix__) || defined(__APPLE__)) && _POSIX_C_SOURCE >= 200112L || (__ANDROID__ && __ANDROID_API__ >= 17)
void* ptr = 0;
if (posix_memalign(&ptr, NCNN_MALLOC_ALIGN, size + NCNN_MALLOC_OVERREAD))
ptr = 0;
return ptr;
#elif __ANDROID__ && __ANDROID_API__ < 17
return memalign(NCNN_MALLOC_ALIGN, size + NCNN_MALLOC_OVERREAD);
#else
unsigned char* udata = (unsigned char*)malloc(size + sizeof(void*) + NCNN_MALLOC_ALIGN + NCNN_MALLOC_OVERREAD);
if (!udata)
return 0;
unsigned char** adata = alignPtr((unsigned char**)udata + 1, NCNN_MALLOC_ALIGN);
adata[-1] = udata;
return adata;
#endif
}

DTL

25th February 2025, 20:39

None of the 3 icx variants work for me, all programs crash.

It may be some complex issue between VirtualDub + AVS core + Intel libraries and some other software.

If crash finally happen in VirtualDub module - we also need debug build of Virtual Dub with .pdb file for it.

May be some _version_ of additional loaded .dlls in 'used/updated Windows' is not compatible with current version of ICX compiler (its libraries) and it cause crash in returned value in VirtualDub.

Also the point of crash may be 'never fail before' so returned value do not checked (for being zeroed) inside VirtualDub and used as pointer and it crash at zero value. But this zero value may come from many other loaded third-party modules (not VirtualDub and not AVS core).

Here is debugger output of files loaded in 'normal' opening 'version' script with Base build (in working Win7 state/config)

'VirtualDub64.exe' (Win32): Loaded 'C:\distr\VirtualDub2_44282\VirtualDub64.exe'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ntdll.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\kernel32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\KernelBase.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\winmm.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvcrt.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\user32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\gdi32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\lpk.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\usp10.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvfw32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\advapi32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\sechost.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\rpcrt4.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\shell32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\shlwapi.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\winsxs\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.24380_none_e3731d0b30fb6b11\comctl32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\avifil32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ole32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msacm32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\comdlg32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\oleaut32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\imm32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msctf.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\cryptbase.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\distr\VirtualDub2_44282\plugins64\avlib-1.vdplugin'. Module was built without symbols.
'VirtualDub64.exe' (Win32): Loaded 'C:\distr\VirtualDub2_44282\plugins64\scripted.vdplugin'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msimg32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\uxtheme.dll'.
The thread 0xec8 has exited with code 0 (0x0).
< - start opening AVS script here
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\clbcatq.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\AviSynth.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\imagehlp.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvcp140.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-runtime-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbase.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-core-timezone-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-core-file-l2-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-core-localization-l1-2-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-core-synch-l1-2-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-core-processthreads-l1-1-1.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-core-file-l1-2-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-heap-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-string-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-stdio-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-convert-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140_1.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-locale-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-filesystem-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-time-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-environment-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-math-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-utility-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ddraw.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\dciman32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\setupapi.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\cfgmgr32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\devobj.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\dwmapi.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\nvd3dumx.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\version.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\powrprof.dll'.
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\powrprof.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\nvd3dumx.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\version.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\ddraw.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\dwmapi.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\setupapi.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\devobj.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\dciman32.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\cfgmgr32.dll'

Most interesting critical .dlls after start loading .avs script are

'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\clbcatq.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\imagehlp.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvcp140.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbase.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140_1.dll'.

Will try to replace 'bad Win7' with 'working Win7' versions of these files (or at least compare for binary equality - it is better idea).

DTL

25th February 2025, 21:17

Emulgator

25th February 2025, 22:47

Ah, good find.
My first everyday testing system is (unfortunately) updated, this broke Dual iGPU/dGPU capability, but ICX builds worked, and it is indeed 14.42.34433.0
Repeating tests on my other stable-frozen W10 system soon, and Win7U64.

DTL

25th February 2025, 22:55

Emulgator

25th February 2025, 23:08

And we have a hit: AviSynth+64 r4198 ICX Base under Win7U64, i9-940XM
Universal AviSynthInstaller reports: Immediate AccessViolation in C:\Windows\system32\MSVCP140.dll
Versions are 14.34.31931 from 05.10.2022

On that same 2009 system AviSynth+64 r4198 XP+ runs ok. (only simple scripts tested for now).
...one hour to go for the second mid-2024-frozen Win10 system to become free for testing...

TR-9970X

26th February 2025, 01:24

Microsoft site also lists latest (for MSVC 2019 ?) https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

Latest Microsoft Visual C++ Redistributable Version
The latest version is 14.42.34433.0

Why don't you use these distro's ??

These update ALL of them (after a restart).

https://github.com/abbodi1406/vcredist/releases

Visual C++ 2022 Redistributable - 14.44.34823.2

Emulgator

26th February 2025, 02:17

Because it breaks other stuff, and is close to impossible to repair afterwards.

TR-9970X

26th February 2025, 02:23

Because it breaks other stuff, and is close to impossible to repair afterwards.

I'm running W11 24H2, and I've never had an issue, but then I don't use most of these apps that you guys like to play around with !

gispos

26th February 2025, 10:30

Found and fixed - as expected it is about issues with MSVCP runtime and Intel libs :

Critical files are
'C:\Windows\System32\msvcp140.dll'.
'C:\Windows\System32\vcruntime140.dll'.
'C:\Windows\System32\vcruntime140_1.dll'.

Working with ICX builds version is
https://i.postimg.cc/W1rS0qYK/image-2025-02-25-231419318.png
14.42.34433.0 (from 29 Oct 2024 ?)

Not working version (VirtualDub crash) is 14.26.28720.3 (from 20 Mar 2020 ?).

It looks users need to update 140 MSVC runtimes to version from 2024 ?

Non-compatible with ICX build .dlls for testing - https://drive.google.com/file/d/1riwNEOc-qvM7Mi3P_7CqOMsdWH3f86pY/view?usp=sharing
My goodness!
I had looked up on a site what the latest MSVC runtimes are. I skimmed briefly and read “All in One runtimes 2015 to 2022”.
Hm, I have that on my system.
Kind of my own fault, but I think it should have been changed by name and not just 2o15 to 2022.

Then my first thoughts weren't so wrong. I was probably just too lazy to take a closer look.

VirtualDub2_64
The Avisynth.dll is loaded and after the VCRUNTIME140_1.dll is loaded the error starts.
Is it possible that the VCRUNTIME140 is not compatible with the Intel runtimes? Or are there newer VC runtimes after all?
Note: Fehler = Error

Ereigniszeit Ereignisart Thread-ID Speicheradresse Dateinam
00:01:32.426 DLL laden 6264 00007ff9`a43c0000 C:\Windows\SYSTEM32\AviSynth.dll
00:01:32.427 DLL laden 6264 00007ff9`f0010000 C:\Windows\System32\imagehlp.dll
00:01:32.427 DLL laden 6264 00007ff9`ac020000 C:\Windows\SYSTEM32\MSVCP140.dll
00:01:32.428 DLL laden 6264 00007ff9`e2d80000 C:\Windows\SYSTEM32\VCRUNTIME140.dll
00:01:32.428 DLL laden 6264 00007ff9`e9d30000 C:\Windows\SYSTEM32\VCRUNTIME140_1.dll
00:01:32.429 Fehler 6264 00007ff9`ac033028 Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000
00:01:32.430 Fehler 6264 00007ff9`ee31b699 Fehlercode: 0xe06d7363, Parameter: , 0x19930520, 0x004fe740, 0x200905f0, 0x1fc70000
00:01:32.478 Fehler 6264 00007ff9`ac033028 Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000
00:01:32.478 Fehler 6264 00007ff9`ac033028 Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000
00:01:36.003 Thread beenden 7304 Austrittscode: 0xc0000005

Emulgator

26th February 2025, 11:40

...one hour to go for the second mid-2024-frozen Win10 system to become free for testing...

And to confirm gispos and DTL, we have a second hit:
AviSynth+64 r4198 ICX Base under that similar Win10P64, i9-11900K
Universal AviSynthInstaller reports: Immediate AccessViolation in C:\Windows\system32\MSVCP140.dll
Runtime versions are 14.36.32532 from 10.05.2023

I am very thankful for the XP-compatible builds and will be backing off from ultra-modern-but-incompatible compiler builds for now
(had only dived in for that educational reason anyway).
To me at least those marginal gains seem not worth the hassle of broken bridges, but I am still thankful to those who try.