Well, basically Rhino keeps crashing on me with no warning, and every time I get an error message saying: “The NVIDIA OpenGL driver lost connection with the display driver due to exceeding the Windows Time-Out limit and is unable to continue.” Any idea why?
I am having similar video card issues… AFTER I just got a very pricey PNY / nVidia Quadro card and downloaded the latest drivers.
I spoke with PNY tech support and they suggested trying older drivers… which was a first! I tried two before I ran out of tweaking time,
As a temporary work-around, (like you have a deadline and need to do work!) you can ‘turn off’ the video card’s 3D acceleration under Tools --> Options --> Rhino Options --> View --> OpenGL & de-select ‘Use accelerated hardware modes’
The viewports look a little different, but but for smaller files, I was able to work at the same speed.
The same thing happened to me today. First time ever. Not a nice experience. I’m on a very modest GTX-470 with 310.90 driver. At the moment of crash I had two Rhino instances open and a couple of other programs. Now I installed newer 320.49 driver. Will see what happens next.
I thought about doing this, but from what I’ve read on the McNeel Wiki, turning off accelerated modes essentially negates the benefits of having a powerful (and expensive) video card. I’m using a PNY/nVidia Quadro 4000. There has got to be a better solution.
I have the exact same card: PNY Quadro K4000 and I sure would like to use it. Unfortunately, I have a conflict with one of my plug-ins (appears to be V-Ray, but no one can tell for sure yet) and I have burned about two days worth of testing. I am working on a better solution with the tech guys at both V-Ray and PNY, but no one has a fix yet.
As I mentioned, I only turned the cards acceleration off as a temporary work-around while I get my projects done. Feel free to report back if you find a solution…
Hi Bill and Dave,
Thanks for the post about this. I haven’t seen this here but I’m trying to find some common threads with your set ups aside from the card model. Can you let me know if this only happens with multiple instances of Rhino open? If so, are these separate Rhino sessions using certain display modes like Technical or Rendered and are the display modes customized? Can you also please let me know your OS. I have found that Win 8 with the Metro UI features can conflict with some GPU drivers and configurations. This might be involved.
I’ve also asked our developers to take a look asap at this topic.
My month-long problem was solved today! It appears that I had a corrupted USB V-Ray dongle. I installed another dongle / license and the memory leak is gone.
Separately, we also had occasional crashes with errors that pointed to the video card / OpenGL. It was fairly random, but it didn’t happen often enough to be sure of the cause. I read a post that suggested a tip which appears to have worked: “Quadros behave better if the nVidia control panel > Global setting page is set to use 'Workstation App- Dynamic Streaming”
Previous to this fix, the random crashes happened either when working or when quitting Rhino. So far (one full day after the fix above) we have not had a crash. Feel free to email me directly for me info, dave-AT-schultzeworks.com
I am still experiencing the same problem, which is very frustrating. The crash has been occurring with only one instance of Rhino open, though I often has Grasshopper open as well, and I am using two displays. I have only used the standard display modes, mostly Shaded, and the global settings page on the nVidia control panel is set to Workstation App - Dynamic Streaming". I am operating on Windows 7. What should I do?
Driver crashes has occurred on my systems for a few years. With Geforce and Quadro. They usually occur if I run different software at the same time and run out of graphiccard memory. It has happened with SolidWorks, Rhino, Photoshop and Cinema4D.
I think one of the problems is that too many applications are “designed” to run alone on a system, thus they are not designed to adjust the GPU memory usage on the fly if another application is launched. But I might be wrong. This at least makes sense to me, as the driver crashes has occurred in a variety of scenarios. But this has been over time, and never often
This might be caused by a loose connection between hardware. I’d check to make sure the monitors are connected securely and that the GPU itself is seated on the motherboard properly. It could also be a bad PCI slot… if there are multiple slots on the mobo, try another one as a test too if all connections look good.
Also, what driver are you using? I don’t see it in your other comments here. Can you post a screen shot of Options>Rhino Options>View>OpenGL?
I’ve got a Quadro 4000 here. Recently I had the same random crashes with the nVidia driver yet it had previously performed flawlessly. It drove me crazy updating drivers and fiddling with settings until I discovered the culprit. A tissue paper blocking one of the main ventilation fan inlets. Removing that and a good blow out and vacuum of all the cooling fans brought my machine back to its reliable self.
Thank you for your advice. I checked all of my connections, and even tried plugging the GPU into another PCI slot, but I have still experienced crashes. Here is an image with my driver information, as well as some screen captures of the error messages.
Thanks for the screen shots. I’m still not sure why you are losing connection with the display driver. The next thing I’d ask is does this happen if only one display is connected to the GPU? If so, does it happen if you load protect any plugins that don’t ship with Rhino? I see you also have Vray installed and there was a previous report of that being involved from Dave.
I’m not sure why your Anti-Aliasing setting is also blank in Rhino’s options even though accelerated hardware is active. Do you have any options in this drop down list? Maybe you have customized the Nvidia control panel in a way that is only allowing Rhino to do certain things but not others. Have you tried default settings for Rhino or all together removed it from the list of special Nvidia per application settings in the Nvidia control panel?
I’ll also ask our lead OpenGL developer to look over this thread once he’s back from vacation.
Well in my case after updating new driver, half an hour later my video crashed again only this time for good. Rhino wasn’t even open at that time. Basically 3 year old GTX 470 went kaputnik. There was also some damage to mother board socket. Not sure why it happened. A few months back I had low power supply problem with too many devices plugged into one outlet. That was rectified but I suspect some residual damage might have persisted eventually causing video card demise. It was definitely using a lot of power for the past few days before crashing as I could hear fans running harder than usual. Now after installing new GTX-640 my machine again is whisper quiet. I’m using Windows 7.
The same thing has just happened to me.
64 Bit Rhino ( Version 5 SR5 (5.5.30717.16015, 17/07/2013)) on Win7 x64
Different NVIDIA card, looks like the same drivers.
Two screens. 12GB memory total.
Same NVIDIA crash, with Rhino crashing and sending info to Microsoft.
Same thing; crashes within minutes of opening 64 bit rhino 5, also using grasshopper, started when updating to new NVIDIA driver, have tried several different ones now but still crashing. Quadro 600 and an M2090 on Asus motherboard. Ran flawlessly up to this point. Not sure what is going on.
Can you not use the windows restoration point prior to update?
It is with drivers as with everything else: don’t fix it if it ain’t broken
Installing cuda took me to the development driver. I reinstalled the
windows updated driver and it seems to work again now, but I tried going
back to many earlier drivers before doing this and they all had the same
behavior. It might be the quadro 600 card. Thanks.
Actually it started happening again. Apparently there is a windows fix for it; something to do with windows rebooting the driver if the card takes too long to complete any task. There is an automated windows “click to fix” for it which increases the time allowed before rebooting the driver. I have applied it so will see how it goes.
That’s interesting. Thanks for posting that.