With SLT, I've had a similar problem, but not with the Blend tool. Mine would be when closing in on using 1GB of RAM, and concurrent to selecting a single point when zoomed in very, very closely. It would be random, and it caused me great stress for around a month. The machine has not been connected to any networks for months, and so I suspected possible video or resolution or just geometry issues. Possibly some excessive amounts of dependencies between parts and when selecting or moving certain points may have had a hand in the problem.
When it happend, I got a white screen, except for the coordinates bar, and the mouse was visible, but NO keys for the most part worked. No way to get out of the view sometimes. On one occasion, I lost over an hour of unsaved work, on another occasion more. Once, in great trepidation, I hit File, Save, and fortunately, the file did not save corrupted. But, on one occasoin, it seemed a file saved as corrupted, but I was able to open it by monkeying with the extension and then telling Shark to see it as a VCP file, if I recall correct.
Last night, a file I worked on involved translating a curve. The screen went white and I almost had a heart attack. It turned out, however, that SLT did not crash or corrupt my file. This at first appeared to be related to my main interface of Shark LT on an external display, but after experimenting, the screen-going-white reoccurred, but when dragging the geometry on my laptop's display, via a floating window of SLT. When that happened, only the coordinates appeared, and changed when the mouse moved. But, the icon in the upper left changed to something non-related to my most recent icon click. Fortunately, minimizing and resizing SLT made the white screen return to normal. But, as a safeguard, I backed out of tthe file, shut down SLT, and, IIRC, restarted windows.
Overall, it seems SLT and VCP gracefully did not destroy my files. If it has happened in the past, it is so rare that I cannot recall at this time of VCP or SLT trashing any of my files.
WRT excessive or very deep dependencies on parts or other geometry, I moved one curve, and even after setting Shark in high priority (via windows) and sleeping early, and letting SLT whirl away for 10 and around 25 minutes, nothing changed. I had to task kill it. But, fortunately, I had saved at a good point before moving that curve. So, no stress, but it did make me wish that it was easier to have user-set break/kill points. Example: If the same process of refreshing or moving is system intensive, then every two minutes, interrupt the activity and offer the user a chance to back out and if necessary KILL the app. I hit escape to cancel, and no joy. I hit the Task Manager, but it took upwards of a full minute just to respond with highlighting SLT on the task list. I was unable to immediately kill it, so I had to back out to a Linux console and kill VirtualBox to regain control of Win7. On other occasion, SLT proved very wrong MS's claim that Win7 will not be crashed by errant or troubled apps. I've had Win7 crash/bluescreen/abort VirtualBox when a drawing curve moved a millimeter sent SLT into a tizzy, and some process or thread tore right through to W7 and made it bring down VBox. On at least two occasions, it locked up my whole GUI and I had to kill Linux and reboot, too. So, I know first hand that an app in Win7 can cruel Win7, tear through VBox, trash the K server, and force reboot of Linux on my laptop. But, at the moment, it's pleasing anecdote, since I like seeing stuff that proves incorrect certain statements people sling around.
