DynDOLOD is being terminated prematurely, suddenly closes

[VulKun]

I can use 2.98 but i cant use 3 alphax. Still doesnt work for me. Just closing itself and there is no bugreport or something. I tried everything but nothing change 

[sheson]

1 hour ago, lighthouse-lady said:

Nothing has stood out to me that would imply hardware error, I can use window event viewer and find no other violation or with the same code as this one. I did stress test though and everything runs smoothly with more than reasonable temps (I can play cyberpunk with 50-60 for gpu & cpu) with no crashing or artifacts of any kind w/o overclocking aside from xmp. I found something saying that memory page for my ssd could be the issue and to solve this I should try increasing the pool? Is it fair to say that this might be to with city/town expansion mods I have installed? I did try once to just generate Tamriel so that stuff like Beyond Reach wouldn't interfere somehow. Maybe looking through SSEedit is the only option left? I'm not sure where to begin looking though since I don't have anything to help diagnose this.

EDIT: I did recently have my motherboard RMA'd and since it was the same model and everything I felt no need to reinstall windows but I suppose an OS issue could be causing this. I've thought that a corrupt OS would not only be obvious just with regular desktop usage but also through gaming (like crashing or low performance). 

No realtime log was provided.

Playing a game is not the same as actual stresstesting with prime95 or OCCT.

I typically suggest to let the OS handle page files / virtual memory. If that is already the case, you can test if setting the same amount as the main memory makes a difference.

Switching hardware should not require reinstalling the OS.

[lighthouse-lady]

In fairness I did in fact stress test but was doubtful anything would show since this is the single instance I've ever had an error of this sort before and the first time I've encountered an oddity like this. But following your advice, I did now try raising the memory pool and sadly it did not help. I understand if there isn't anything else you could say might work to solve this since I've exhausted through a lot just getting to the option of stress testing so I think I may have an issue with some conflicts between mods which was something I had to resolve before with SSEEdit (and was given the exact details via an error message) prior to it having the opportunity to terminate prematurely like it has now. Either way I really do appreciate your quick responses which I can imagine is probably frustrating since I lack a lot know-how with the "modding stage" aside from the basics. I think you've made a remarkably impressive mod that works wonderfully from what I've seen in user reports & video demonstrations, I just happen to be doing something wrong. 

[sheson]

41 minutes ago, lighthouse-lady said:

In fairness I did in fact stress test but was doubtful anything would show since this is the single instance I've ever had an error of this sort before and the first time I've encountered an oddity like this. But following your advice, I did now try raising the memory pool and sadly it did not help. I understand if there isn't anything else you could say might work to solve this since I've exhausted through a lot just getting to the option of stress testing so I think I may have an issue with some conflicts between mods which was something I had to resolve before with SSEEdit (and was given the exact details via an error message) prior to it having the opportunity to terminate prematurely like it has now. Either way I really do appreciate your quick responses which I can imagine is probably frustrating since I lack a lot know-how with the "modding stage" aside from the basics. I think you've made a remarkably impressive mod that works wonderfully from what I've seen in user reports & video demonstrations, I just happen to be doing something wrong. 

No realtime log has been provided, so it is not clear what is being worked on at the moment of the crash or if it happens always at the same time.

c000001d from the event log is all I have to go on at the moment.

This should not really be an issue caused by mods or the compiled program code itself when everything works normally. Typically the error and crash handlers catch all normal issues and write them to the log or at least a bugreport.txt.

[lighthouse-lady]

Hmm, well it consistently follows the trend of launching LOD generation (e.g Tamriel) and then once that window is closed the entire process just terminates after finding no trace of it in task manager. Is there a way I can enable realtime log even in spite of the program's abrupt termination?

[sheson]

7 minutes ago, lighthouse-lady said:

Hmm, well it consistently follows the trend of launching LOD generation (e.g Tamriel) and then once that window is closed the entire process just terminates after finding no trace of it in task manager. Is there a way I can enable realtime log even in spite of the program's abrupt termination?

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs what to do in case the tool is being terminated prematurely and can not write the logs.

[lighthouse-lady]

So I added the line RealTimeLog=1 --does it matter where I place it in the ini file? I ran the tool after making this change and I didn't find any logs besides the ones I have already...

[sheson]

14 hours ago, lighthouse-lady said:

So I added the line RealTimeLog=1 --does it matter where I place it in the ini file? I ran the tool after making this change and I didn't find any logs besides the ones I have already...

