Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.Daz 3D is part of
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Yes, you are correct. My apologies; I haven't used any BSD much recently. I was referring to a coding error in the CMS, but the same file produces the same apparently false report in 4.15.0.4 so it's not new. The dForce problem also repros in 4.15.0.4, fortunately the file save problem hasn't yet.
Indeed I don't log in to DAZ Connect; I only log in via DIM. The information in question was the full file name of the scene I loaded and it appears there even though I'm not logged-in to DAZ Connect ("Smart Content" tab, top right always shows the blue "Login..." button). It arises bcause DAZ Connect seems to be querying the CMS to see if the scene file is a downloaded/purchase scene without checking the logged-in state:
"scenes" is in "My Library", so it is in one of the CMS managed directories and the original log file contained not just the file name but the full path name, revealing the structure of my disk. However on examination I think it is clear that DAZ Studio is not transmitting this information and it only gets into the log file because the database connection fails and the full query that fails is logged as a consequence. It's still unfortunate that the above stuff appears in a file, "cloudLog.txt" which ends up embedded in the bug report zip. The errorlog.xml file does seem to have been anonymized and the crashdump.dmp file does not record the heap, according to Visual Studio.
BTW the above special container originally contained the full log with just the file/path names editted out. I got a "you've been blocked" security page from daz.com - apparently it doesn't like PostgreSQL queries in comments!
No need to apologize, while the default is case insensitive, there are people who format their partitions to be case sensitive, so it's not unheard of. I just naturally assume that I've misunderstood something (which seems to be becoming more the norm these days than I'd prefer).
-- Walt
Checked the changelog and didn't see any fixes directly related to morphs and saved scenes. So never tried 0.26. Will wait or until others say all good again.
@icecreamdude never bought or updated to 8.1. so even my DIM shows newer G8 base, F, M updates as unloaded. Prefer less potential conflicts. So no G8.1 morphs or 2nd folders. So unless back mechanics for morphs changed from working 0.14 to non-working DS 0.25 requiring now G8.1 even if not used?
I've been messing around with .025 a little here and there last night.. haven't gotten to really take the time and try a heavy scene, but so far - I've got to say I'm quite impressed with Daz running on the M1 Macbook Air. Decently quick loading of figures, fluid viewport/OpenGL, Iray preview renders decently quick and no issues loading/saving. Also I installed DazToBlender and the Diffemorphic Blender scripts, all of those worked just fine (again haven't tested extensively). I'm kinda afraid to upgrade to .026 though - I've been waiting TOO long to have a funtional DaZ.
I think it was the 0.24, and yes, I have the latest version of the drivers
Folks, would anyone be so kind as to remind me what's the best thing to do with crash reports? Does the dev team even need them?
Yes. They should be submitted with the bug reports.
Restore from backup, you do keep backups?
If you have Windows File History turned on you may be able to find the old download there (if file history is recording the downloads directory):
However WFH is extremely unreliable in my experience - notice that there is no entry from this month even though I downloaded 14.0.1.25 and 14.0.1.26. It may also be necessary to have the .dsx file as well as the .zip; I always restore both so I don't know. (The .dsx reflects the version on the DAZ server, but I think it is still possible to install even if the server version is newer.)
Try turning off Daz Connect by not logging in when DAZ Studio prompts at the start or turning the auto-login off in the Studio settings. Of course if you already have it turned off that would be very interesting! Here is the relevant part of the crash:
If you aren't logging in to DAZ Connect that might immediately explain the crash to the DAZ developers; I don't log in and I saw a close-down crash, i.e. not one explicitly on save, one that happend after I closed DAZ Studio itself and "ok'ed" the "save the scene" dialog. The scene was not corrupted so the save had completed.
Correct.
Logging in or not to anything was basicly not an option as DAZ crashed while starting, before there was any opportunity to do anything. However, this now seems a moot point as I downloaded 4.15.0.26 and that seems to work. At least I have been able to open a file, create content, save it and do a render. Thanks for the effort.
Thanks again! It's been ages since a beta crashed on me... maybe it's because of a different machine. Sent in two reports, hopefully they end up useful somehow.
After not beimg able to load DAZ Studio in Big Sur, I went to recovery mode, wiped the drive and loaded Big Sur all over again. Installed the Beta of DAZ studio. DIM installed product for over 2 hours. Next time I loaded DIM showed I had 15 items installed. Opened DAZ and began to install from each product catagory. Some of the products work. Many do no. Error loading contennt. PZ2 files don't read. I was able to load some content and my test render was pretty good.
This may not be an option for everyone. I am looking forward to the next round of updates, see if more content is useable. I am hopeful.
In this beta (4.15.0.26) I noticed that loading a G8M saved previously as a scene subset, and then selecting that figure and loading wearable (with a shell) made earlier, will make second instance of DAZStudio.exe to appear in Task Manager, and, of course, everything just hangs with zero CPU usage. Is it intended behavior? Stable version does this fine, there's no second DAZStudio.exe appearing, even for a moment, wearable loads itself and attaches.
Loading G8M figure as scene subset with wearable (gens with shells for example) also simply hangs this version of Daz after a while, with no figure appearing. Figures without such "attachment" seem to load fine.
"Double" Daz EXE file appears, when I click the hanging program and it becomes white-ish.
Yup, that's exactly what happens. I need to kill the program by force. Figure without an attachment loads fine though.
When adding a few character morphs I have found .25 and now .26 hang when attempting to add a goegraft item and need to be forcibly closed. If the same morphs are loaded in the general release geografts load fine, but then if I save the scene and attempt to reload it in .26 it hangs again and needs to be forcibly restarted, and that scene cannot be reopened in .26
First time I have ever had to roll back a beta version. Glad I make backups now though.
When you "load" a file, how are you loading it? Causing a second exe to launch sounds like you are doing it outside of Daz Studio - i.e., File Explorer, double-click, as only one instance is allowed and should therefore not start if you use the desktop shortcut or Start Menu entries while Studio is running.
Task Manager in Windows 10 (as of the "Fall Creators Update") groups processes by application - the top level entry is the container for the app, the child is the actual process.
Please report these loading issues, and attach an example file if possible
Also send in the error log file from DS if possible.
It's actually totally normal file opening, from within the program. I'm using Windows 10 21H1, and the program itself isn't being run as Administrator. The screenshot I posted is from Process Hacker. I never saw DAZStudio.exe creating a child process like this before though - I'm not using any scripts at launch, no file opening at launch nor I use the scripts used for background rendering as second instance (haven't ever tried it).
Luckily, I had previous beta DIM installers backed up! :)
I agree, it's something about loading geografts/projected morphs from the main figure mesh to the graft - trying to add a geograft as wearable also locks up this beta version.
Log file ends abruptly, doesn't show any error related to it.
This beta (4.15.0.26) doesn't crash at loading grafted figure (I would have a crash report ready otherwise), it locks itself up during that process with no CPU/GPU usage.
Log file itself ends abruptly like this:
And after killing DAZStudio.exe, my next application start is being logged, as usual:
Otherwise, this version works fine and loads and renders anything that is not a figure with a graft (for example genital, no matter who made it). Figures without grafts, with clothes and strands hair, load and render fine and quickly.
Which geograft as wearable are you trying to load? Please name a few, in case I don't have a specific one.
Ekhm, it's actually either a graft from Meipex, or even the one given with Michael 8 Pro. There are shells on them and they've been saved as wearables though. Then an attempt to load such figure, or to load the wearable with figure selected will lock up this version of DS, hovewer, it will not lock up when only wearable/graft is loaded alone in the empty scene. I didn't try to load such wearable without having figure selected, yet.
Well, I've tried Michael 8 and his graft, no problem with that. Nor with the other one you mentioned.
If you load Michael 8, and then the graft, does it load? You mention saved as wearables.
Yes, all it takes is to save the graft as wearable, while it's being "fitted" to figure, and then remove the graft, and then, while M8 is selected, to load that wearable on him. Lock up, endless waiting.
But also just loading the Michael 8, and then his "attachment" locks this beta. No crash. User Mart1n71 also mentioned this, in post #94. Something's not right with loading grafts. I have no such problems with DS 4.15.0.14 beta.
I'm using latest (471.68) NVidia Studio driver for RTX 3090, if it helps.
The only crash I had with this beta DS happens with latest Octane renderer test plugin, at exit, but I had it disabled to be sure it's not the plugin causing this.
About second DAZStudio.exe process - it appears, when Windows saves dump with WerFault.exe from forcing-closing hanged DS application by OS. No such thing will occur if I kill DS with Process Hacker though.
Please try the following: uninstall Octane (remove it from the plugin directory, or rename the file extension so it does not load so that there is no possibility of it having any influence), whilst DS is closed. Then try M8 and the graft again.