New frequent video driver related crashes

Rhino was very stable on this computer until I loaded SR9 RC 2 or so, now it’s crashing quite frequently… even with SR9 final… I do have a Quadro running on Windows 8 but it was running fine until the last year until couple of SR RC’s… What got changed?


I know you know to think of this Mitch but are the recent display crashes you’re seeing with all files or one in particular?

Hi Brian,

I’m currently “editing” 150 individual student files, doing some minor adjustments, adding/correcting some materials, etc, then exporting them in a lightweight mesh form for a further process. I work on one file, export it, then drag and drop the next one into the window to open it (without saving the previous one). An hour ago it was crashing on virtually every second file or so, now I’ve had a run of maybe 8 without crashing… Just installed SR9 final this morning.

Hmm, 50 down, 100 still to go…


OK, this now started happening on a different computer, Windows 7 this time, Quadro 2000. Geez guys, what did you change to mess this up so badly? Got a presentation in an hour, this isn’t going to help…


So what makes this a video driver crash or related issue? I’m not seeing anything mentioned here. What happens when it crashes? There are probably no more than 2 changes to the display code for SR9, and I can’t think of any reason why they would be causing all of these crashes… If the drivers are indeed crashing, then all I can think of is that your drivers might have changed. Driver crashes aren’t really the fault of the host application, but I understand the perception.

More information about the crashes could help… Have you been sending in the crash dumps? (with your name on them)


I’m not seeing any crash dumps for this…however, if they are video driver crashes, then the automated system probably detects that and just fires off an “Update your video driver” email automatically.

If the dumps aren’t too big, try posting one here and I’ll take a look…but again, a crash in the video driver has very little chance of McNeel fixing it…but I’ll see what can be done.


I just received a Quadro K2000 from NVidia… Mitch, is that the card you’re having issues with on the Windows 7 machine?


Well, firstly, I get these messages from support…

Thank you for sending in the crash report. The information in the report indicates the crash was caused by the NVIDIA OpenGL video driver (nvoglv64). It also shows that you are running a “NVIDIA Quadro K2000M”.

Then my experience also tells me that when Rhino crashes randomly and non-repeatably on different commands or operations, that it’s pretty much always video-related. If I can repeat the crash, I always document it and send it in, but this isn’t the case.

I haven’t touched the drivers… Normally I would try to always keep relatively current drivers, but since we started getting all these warnings about the latest drivers not working with Quadros, I was hesitant do to so - especially as up until a few weeks ago, everything ran fine. The only thing that has changed are Rhino SR updates and Windows updates (video drivers not included).

I send in the error reports… There often isn’t a crash dump in these cases… When there is a file produced, I send it in…

The thing is, that a number of people have invested a lot of time and money in systems that should be reasonably high performance, many of them are running Windows 8/8.1 and have Quadro video cards. Now we are told that “For Windows 8 and 8.1, there is no stable driver we can recommend”

  • what are we supposed to do with that information? Go out and buy a new computer again? Reinstall the whole system with Windows 7? Stop using Rhino? None of those alternatives are acceptable.


Hi Jeff,

The Windows 7 machine (HP 8570w) has a K2000M (mobile) as it’s a laptop. I am running the “recommended” 320.92 drivers.

I have two other workstation machines, one with a Quadro 4000 running on Windows 8.0 - the other computer I recently reported problems with - and another with a Quadro K2000 (no “M”) on Win 8.1 which is my home machine. The last one hasn’t had any problems yet, but I haven’t been using it extensively with Rhino as of late…


I will be running some tests this week with the K2000 and 4800… Based on what you’re describing, I need to:

  1. load files by dragging and dropping them onto Rhino
  2. Make some modifications
  3. drag-n-drop another file, onto Rhino to “open”, but don’t save any of the changes.
  4. Continue doing #2 and #3 until things crash.

Does that sound about right?


Yep, that’s about what I’m doing, models in rendered mode with some materials applied… Worked OK this morning for about 10 files and now just crashed… --Mitch

After 10 crashes or so today running the “older” drivers, I installed the nVidia recommended “ODE” drivers (333.11) - basically because I reasoned that it can’t get any worse… Unfortunately it didn’t get better either, after 4-5 files it crashed as well… This is getting to be downright “annoying”… (being nice here)

And my laptop also crashed out once today as well - on the only file I used it with - using RhinoTerrain, but again, I suspect it’s not RT, as I was in the “visualize” phase of the mesh generation, almost certain that it’s video as well. Redoing the same procedure after the crash worked fine. This with Win 7 and the “recommended” 320.92 drivers… I got a RhinoCrashDump.dmp file, but not a .3dm file… No error reporting box… You want the file? That file is empty…


Did you get today’s batch? You should have a bunch…

No, but as I said, if the automated system sees anything having to do with a video driver, I probably won’t see it. If the dump file isn’t too big, just post it here so I can confirm that this is indeed crashing in the nvidia ogl driver.

I will start hammering on the two cards I have here in an attempt to reproduce this crash. Also, if you’re using SR9, then I’d like you to start trying to use the latest NVidia drivers and not the ones recommended on our site…for now.


I’m on SR9 all around. You want me to run the latest performance driver (334.95) or ODE driver (333.11)? I installed the ODE on my Win8.0 / Quadro 4000 machine this afternoon (the one that’s been crashing all day) and that didn’t seem to fix it.

Let me know if there’s anything else I can do to help…


When you install drivers, do you select “Custom” install, and then CHECK the option for a “Clean uninstall/install” ?


Just got 2 crash reports from you…and neither of them have anything to do with the video driver… Something is going bonkers in OpenNURBS when trying to delete and free up memory.

I’ll let you know more when I have more…


Hey Mitch,
We’re looking at these crashes and they appear to be related to .NET code crashing during garbage collection. It looks like the python plug-in is loaded in your Rhino process. Is there a python script that you are running while you are doing all of this drag and drop stuff? If so, I would really like to see that script since it would help us a ton in figuring out the true cause of the problem (it is probably something I need to fix in RhinoCommon.)

Hey Steve,

There are 3 scripts, they’re not running when I drag and drop obviously, but I run them once I have the file open… They’re on some temporary toolbar buttons. The first I only run if necessary to create some specific named layers in the file and with an option to import a “template” file with some materials stored in it. A second just groups objects on each of two layers. The third actually Meshes the objects with some presets, selects the meshes, exports them to a specific folder, and deletes the meshes again. That last one runs just before I drag and drop the next file into the window…

I’ll need to grab the whole package of stuff and send it to you tomorrow, as the latest versions are on my work computer and you’ll probably need some sample files to test on. Should I send it directly to your e-mail?

Thanks for looking into this, and apologies if I mistakenly charged the video driver with these “crimes”…


Sure, that works for me.

I think the problem is that our crash analyzer application got fooled in this case. The crash appears to be happening in the garbage collector on a background thread and I think the crash analyzer is looking at the main thread. We’ll need to tune this up once we figure out this is truly the case.