![]() ![]() \Hybrid\64bit\Avisynth\ucrtbase.dll and not C:\Windows\System32\ucrtbase.dll) (Check with Dependency Walker 64 to insure that it's using. \Hybrid\64bit\Avisynth directory and see if it now crashes on you. Ucrtbase.zip (Size: 452,05 KB / Downloads: 112) If you feel like testing it out, here's the ucrtbase.dll file that I have that causes the crash: (I left the one currently in C:\Windows\System32 alone). I put it in C:\Program Files\Hybrid\64bit\Avisynth. I downloaded version 2.387, dated, from here: The version that causes the crash is 3.2990, dated. (I can't be sure because Universal Extracter won't extract the installer for this program.) 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 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 am pretty sure the 64 bit viewer was working for me without crashing earlier, as I mentioned. This is a machine learning based upscaling program. I am using Hybrid in conjunction with Topaz Video Enhance AI. I know debugging info is usually useless but I posted it on the off chance it might tell you something. Outside of the debugger the 32 bit one runs normally, but the 64 bit one crashes with 0xc0000005. 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. 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? But 圆4dbg'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. The command window seems to show there was some problem passing the command line arguments through and somehow only "\" got through. It stops without crashing and stays like that in that "Running" state. When I try to run avsviewer64.exe through 圆4dbg, 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: ![]() The command window crash above is what happens when I think it gets to the point of trying to load the video file. avs file because it produces errors if there are errors in the script (wrong file name, etc.). ![]() It doesn't show "Importing E:\USER\viewer\test1.avs" like avsviewer (32 bit) does. With avsviewer64.exe, I can't run it (0xc0000005 access violation crash), and 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? When avsviewer.exe (32 bit) runs normally outside of a debugger, the command window looks like: 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. I can run the 32 bit avsviewer.exe and it works as it should. I think the command line arguments might actually be the problem. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |