Crash EXCEPTION_ACCESS_VIOLATION (After time of use)

[Charlie-Ramirez-Animation-Studios-de-MX]

Description

This is the first time I have installed opentoonz on this particular computer. Throughout the project opentoonz tends to shut down unexpectedly due to access violations. There is no specific pattern to replicate but it usually occurs after a relatively long execution time (4+ hours). and/or commonly when manipulating vectors. The failure does not make it impossible to work since it occurs randomly and it is enough to close and reopen the program to recover normality for a time while it occurs again

-The project is entirely vector levels, the only raster layers are the background and some hidden reference images (all images imported into the project)

-Crash log attached

Steps to Reproduce

1. The first times they occurred when modifying bezier curves that delimited colors within already colored layers (However, I had activated it to experiment with the integration function with Windows Ink, after deactivating it, crashes stopped occurring as frequently).
2. It happened again this last time when trying to Preview the same vector animation already with effects and repeated to move over the scene

Apparently the backtrace references ntdll but I have not had problems in other programs or BSODs and there are no errors in the event viewer to suggest that it is a system failure but I am open to trying whatever is necessary

-Windows is updated to the latest available as of 2024-01-25 (KB5034204)

Expected Behavior

Technically opentoonz should not crash due to access violations when manipulating vectors.

The canvas is relatively large (it is an A4 size sheet with 600 dpi) although I don't think it is the cause of the problem.

Screenshots, Video & Crash Logs

Crash-20240125-031805.log

OpenToonz Version

1.7

OpenToonz Version Information

Backtrace: OpenToonz 1.7.1 (Build Mar 14 2023) About Opentoonz: Built May 10 2023 11:07:51

Operating System

Windows

GPU

AMD

Graphics Tablet

Wacom

[RodneyBaker]

Since you are primarily using vectors which are resolution independent I'll recommend you use the default DPI of 120.

Yes, you shouldn't need Windows Ink and you should turn all those option off both in Opentoonz and in Windows itself. If you use other programs that rely on Windows Ink you may need to investigate your options a little more.

In your screenshot I see a mention of WIndowsCodecs which suggests you might have an incompatible codec installed on your system but... I only mention this as codecs have been problematic for others in the past so I'm always on the lookout for that.

If you are dealing with lots of vectors... which apparently you are... there are many other things you can do to free up resources but that is all something that would have to be worked out based on your system and project.

Added: I don't see anything in your crash log that stands out although I do get the sense that you want to double check your antivirus to make sure it isn't being overly protective and halting Opentoonz during critical write to hardrive processes.

You mention that this crashing tends to occur after some time of usage. After saving and perhaps opening a temp scene to make sure nothing of your current project is still active... Go to File > Clear Cache Folder and remove the files stored in cache. This can keep Opentoonz from inadvertently referencing those cache files. Once cleared, close and restart Opentoonz to get a full clean restart. If you haven't restarted your computer system in a long time I'll recommend doing that as well.

[Charlie-Ramirez-Animation-Studios-de-MX]

Ok I have completed my project, I had to render it in parts (maybe the resolution was a little excessive), but during experimentation, I discovered a method to replicate the issue. I can consistently reproduce the problem when rendering with Google Chrome open in the background.

While I cannot provide a definitive answer, it seems to be related to a Chrome memory management issue. The occurrence is more frequent when the total RAM usage approaches 70-80% (in my case), but it also happens if Toonz memory exceeds 5 GB.

When trying to force the error with chrome in the background I was able to get a system error message indicating a memory reading error from the program. Interestingly, the HEX 0x00007FFF94113AE0 and 0x0000000000000008 in the system error remains consistent across all three occasions, even after a complete system restart and cache cleared (I don't use Windows quick start).

To eliminate the possibility of a hardware problem, I conducted multiple passes of Memtest86, which returned no errors, and the system continues to function normally. The issue doesn't appear to be related to antivirus software either. Despite using only Windows Defender, with protection disabled and Toonz in the exception list, the problem persists. (I also do not use Windows Core isolation)

As for codecs, I believe that's unlikely to be the cause, as I exclusively use standard codecs such as VLC and the ffmpeg folder shared with Audacity. However, considering the connection with Chrome, I'm exploring the possibility that one of the codecs used by YouTube could be a factor?.

I'm in the process of ruling out any association with AMD drivers or potential corruption in Windows 11 components. However, current observations suggest that the problem might be rooted in how Chrome or Windows manages memory in the background, conflicting with Toonz's attempt to use the same address simultaneously

probably offtopic but the logs detect windows 11 as Windows 10 2009. I am currently on Edition Windows 11 Pro Version 23H2 Installed on ‎2023-‎12-‎09 OS build 22631.3085 Experience Windows Feature Experience Pack 1000.22684.1000.0

[RodneyBaker]

Thanks for the information @Charlie-Ramirez-Animation-Studios-de-MX

I suppose one workaround for those encountering the problem would be to turn off Chromium browsers while in production. In general I personally would like to keep my browers on an entirely different system than the ones I use for production but so many useful tools these days are browser based that isn't entirely optimal.

It would be well worth the effort to consider why these programs might be inadvertently trying to use the same allocation of memory. Assuming that is in fact the case.