Page MenuHome

Blender 2.8 Eevee randomly closing during render: EXCEPTION_ACCESS_VIOLATION
Needs Developer to Reproduce, NormalPublicBUG


System Information
Operating system: Windows-10-10.0.17134 64 Bits
Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 419.35

Blender Version
Broken: version: 2.80 (sub 48), branch: master, commit date: 2019-03-13 19:14, hash: rBbbc3ee09e44b
Worked: (optional)

Description of error
Now this is an issue I seem to have for quite some time now with 2.8.

When I render something with Eevee, Blender 2.8 will randomly close after a couple of frames and sometimes after a couple of hundreds of frames.
It does not crash on startup, it does not crash randomly while just using blender and the viewport, just at rendering.

This is what the console spits out last.
Address: 0x0000000052982D80 (this one seems to change)
Module: C:\Windows\System32\DriverStore}FileRepository\nv_dispi.inf_amd64_7a8e74171e1b8492\nvoglv64.dll

As I said this issue has been happening for quite some time, which in turn means this is likely not related to the latest build.
I did however test it and it happens in the latest build as seen above.
What this also means is that this error happened over the past driver versions. 419.35 is the latest from nVidia and this has happened on past versions as well.
Driver was updated not so long ago, I think 2 weeks ago.
Edit: A full reinstall with DDU was also done.
And since I also recently got a new GPU, this happened on my former GTX 750 Ti and my current GTX 1080.

I also tried a couple of things, like running with -d or --debug-gpu, the latter actually gave it more time before it crashed which brings me to a few observations.
Main observation is that the duration it renders, while still being somewhat random, depends on what else is showing in the Blender interface.
I get the faster crashes when I have a 3d viewport open and the image editor, I get the most render time before it crashes if I replace those two with just text editor for example.
Changing those windows while its rendering often causes a crash on changing them.
That said, even after changing those two to text editors it still caused the crashed after some time.
Another observation is that the crash also likes to mess with running YouTube videos, where YT just stops playing them and goes into endless loading.

The issue happens in pretty much every scene, so providing a blend file seems not needed.
Steps to "recreate" would simply make any scene, cube + camera for example and render as animation with Eevee.
Although I think it might be system specific and thus not easily reproducible.

Event Timeline

Sebastian Parborg (zeddb) lowered the priority of this task from 90 to 30.Mar 14 2019, 11:03 AM

Does this happen with cycles or just eevee?

I can confirm that this also happens in Blender 2.8 with Cycles.
2.79 seems stable with GPU rendering from a test I'm currently running which already went through 800 frames in the past 8:30min.

can you run blender_debug_gpu.cmd in the blender folder, reproduce the issue and attach the files it produces?

Florian (Mitsuma) added a comment.EditedMar 14 2019, 4:51 PM

Here is the Log with Cycles in 2.8.
Quite big because it did render a bunch.

Here is the Eeevee one.
This one actually crashed right as it started (after skipping last rendered frame)

Forgot you might also want the system info file so here is from the last one with eevee:

Florian (Mitsuma) added a comment.EditedMar 15 2019, 1:21 AM

Do you get crashes if you render without gui (the -b flag)?