https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs
Add RealTimeLog=1 under [TexGen] or [DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\[TexGen|DynDOLOD]_[GAME MODE].INI respectively.

Adding it at the bottom of the INI file for example. By the time the options window shows, the real time log file should be in the log folder already.

[lighthouse-lady]

Sorry, I got side-tracked for some time before getting back. So yes, I tried running it with the line pasted into the dyndolod.ini but I still only have the same logs as before. I'm not sure if mentioned load order or not but even though I have personally sorted my entire modlist according to what others have said optimal, I ran the tool with only the essential world building and texture mods and yet it still failed to complete its course. I'm trying not be annoying but I really just have no idea where to venture next. Of course I could skip the mod but I'm really interested in it...

[sheson]

3 hours ago, lighthouse-lady said:

Sorry, I got side-tracked for some time before getting back. So yes, I tried running it with the line pasted into the dyndolod.ini but I still only have the same logs as before. I'm not sure if mentioned load order or not but even though I have personally sorted my entire modlist according to what others have said optimal, I ran the tool with only the essential world building and texture mods and yet it still failed to complete its course. I'm trying not be annoying but I really just have no idea where to venture next. Of course I could skip the mod but I'm really interested in it...

If DynDOLOD can not write other logs files while running but not the realtime log, then the wrong INI file is being edited or the setting is not added correctly.

Copy and paste the line
RealTimeLog=1
to bottom of DynDOLOD_SSE.ini

Once the wizard/advanced options window shows, there should be a DynDOLOD_SSE_realtime_log.txt in the logs folder.

[lighthouse-lady]

Ok I'm stupid I was editing the DynDOLOD non-sse config instead of sse one. So after running the tool not only was the log created but the tool ran flawlessly this time. Is there a specific reason why this is so? Here's the log anyways if that helps with that question: https://ufile.io/pltiwpme. I'm not sure if there was something possibly bypassed by enabling this setting and that's what allowed the tool to run without being halted--but if this doesn't sound like a true solution to you maybe I should be doing something else? I've tried things like running the tool in administrator mode (yeah I know stupid) yet that did nothing and this did...

[sheson]

On 12/10/2024 at 4:26 AM, lighthouse-lady said:

Ok I'm stupid I was editing the DynDOLOD non-sse config instead of sse one. So after running the tool not only was the log created but the tool ran flawlessly this time. Is there a specific reason why this is so? Here's the log anyways if that helps with that question: https://ufile.io/pltiwpme. I'm not sure if there was something possibly bypassed by enabling this setting and that's what allowed the tool to run without being halted--but if this doesn't sound like a true solution to you maybe I should be doing something else? I've tried things like running the tool in administrator mode (yeah I know stupid) yet that did nothing and this did...

Writing the realtime log means the tool is using a bit less CPU and the entire process to take a bit longer. It will generate everything just the same, so the output is perfectly usable.

[lighthouse-lady]

I see, do you think there is a clear explanation for this anyways? Have you encountered someone that this worked for as well? It just seems kind of strange but of course I'm glad that it works at least!

[sheson]

8 minutes ago, lighthouse-lady said:

I see, do you think there is a clear explanation for this anyways? Have you encountered someone that this worked for as well? It just seems kind of strange but of course I'm glad that it works at least!

Less demand on certain resources so the situation with the error is avoided. Probably happened before trying to troubleshoot TexGen being terminated IIRC. 

[lighthouse-lady]

Makes sense. I seriously doubt I would have managed to pin down the problem without you so thank you so much for helping a newbie like myself! Have a good one!

[lighthouse-lady]

So I just wanted to follow-up with this issue as I didn't want to rely on a workaround but also I was really curious what cause of it is especially after reading this windows error;

"Windows cannot access the file for one of the following reasons: there is a problem with the network connection, the disk that the file is stored on, or the storage drivers installed on this computer; or the disk is missing. Windows closed the program Taking Your Firstborn because of this error."

I know that windows errors can be rather cryptic when diagnosing application failures and this is especially true when I know myself that this could not be a hardware issue after stress-testing as you've mentioned and no other signs of failure (I forgot to mention that I am using a 12700kf cpu) and modern. So I looked over my windows firewall settings and which applications are allowed to run or not... but I could not find "Taking Your Firstborn" (lol) anywhere in the list so I decided to just add it. Well--it runs perfectly now without the workaround. I realized building LODs for Tamriel was the most resource intense which is probably why it was blocked by my firewall (don't know why the application wasn't listed though... maybe it updates in realtime when it encounters a supposed threat unlike ones it recognizes by default). Just thought this might help anyone who is having the same problem. Thanks again though for your time in helping me solve this!

Edited December 19, 2024 by lighthouse-lady