Page MenuHome

Blender crashes when changing viewport shading to rendered
Closed, ArchivedPublic


System Information
Win 7 Professional 64-bit SP1, Nvidia GT 730 2GB, Nvidia Drivers 385.28, 385.41 and also on an older driver version 37x.y, Nvidia CUDA 9.0.163 and possibly older version relevant for the above nvidia drivers.

Blender Version
Broken: 2.79 Release Candidate 2 (2017-08-18 12:53, 7b397cd), 2.79 release (2017-09-11 10:43, 5bd8ac9), 2.79 nightly (2017-09-16 10:33, 6798a06)
Worked: none I tried

Short description of error
Blender crashes to desktop on the first path trace sample, after changing viewport shading to rendered.

Exact steps for others to reproduce the error
Occassionally blender crashes after chaging the viewport shading to rendered during the first path trace sample. The attached .blend file is an example of this. It's a somewhat complex scene, I'm sorry I was not able to construct a simple example showcase. Rendering via F12 oder the Render button works fine, the crashes only occur when switching the viewport shading. It first occurred on 2.79-rc2 with some 37x nvidia driver, but is still present after updating the driver twice. Today I updated to latest blender release 2.79 and after the bug's still there, I also tried the latest build (6798a06), with no success.
Usually the crash starts to occur after adding a glossy and mix shader to the default diffuse shader for the material of an object. Sometimes the crashing stops after changing some of the parameters on the mix and/or glossy shaders or adding some more nodes to the material or other objects to the scene. From a user's perspective the crashes occur somewhat random, although they seem to be attached to the glossy shader.



Event Timeline

deleted the .build file by accident.

Joshua Leung (aligorith) lowered the priority of this task from Needs Triage by Developer to Normal.
Sergey Sharybin (sergey) triaged this task as Needs Information from User priority.Sep 18 2017, 8:12 AM

This file is missing textures in it, so it might affect on reproducability of the bug. Besides that:

  • Does the crash only happen on GPU, or did you manage to get crash on CPU as well?
  • Does the crash happen for you every time you enter rendered viewport?
  • Try running blender from the terminal (cmd.exe) and attach all possible messages from there as a file here.
Bernd (waebbl) added a comment.EditedSep 18 2017, 6:47 PM

There's only one texture used that I'm aware of, the environment texture. I used one from the sIBL archive at and append it here, if it's what you're referring to.

Answering your second question, depends how you mean it. It doesn't crash every time I switch viewport in all cases. But once it crashes on a file, it will crash every time I switch viewport, as long as some changes, as described above, will stop it from happening.

As for your other questions, I haven't tried using CPU, only GPU so far, I will check this out and come back then.

I figured out how to pack all files into the .blend file. So please try the attached file.

Here's the output when starting it from the terminal:

D:\Blender Foundation\Blender>blender.exe
Read prefs: C:\Users\waebbl\AppData\Roaming\Blender Foundation\Blender\2.79\conf
found bundled python: D:\Blender Foundation\Blender\2.79\python
path not found
path not found
Read blend: D:\Data\Blender\tower\tower_packed.blend
path not found
CUDA error: Unknown error in cuCtxSynchronize(), line 1835

Refer to the Cycles GPU rendering documentation for possible solutions:

D:\Blender Foundation\Blender>

I tried reducing the tile size all the way down to x:8, y:8 as mentioned in the manual, but it doesn't help. Changing to CPU rendering does not crash blender, so this only happens with GPU rendering.

Bernd (waebbl) added a comment.EditedSep 19 2017, 8:15 PM

I just booted up my linux box, downloaded the current stable release and tried the tower_packed.blend file. Here it doesn't crash when I switch viewport, but I haven't updated nvidia-drivers yet, using 378.13 here. Also CUDA is version 8.0.61 toolkit and sdk packages, which is the latest for my distro.
Haven't used linux for some time. I'm running gentoo, there's no relevant output on the terminal.
I'm off until sunday, when I'm back, I'll go and update the nvidia driver and report back on the behaviour.
If you have any questions or suggestions, feel free to ask.

After updating nvidia-drivers to 384.59-r1, which is the current latest stable release, viewport switching to rendered mode is also working.

Bernd (waebbl) added a comment.EditedOct 5 2017, 9:06 PM

@Vuk Sorry I answered by email accidentally.
I didn't notice there's been an update available for windows nvidia driver. I was running it on linux since the report, because it works there. I'll check the new driver and then come back.

Using the 385.69 driver the problem's still there in windows. The output from the console says
CUDA error: Unknown error in cuCtxSynchronize(), line 1835

Refer to the Cycles GPU rendering documentation for possible solutions:

Is it still an issue with latest builds from There was some work related on how CUDA devices are used.

I tried the latest official release from (#cc96cdd from Oct 24) and also updated to latest nvidia drivers 388.0, but it's still an issue.

If it helps, I can provide a mini dump and related WERReport data, which windows wanted to send home, from the last crash.

Also please note, that I'm completely switched back to using linux and won't use windows actively for the time being, so I don't care a lot about this bug. You're welcome to close it, if the issue is too special or for whatever reason. But if you want to dig further into it, I'm also happy to help you in any way I can and try changes out whenever you say. Just let me know. If I can be of any further assistance, please let me know.

Thanks for your help.

Bastien Montagne (mont29) raised the priority of this task from Needs Information from User to Normal.Oct 31 2017, 4:13 PM

Can not reproduce the issue, on nether latest master build nor 2.79 release.

@Brecht Van Lommel (brecht), could be same roots as T52572? Mind having a test here?

Probably the same as T52572 indeed.