Surfaces showing as "Custom" rather than their names, rendering white

Hello -
Recently, I began having a rash of spontaneous and unexplained render crashes after having run the most recent version of DAZ for some time with relatively few issues. As a hopeful fix, I installed the latest version again, but when trying to render, I noticed that all of my non-standard surfaces, such as ubersurface 2, AoA, etc., show in the Surfaces panel as "Custom", as opposed to their proper names. Furthermore, in the properties of the Surfaces Editor, when I select an item, only the Default UV, Smooth, Angle, Diffuse, Normal, and Opacity Strength show up. Further, area and test renders show as white, even though the scenes load normally in the workspace. Basically, I'm totally unable to edit my custom surfaces, or produce a render.
This is a first, and more than strange. If the only solution is to rebuild all of my characters from scratch, it will be the call for me to leave this medium, sadly, as I seem to be doing more troubleshooting than art these days. I'm hoping someone has a better option.
Thanks...
Comments
Update:
Part of the issue with the shaders/textures might have been a bad re-installation. I reinstalled the 64-bit again, and the Surfaces panel seems normal. But I noticed that there is also a 32-bit version of DAZ on this machine for some reason. Should I uninstall it, or just leave it?
The 32 bit version won't help, and has the LipSync plug-in which isn't in the 64 bit version so if you want that it may be worth keeping for occasional use. The shader code is usually in the default Lights and Shaders package.
You can have both 32 and 64 bits version installed on the same machine without problem. It will be useful if you want to use LipSync, which is 32 bits only.
There might also be a few other plugins which use the 32 bits version, from memory the Photoshop Bridge works from 32 bits DS if you have a 32 bits Photoshop, for example.
Okay, guys, thank you on the 32-bit question.
As to the other issues, I just ran a test render of the scene that made me aware of the problems. It rendered successfully, but also in literally half the time as it had taken before. So I'm left wondering if, over time and from robust use, DAZ might become corrupted (prior failures and other burps? junk files?) and want a periodic (every few months?) uninstall (of just DAZ) and re-install.
Fingers crossed, I'm back in business...
Also, what is best practice when updating DAZ? Should one just go to the product page and install just DAZ, or the whole package, including attendant files? And should one uninstall DAZ first? The latter may have been what fixed my issues. My render times have been cut in half.
You don't need to update the content, unless there's a note to say it has been updated. it's generally a good idea to use the updates for plug-ins (which are generally small files in any event).
Thanks for your reply. The uninstall/reinstall does seem to have solved the issue, so I'll remember that in the future. I suppose that DAZ accumulates some deleterious junk over time. Can't think of any other reason why my render times (of the formerly problematic scenes) have been slashed by essentially 50 percent.
Had a couple of crashes since my last post, but they were all with a particular file that was the sixth in a series, all built sequentially from one first file. So I tried taking the fourth file, randomly, and rebuilt scene 6 from it. No crash. So this begs the question of whether one file in a sequence can become corrupted if you "save as" and re-pose/rearrange "too many times", thus causing errors ad crashes. Doesn't seem like too much of a stretch. Anyone?
I doubt reposing things would corrupt a file, but of course if there was a problem at some point it wouldn't go away (and wouldn't necessarily recur on rebuilding the scene). It may be worth opening a support ticket with the bad file attached 9and a note of the content used) in case you've uncovered a bug.
Sadly, I over-wrote the file with the newly constructed one which rendered fine. I do recall, in the troublesome file, having added a linear point light to the Uberenvironment set I had been using, and thereafter, the problem appeared. I removed that light, but the crashes persisted. So I wonder if adding that light (even after I removed it) set off some unrecoverable scenario deep in that file somewhere.