video card Crash when using viewport preview rendering and GPU

I have a Nvidia 550ti GPU with only 1 gb of memory. Something that occurs is random crashing of my GPU when using viewport preview rendering. When it occurs, I get a crash message from nvidia… not blender, but blender crashes at the same time.

What has me scratching my head… is if I do a normal render (f12)of the exact scene using GPU it has no problems rendering with GPU.

This has been an ongoing problem with past versions of Blender as well. I’m definitely going to go upgrade my drivers for my GPU as they are out of date. But I’m pretty sure this has occured when I have the current versions of the drivers.

edit… I should mention that his is happening using official versions.

I was just wondering if this is something that occurs to others, or if it is more likely a local problem?

EDIT… These are the error message that comes up as well as the council window


I get this from time to time as well. To add to it, when it happens on my machine I tend to get one card of my three that will only render at about 1/5 speed (400 compared to 1300) until I restart. I have yet to find a solution and I know it is not memory overrun because the scene I can remember it happening the most with is one of the Cornell box benchmark files floating around.

This is a Windows problem, the OS think driver is crashed and shut down application.
You can change TdrDelay in the registry.

Cheers, mib

Hey Mib… I appreciate the link, but if possible I would like a little clarification before I start messing around with registry keys (that always makes me nervous)

  1. just to clarify… were you giving advice on my specific issue or the addtional problem that anthony mentioned?

  2. What value should this be set to? It says the default is 2 sec for TdrDELAY?

  3. Will this need to be changed each time I upgrade graphic card drivers?

You can use the following TDR-related registry keys for testing or debugging purposes only. That is, they should not be manipulated by any applications outside targeted testing or debugging.

This was mentioned at the beginning of the article you posted. I really don’t understand what it means. I’m assuming if I make this change, it will permanently stay, but yet this article is saying it should only be used for testing or debugging.

Hopefully you or someone else knowlegable about this problem could answer the above questions.

Hi harleynut97, I reply to your problem.
You can easy change it to 20 seconds for example, Windows will wait 20 seconds without reaction of the driver to stop the application. The registry setting stays “forever”.
The only “problem” is, you cant differentiate whether Cycles really crash until this 20 seconds are over.
I know this problem mostly from Octane, now Octane set this key during installation to 15 seconds iirc.

Cheers, mib

I hate to bug you again mib… but take a look at this screen shot of when I’m in regedit
This first screen shot comes from the link you gave me… I was trying to find where to change
the setting (what directory) So I was following that key path


Below is a screen cap of with me in regedit… But below the graphic driver folder is a bunch of other folders and I’m not sure what folder I should be looking inside to make the change. I’m on windows 7 64 bit OS.


Inside this DCI folder… I do see something that says time out… but I have no idea if this is the correct place to make the change. If by chance it is… would I change the 7 that is in parenthesis to 20 and maybe also replace the 0x00000007 to 0x00000020?
This is what always makes me nervous about making registry changes :slight_smile:


Hi, you have to create the key in main folder GraphicsDrivers.
Create key type > REG_DWORD
Name > TdrDelay
Value > 20
I have no Windows anymore, this is from mind only. :slight_smile:

Cheers, mib

Yikes… creating my own key … sounds a little scary to a nontechnical person like myself. I’ll have to see if I can find some window 7 tutorials out there somewhere on how to do it… What I don’t know how to do is actually create the new key.

You mentioned that this new key needs to be inside the main graphics folder… these are the keys that are in there now.
I did also notice this UseNewKey folder… I’m not sure if this is where you create them possibly in window 7.

But I guess what surprises me most is I would have thought there would have already been a key set up with that default time the link article mentioned… I would have thought I would just change whatever the default value is with some new one… but your saying I need to create a whole new key.

If anyone has any links on where I can find specifics related to the window 7 OS and creating these registry keys let me know. Thanks again Mib for all your input on this thread.


Hi, look here:

https://devtalk.nvidia.com/default/topic/502643/cuda-programming-and-performance/win7-tdr-driver-timeout-detection-38-recovery-/post/3587100/#3587100

Cheers, mib

Harley I have the same thing in version 2.71 with a Nvidia GT 530. I’m not sure about 2.70, just don’t remember. However, no problem in version 2.69. I’m confused by how all of a sudden it’s a Windows problem when it doesn’t exist in other versions. And, like you I don’t need to be playing around in the registry.

My usual fix for this is dropping the tile sizes… pretty much what is happening is that the amount of time it takes for it to do one sample is longer hten the time it needs to report back to windows.

I believe that there have been some major fundamental changes with cycles over the past few versions which may cause your card to perform slower, which could be the reason for this.

(transparencys are usually the main culprit of long sampletimes… the other is hundreds/thousands of different meshes all ontop of the same spot)

@mib Thanks for the link… I went ahead and first made a backup of the graphicdrivers registry key. Then went ahead and created a new DWORD key INSIDE the graphicdrivers folder. The only strange thing that occured, is when the new key dialog box came up, I was able to input a value (I used 15), but it would not allow me to actually name the thing in that dialog box (it had some generic new key name in the name field, but it would not allow me to rename.) So I said OK to close the box, and then just selected this new key, right click, and renamed to TdrDelay and that allowed me to give the key the proper name. I restarted and luckily no BSODs or black screen… windows started normally (whew :slight_smile: )

But to any future readers of this thread… in NO way should you be taking what I said in this post as the right way to do it… this is your registry… and you can really screw things up with your computer messing around with registry keys.

OK with that said, I will need some time to really tell if this helps or not… this problem always seemed to be somewhat random, but it occured enough on my system that I will be able to tell over a short period of time.

Thanks again Mib for all your help.

@ghost For me Ghost, I’ve experienced this problem long before 2.69.

@doublebishop Thanks for the additional advice on reducing the tile size, it sure can’t hurt to try it… When using my GPU, I usually have the tile size at 256 x 256. And with normal F12 rendering these seem to work fine. But its when viewport rendering (gpu)where I was has having the crashes.

Just as a side note … on another forum, someone sent me MS this link

I didn’t try this, because I manually made a change in my registry of the TDR earlier today, but if you look in the Resolution section, you will see an option to let MS fix it utility automatically make the fix for the time delay issue… apparently doing the registry change thru the utility.

The only thing I could not determine regarding this utility fix, is what specific setting they change it to.

If you decide to check it out…always first create a restore point for a system restore, and I would back up your registry just to be on the safe side.

Have you tried switching from dynamic bvh to static bvh?, final rendering only ever uses static bvh… viewport uses dynamic unless set otherwise, which is a bit slower but gives better updating speed.

@doublebishop I have not tried switching to static BVH for the viewport, but I will definitely give it a try.