It did render fine with console only using eevee in a first test, which was the rest of my original scene. (~12k frames)
I always forget how much faster that is, even on windows. (Save time and render time were a lot quicker.

Kinda lines up with my observation that playing with the UI while rendering can cause a quicker crash.

Does it crash with GUI if you force software rendering?
Download this dll and copying it so its located in the same directory as 'blender.exe' and run Blender normally.

It will be slower but I just want to check if it crashes the same way.

Can confirm that the GUI was slower, like the camera was slower.
The rendering times per frame seemed to be on par with before though in Eevee.

It crashed after 30 frames in my first test.

Just to provide additional info, I made a quick recording of a test, this is still with the .dll file inside, which is why its a bit slow.

Does it crash if you use the default settings? You seem to run with some non standard things.

I already reset the usersettings (basically deleting the 2.80 folder in appdata, besides the two addons), in terms of non-standard things there would only be Animation Nodes addon and my small little render button addon.
I did once test removing the my own addon and nothing changed.
Don't think that can cause anything but I will admit its a hack copy/paste job from 2.79 over to 2.80 and I have little clue about python really.

I will however do a test with all removed and all settings reset again.
Not sure if any of those two addons could actually cause this issue, although I know this might not be the place for support regarding those addons, well one being my hackjob.

Okay, I think we can eliminate those two addons.

I fully deleted the AppData\Roaming\Blender Foundation\Blender\2.80 folder to reset all user settings, addons and startup file.
On startup I did not let it load 2.79 settings.
I just hit save settings how it is by default on the first screen.
Made a new test scene:

Very simple one, just a sky background, 1 sample, enabled Ambient Occlusion and set a render output.
I split the main view to open a image editor window.
Everything else should be default from the default scene.

And then I just let it render the animation, crash after 1388 frames here.

Sebastian Parborg (zeddb) raised the priority of this task from 30 to 90.Mar 15 2019, 11:40 AM

In case the debug logs are useful again, those are from running the blender_debug_gpu.cmd again but with the complete reset Blender and the test scene from the last comment.
Seems like it doesn't even show the error, in some of the crashes I recorded the error also did not show up at the end, not sure if it just crashes faster then it can log, or how that works.

I would like to confirm that I am getting regular random crashes when using CTRL-F12 to render my animation. I can play the animation, fine in the viewport.

Using today's build, 06/10/19

When I screen captured the log, I was able to review the screen capture and pull out the last displayed message, an ACCESS_ERROR_VIOLATION Address: 0x000000013FB79AFF

NOTE: I get the crash with denoising both on and off.
Sebastian Parborg (zeddb) lowered the priority of this task from 90 to 80.Jun 11 2019, 10:00 AM

I've been getting green flicker with latest NVidia drivers and then also this same crash will occur.

Address : 0x0000000064E9957A
Module  : C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_fd332b7c7ad5fe7e\nvoglv64.dll

GeForce RTX 2080 Ti Driver: aka 436.02 Date: 2019-08-16

I get the same error in Cycles in 2.8 when having multiple 3D views open at the same time. If I keep open just one view open it doesn't crash. Also running it GUI-less, it doesn't crash.

I'm running a Ryzen 5 2600 and GTX 1060 3Gb

Richard Antalik (ISS) changed the task status from Needs Developer to Reproduce to Needs Information from User.Jan 6 2020, 11:57 AM

@Florian (Mitsuma) is this still an issue with latest build?

Campbell Barton (campbellbarton) changed the subtype of this task from "Report" to "Bug".Jan 13 2020, 9:58 AM
Campbell Barton (campbellbarton) changed the subtype of this task from "Bug" to "Report".Jan 14 2020, 8:10 AM

Misunderstanding on new policy, set back to report.

I also have this, using 2.81a and 2.82b, on cycles. Happens with GPU rendering, CPU rendering, combined, and with CUDA disabled.

I've switched to rendering in headless mode. Without the GUI, it works great and I never get this error.

Richard Antalik (ISS) changed the task status from Needs Information from User to Needs Developer to Reproduce.Jan 22 2020, 12:25 PM

Hi all,
it sounds to me like the common problem with heavy GPU computation under Windows.
There is a windows feature called Timeout Detection and Recovery (TDR) which complete resets the GPU after 2sec of freezing (GPU is unresponsive)!
SubstancePainter had the same problems and they wrote a nice tutorial on how to change the "TdrDelay" in the windows registry.

Hope that fixes your problems. ;)

Ahh, i forgot... it surely applies to cycles rendering too!

It's documented in the Cycles manual:

But, generally when TDR happens Blender should not crash with EXCEPTION_ACCESS_VIOLATION, just abort rendering. And I believe that if TDR happens, Windows will show a popup saying that the driver timed out.

I'm running Win7 64bit and had this problem with MeshRoom. There was no popup with the 'driver time out' mentioned, just a message saying 'MeshRoom stopped working'. Maybe it's different on Win10 or it's related to the MeshRoom architecture,

I looked at the cycles documentation and it feels somewhat 'hidden' to the technicaly unexperienced user.
I can imagine that the linked Microsoft document can throw off some/many users.

Maybe a FAQ entry with a link to a better description on how to fix that would be better?
Something like 'Blender crashes randomly, what could i do?'

The SubstancePainter team did a great Job on describing the problem and providing a step by step tutorial on how to change the registry:

Just my 2cents

Hi I have downloaded and installed Blender 4.1 but it will shut down automatically until I open it Thanks for helping me

Hi I have downloaded and installed Blender 4.1 but it will shut down automatically until I open it Thanks for helping me

Please make new report if you have unrealated problem to this topic.
Please follow all instructions there mainly please check if bug is already reported. If it is, you can just subscribe to that report and wait until it is resloved.

No This is a new problem

I don't think it's the TdrDelay thing. I have already modified my registry for Redshift on this matter. It's definitely a Blender bug.

Bastien Montagne (mont29) changed the subtype of this task from "Report" to "Bug".Thu, Oct 15, 3:59 PM