[BUG] Various bugs with latest dev build (2020.09.25-21270)

[The_Tinkerer]

I think the command line arguments might actually be the problem. (Maybe?)

I can run the 32 bit avsviewer.exe and it works as it should. But if I try to run it in x32dgb, the command line arguments don't pass, even though x32dbg's log reports that they did, and it produces a similar 0xc0000005 access violation error that avsviewer64.exe does when it's run normally.






When avsviewer.exe (32 bit) runs normally outside of a debugger, the command window looks like:




So why does the command window show that weird crap instead of the command line arguments in x32dbg? Why the 0xc0000005 access violation?



With avsviewer64.exe, I can't run it (0xc0000005 access violation crash), and the command window looks like:




It doesn't show "Importing E:\USER\viewer\test1.avs" like avsviewer (32 bit) does. But I know it's reading the .avs file because it produces errors if there are errors in the script (wrong file name, etc.). The command window + crash above is what happens when I think it gets to the point of trying to load the video file.

When I try to run avsviewer64.exe through x64dbg, it does NOT produce a 0xc0000005 access violation (which it does when it's run normally), but it DOES produce similar issues with passing the command line arguments through:






It stops without crashing and stays like that in that "Running" state. The command window seems to show there was some problem passing the command line arguments through and somehow only "\" got through. But x64dbg's log shows that the command line arguments were parsed (it turned \ into \\ for some reason), and the avsviewer64.exe gui even loaded and reports that it received the location of the avs script. Why would the GUI show the correct location of the avs script, but the command window show an error and tried to only import "\"? Why no longer a 0xc0000005 access violation crash? But it still doesn't load the video?

So to summarize: both the 32 and 64 bit viewers in the debuggers have a last entry of ole32 before the 32 bit one crashes with 0xc0000005, and the 64 bit one hangs. Outside of the debugger the 32 bit one runs normally, but the 64 bit one crashes with 0xc0000005.

I know debugging info is usually useless but I posted it on the off chance it might tell you something.

I guess I finally give up!

[The_Tinkerer]

I didn't give up.

I got it to work.

The problem, is with ucrtbase.dll.

I am using Hybrid in conjunction with Topaz Video Enhance AI. This is a machine learning based upscaling program.

I am pretty sure the 64 bit viewer was working for me without crashing earlier, as I mentioned.

I think the problem happened when I upgraded Topaz Video Enhance AI in mid September to version 1.6.0 then shortly afterwards to 1.6.1. I think that's what probably overwrote ucrtbase.dll in my c:\windows\system32 directory to a different version than what was there previously. (I can't be sure because Universal Extracter won't extract the installer for this program.)

The version that causes the crash is 10.0.14393.2990, dated 4/12/2019.

I downloaded version 10.0.18362.387, dated 5/3/2020, from here:

https://www.dll-files.com/ucrtbase.dll.html

I put it in C:\Program Files\Hybrid\64bit\Avisynth. (I left the one currently in C:\Windows\System32 alone).

Now avsviewer64.exe works.

That was excruciating.

If you feel like testing it out, here's the ucrtbase.dll file that I have that causes the crash:


  ucrtbase.zip (Size: 452,05 KB / Downloads: 217)

Put it in your ..\Hybrid\64bit\Avisynth directory and see if it now crashes on you. (Check with Dependency Walker 64 to insure that it's using ..\Hybrid\64bit\Avisynth\ucrtbase.dll and not C:\Windows\System32\ucrtbase.dll)

What is weird, is that I have the same version of ucrtbase.dll for 32 bit (C:\Windows\SysWOW64\ucrtbase.dll), and it does NOT cause the 32 bit avsviewer.exe to crash.

[Selur]

I copied the ucrtbase.dll into my I:\Hybrid\64bit\Avisynth folder, started Hybrid, switched "Filtering->Support" to "Avisynth", changed "Config->Internals->Avisynth->Avisynth type" to "64bit", loaded a source started the Avisynth Preview.
avsViewer64 was started without a problem, but it's still using the dll in the system32 folder.

What I found was, that the avsViewer64 build in Hybrid was build against another C++ runtime version.
-> build a current version and attached it with the dependencies.

Try whether that version works for you. (extract all the files in your "Hybrid\64bit\Avisynth"-folder)

Cu Selur

Ps.: btw. your avsViewer64bit command line call uses double backslash which it should not. If you are uncertain if you need to escape backslashes, try using slashes instead. (not sure about Win7 but Win10 does support using slashes instead of backslashes)

[The_Tinkerer]

Sorry it took so long for me to report back.

This works! (I made sure to remove the ucrtbase.dll in ..\Hybrid\64bit\Avisynth first! )

[Selur]

Nice, happy that worked out.

Cu Selur