![]() ![]()
#Topaz video enhance ai crash fullI believe this happens whenever it calls on my GPU, however if I set it to only use my CPU, I get the "blue screen of death" which isn't much better than the full blackout I get with the GPU. ![]() Basically, as soon as either program goes to build the preview, it crashes. #Topaz video enhance ai crash PcIn either Gigapixel AI or Sharpen AI, as soon as I open an image, my entire PC will crash to the point that the monitor loses a video feed and the reset button doesn't even work, only a HARD power off will fix it (PC power stays on, but everything else shuts down and the only way to recover is a hard power cycle). Really disappointed with that company at the moment to be honest, I thought they were better and now I am regretting buying their AI suite.Īnyway, I'll do my best to keep this brief: #Topaz video enhance ai crash 32 bitWhat 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.Topaz support has been ignoring me for 2 weeks now so I am hoping maybe someone else has found a solution. \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: 104) 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. #Topaz video enhance ai crash 64 BitI 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 |