TexGen is being terminated prematurely, suddenly closes

[3fast5you]

So I tried to look around and search for someone with a similar issue, but couldn't really find a fix that worked. Apologies if I missed something.

TexGen stops responding and eventually crashes when it reaches the "Creating billboards" part.

No TexGen logs, but Event Viewer has this to say:

Faulting application name: TexGenx64.exe, version: 3.0.0.0, time stamp: 0x61d2f1a9
Faulting module name: TexGenx64.exe, version: 3.0.0.0, time stamp: 0x61d2f1a9
Exception code: 0xc0000005
Fault offset: 0x0000000000895869
Faulting process ID: 0x3428
Faulting application start time: 0x01d800ea10b45f2b
Faulting application path: C:\Faens C\Modding Utilities\DynDOLOD\TexGenx64.exe
Faulting module path: C:\Faens C\Modding Utilities\DynDOLOD\TexGenx64.exe
Report ID: 835b9ca3-7c4d-4d3c-81cc-f79c3c6f1465
Faulting package full name: 
Faulting package-relative application ID: 

Don't know if it is worth mentioning, but originally I had a different error message in the Event Viewer, but then I ran System File Checker, and now I get the above error.
Here is the one before I ran SFC:
Faulting application name: TexGenx64.exe, version: 3.0.0.0, time stamp: 0x61d2f1a9
Faulting module name: KERNELBASE.dll, version: 10.0.19041.1387, time stamp: 0x0b9a844a
Exception code: 0x0eedfade
Fault offset: 0x0000000000034f69
Faulting process ID: 0x592c
Faulting application start time: 0x01d800e553cf8a38
Faulting application path: C:\Faens C\Modding Utilities\DynDOLOD\TexGenx64.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report ID: 07b3f337-478d-4cc7-951e-9de7a42acf16
Faulting package full name: 
Faulting package-relative application ID: 

[sheson]

11 hours ago, Rakz said:

Hi,

I tried what you asked:

• No logs in Event Viewer related to TexGen
• Managed to get a successful run with version 118
• Then, TexGen started closing again without apparent reason (real time logs attached).

Thanks!

TexGen_SSE_realtime_log-BaseSize256-HDTreeDisabled.txt 2.19 MB · 0 downloads

If there are no normal log, debug log written it means TexGen is being terminated without going through its exception handler and shutdown procedures.

If there is really no Windows Event log, look into things like hardware trouble, for example CPU overclocking/cooling, BIOS settings, memory timings etc. 

See what happens by adding TextureCache=10 under [TexGen] in ..\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.INI
Then test what happens setting RenderThreads=1

[Onyx]

I'm having problems running TexGen64 with Alpha 122. It's exiting without any error message, warning, pop-up, or anything else when it starts generating textures after gathering billboards. I've attached the realtime log and a Windows Event log. I've tried using BC1 and BC3 compression as detailed on the last page and that didn't help. I've also updated to the latest 531.41 Nvidia drivers.

Logs.zip

[sheson]

4 hours ago, Onyx said:

I'm having problems running TexGen64 with Alpha 122. It's exiting without any error message, warning, pop-up, or anything else when it starts generating textures after gathering billboards. I've attached the realtime log and a Windows Event log. I've tried using BC1 and BC3 compression as detailed on the last page and that didn't help. I've also updated to the latest 531.41 Nvidia drivers.

Logs.zip 217.78 kB · 1 download

See what happens with this test version https://mega.nz/file/RUQlla5T#3dsJH7Ec5qPTRb-DYghY2srcoC1yRAm0rTzEkc8EKGg

If there are still issues, add GLListDebug=1 and GLDebug=1 under [TexGen] to ..\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.INI.
Only enable the RealTimeLog in case the program is terminated without having the chance to writes its own bugreport, log and debug log.

[Onyx]

20 hours ago, sheson said:

See what happens with this test version https://mega.nz/file/RUQlla5T#3dsJH7Ec5qPTRb-DYghY2srcoC1yRAm0rTzEkc8EKGg

If there are still issues, add GLListDebug=1 and GLDebug=1 under [TexGen] to ..\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.INI.
Only enable the RealTimeLog in case the program is terminated without having the chance to writes its own bugreport, log and debug log.

Hi Sheson,

In trying to troubleshoot before I posted here, I had been running with and without GLListDebug=1 and GLDebug=1 as well already (although come to think of it that may have simply been useless without a test version like that one). I had enabled the real time log because TexGenx64 was indeed terminating without any other log files being generated.

I may have solved whatever my issue was by fumbling around with my load order. My issues began after I'd added ELFX Shadows (on top of other ELFX mods), but changing some overwrite ordering with Particle Patch for ENB seems to have done the trick. I previously had Particle Patch loading after most everything else in accordance with Vortex's recommendations, but some more Nexus posts I found indicated that Particle Patch should come much earlier in a load order and tend to be overwritten by most things. Doing that is what seems to have allowed things to work again. I can run TexGenx64 and DynDOLODx64 successfully.

If you'd like, I can try to recreate the old load/overwrite order again to try to break it again for troubleshooting. I'm not sure how much value that would add for you.

Edited April 4, 2023 by Onyx

[sheson]

3 hours ago, Onyx said:

Hi Sheson,

In trying to troubleshoot before I posted here, I had been running with and without GLListDebug=1 and GLDebug=1 as well already (although come to think of it that may have simply been useless without a test version like that one). I had enabled the real time log because TexGenx64 was indeed terminating without any other log files being generated.

I may have solved whatever my issue was by fumbling around with my load order. My issues began after I'd added ELFX Shadows (on top of other ELFX mods), but changing some overwrite ordering with Particle Patch for ENB seems to have done the trick. I previously had Particle Patch loading after most everything else in accordance with Vortex's recommendations, but some more Nexus posts I found indicated that Particle Patch should come much earlier in a load order and tend to be overwritten by most things. Doing that is what seems to have allowed things to work again. I can run TexGenx64 and DynDOLODx64 successfully.

If you'd like, I can try to recreate the old load/overwrite order again to try to break it again for troubleshooting. I'm not sure how much value that would add for you.

The load order of mods, especially when they do not contain textures used by TexGen, should have any effect on TexGen being terminated by the OS / exceptions with nvoglv64.dll without OPenGL reporting back the problem as "invalid operation" for example and TexGens own exception handler being executed. If anything it is indirectly. Check if the last mentioned full textures that are loaded in the log are from a different mod now.

[Onyx]

On 4/4/2023 at 1:12 AM, sheson said:

The load order of mods, especially when they do not contain textures used by TexGen, should have any effect on TexGen being terminated by the OS / exceptions with nvoglv64.dll without OPenGL reporting back the problem as "invalid operation" for example and TexGens own exception handler being executed. If anything it is indirectly. Check if the last mentioned full textures that are loaded in the log are from a different mod now.

I admit I've reached the end of my limited knowledge (and I'm a decade removed from Skyrim modding, getting back into it now) so I apologize in advance for that. By last mentioned full textures, do you mean the textures from the last line that has a "Loading..." statement like:

[02:58] [TwbRender.LoadTexture] <Debug: Loading textures\dlc01\dungeons\castle\CastleWallStone05.dds>

Should I be looking in my Vortex staging area to determine from which mod that file exists? Because I think the last texture that had that loading statement in my prior logfile was SERuinsBronzeInlay01_n.dds, which I don't see in my staging folder currently. I suppose that makes sense - I must have removed another mod in my fumbling that had the problem texture and that ""fixed"" the issue. (not really because it just avoided it without me understanding why)

I ran again with the test executable you provided and attached the log from that run. If I'm understanding correctly, this time the CastleWallStone05.dds file exists in Skyrim 202X 9.0.1 - Other. Is there anything else I can do to give you more info?

TexGen_SSE_realtime_log.zip

Edited April 8, 2023 by Onyx

[sheson]

11 hours ago, Onyx said:

I admit I've reached the end of my limited knowledge (and I'm a decade removed from Skyrim modding, getting back into it now) so I apologize in advance for that. By last mentioned full textures, do you mean the textures from the last line that has a "Loading..." statement like:

[02:58] [TwbRender.LoadTexture] <Debug: Loading textures\dlc01\dungeons\castle\CastleWallStone05.dds>

Should I be looking in my Vortex staging area to determine from which mod that file exists? Because I think the last texture that had that loading statement in my prior logfile was SERuinsBronzeInlay01_n.dds, which I don't see in my staging folder currently. I suppose that makes sense - I must have removed another mod in my fumbling that had the problem texture and that ""fixed"" the issue. (not really because it just avoided it without me understanding why)

I ran again with the test executable you provided and attached the log from that run. If I'm understanding correctly, this time the CastleWallStone05.dds file exists in Skyrim 202X 9.0.1 - Other. Is there anything else I can do to give you more info?

TexGen_SSE_realtime_log.zip 289.83 kB · 0 downloads

Yes any texture in the last 2 or so seconds that has [TwbRender.LoadTexture] <Debug: Loading ... Not necessarily the last one, as things are multi-threaded and all parallel processes write to the log at the same. In this case textures\architecture\solitude\SStoneBase01.dds is also of interest. 
Edit ..\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.INI in notepad and add RenderTexturesSingleThread=1 under [TexGen] might help to have a clearer log - but might also make it so that the problem does not occur. See what happens if you do that.

If a file does not exist as loose file but only in BSAs, you can use the xEdit Asset Browser that is started with CTRL+F3 after loading the entire load order into xEdit. After enterting part of a filename into the filter field, the first mentioned container (BSA) for a file is the winning one. Data means loose file.

[Onyx]

4 hours ago, sheson said:

Yes any texture in the last 2 or so seconds that has [TwbRender.LoadTexture] <Debug: Loading ... Not necessarily the last one, as things are multi-threaded and all parallel processes write to the log at the same. In this case textures\architecture\solitude\SStoneBase01.dds is also of interest. 
Edit ..\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.INI in notepad and add RenderTexturesSingleThread=1 under [TexGen] might help to have a clearer log - but might also make it so that the problem does not occur. See what happens if you do that.

If a file does not exist as loose file but only in BSAs, you can use the xEdit Asset Browser that is started with CTRL+F3 after loading the entire load order into xEdit. After enterting part of a filename into the filter field, the first mentioned container (BSA) for a file is the winning one. Data means loose file.

This should be the log from a single threaded run. For better or worse, no change with only single threaded, it's still exiting early with no other logs being generated. I don't really have a good understanding of where to go next from here.

Whoops, I had run with only having RenderThreads=1, not actually RenderTexturesSingleThread=1. With that additional flag, it looks like it's going to succeed (still running but it's already gotten past the prior error point). I'll upload the logs from this run once they finish and I wake up.

Also that is a really cool feature, thanks for the tip! I see that the textures\architecture\solitude\sstonebase01.dds winner is from loose files. It has, in order: Data, Enhanced Solitude SSE.bsa, Skyrim - Textures1.bsa.

Edited April 9, 2023 by Onyx

[Onyx]

11 hours ago, sheson said:

Yes any texture in the last 2 or so seconds that has [TwbRender.LoadTexture] <Debug: Loading ... Not necessarily the last one, as things are multi-threaded and all parallel processes write to the log at the same. In this case textures\architecture\solitude\SStoneBase01.dds is also of interest. 
Edit ..\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.INI in notepad and add RenderTexturesSingleThread=1 under [TexGen] might help to have a clearer log - but might also make it so that the problem does not occur. See what happens if you do that.

If a file does not exist as loose file but only in BSAs, you can use the xEdit Asset Browser that is started with CTRL+F3 after loading the entire load order into xEdit. After enterting part of a filename into the filter field, the first mentioned container (BSA) for a file is the winning one. Data means loose file.

OK, with RenderTexturesSingleThread=1 the run succeeded. I've attached all 3 logs that came from this run. Should I just keep that flag in my config and consider this issue solved? DynDOLOD was also able to complete successfully (albeit not free of warnings or errors).

TexGen_SSE_singlethreaded_logs.7z

[sheson]

1 hour ago, Onyx said:

OK, with RenderTexturesSingleThread=1 the run succeeded. I've attached all 3 logs that came from this run. Should I just keep that flag in my config and consider this issue solved? DynDOLOD was also able to complete successfully (albeit not free of warnings or errors).

TexGen_SSE_singlethreaded_logs.7z 522.79 kB · 0 downloads

Thanks for the logs. Yes, it is OK, since we now know that none of the textures are cause of the exception in the nvoglv64.dll that can be avoided by not using multiple render contexts, which is a workable option for now.

[Wulfga]

Alright, I'm just trying to get through this while I still even want to play Skyrim again. I've done this before on v2, this is my first time with v3. I've been Googling and RTFM'ing this for 3 days and I've made what might be progress but doesn't really feel like it yet. 

I'm following STEP5 religiously. Step Skyrim Special Edition Guide (stepmodifications.org)

Running xTexgen64 yields the attached logs. It normally gets to creating textures and simply ends abruptly without error logs or codes. I've been able to capture a couple though, so I'm hoping I can get through posting this successfully. Attached Event Viewer logs also. Attached my modlist; I'm sure I've botched something, but posting a heat log is less anxiety provoking at work than it is here, so please go easy on me.

Reasonably certain I've followed the directions here. I'm past the LODgen step, which went much better after I read the manual a second time and switched to the STEP guide. I gave up completely on ever having grass, the instructions there were more than I was interested in diving into when I can't get through it without.

Crash happens right there at the memory drop-off.

Running from commandline as suggested in other posts launches the app correctly with no errors.

I do have AV, but I went overboard potentially and created a dozen exceptions for everything here. I have PHI/CBI on this box, kinda need at least a basic security layer. It's never bothered anything else but mentioning just in case.

I've seen these come up while spending over a day reading the other threads:

NVIDIA bits:

Please tell me what I've left out, and how I can get through this. Thanks in advance.

bugreport2jun23.txt apploginfo.txt applogerror.txt modlist.xlsx

[sheson]

On 6/2/2023 at 4:08 PM, Wulfga said:

Alright, I'm just trying to get through this while I still even want to play Skyrim again. I've done this before on v2, this is my first time with v3. I've been Googling and RTFM'ing this for 3 days and I've made what might be progress but doesn't really feel like it yet. 

I'm following STEP5 religiously. Step Skyrim Special Edition Guide (stepmodifications.org)

Running xTexgen64 yields the attached logs. It normally gets to creating textures and simply ends abruptly without error logs or codes. I've been able to capture a couple though, so I'm hoping I can get through posting this successfully. Attached Event Viewer logs also. Attached my modlist; I'm sure I've botched something, but posting a heat log is less anxiety provoking at work than it is here, so please go easy on me.

Reasonably certain I've followed the directions here. I'm past the LODgen step, which went much better after I read the manual a second time and switched to the STEP guide. I gave up completely on ever having grass, the instructions there were more than I was interested in diving into when I can't get through it without.

Crash happens right there at the memory drop-off.

Running from commandline as suggested in other posts launches the app correctly with no errors.

I do have AV, but I went overboard potentially and created a dozen exceptions for everything here. I have PHI/CBI on this box, kinda need at least a basic security layer. It's never bothered anything else but mentioning just in case.

I've seen these come up while spending over a day reading the other threads:

NVIDIA bits:

Please tell me what I've left out, and how I can get through this. Thanks in advance.

bugreport2jun23.txt 195.67 kB · 1 download apploginfo.txt 3.73 kB · 1 download applogerror.txt 2.45 kB · 0 downloads modlist.xlsx 29.9 kB · 0 downloads

See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which bugreport.txt and debug log to also upload. The debug log gets replaced with every session, so in case it is still valid to the error, save/upload it it right away.

Add RenderSingle=1 under [TexGen] in H:\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.ini and check if it makes a difference. It helped other people one or two thread pages back that also had an exception in the NVIDIA driver nvoglv64.dll

[Wulfga]

..\DynDOLOD\bugreport.txt

Doesn't exist. 

..\DynDOLOD\Logs\[DynDOLOD|TexGen_SSE_log.txt (truncate large log files to the entire last meaningful generation beginning with the log message  "... starting session ..." )

Had left everything in there since it hadn't crashed the same way twice. Followed exact instructions. Yes, I put a date at the end, let's overlook that.

..\DynDOLOD\Logs\[DynDOLOD|TexGen_SSE_Debug_log.txt (always upload entire debug log)

Did that. Doing it again.

 

If issue involves LODGen upload/paste
..\DynDOLOD\Logs\LODGen_[TES5|ENDERAL|SSE|TES5VR|ENDERALSE]_[Worldspace]_log.txt

(Doesn't exist yet)

 

Attached my .ini in case there's something egregiously wrong in there. Did what you said, I still get to here (which is farther than I get probably 60% of the time).

[00:57] Creating textures
[01:15]     Creating texture H:\Modding\Tools\DynDOLOD\TexGen_Output\Textures\dlc01\lod\dlc01icewalllod.dds with H:\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\Render\Skyrim\Objects\dlc01\lod\dlc01icewalllod.nif

I can hear the fans spin up a little, then it stalls out and eventually the screen disappears. It took longer to crash this time but I never got past this line. the TexGen_SSE_log (6-2-2023).txt is the run with your ini edit in place.

TexGen_SSE.INI

 

I know this is irritating on both ends. I appreciate you even responding at all, and I've done what I can to minimize how irritating my posts are. I could not handle 504 pages of bug reports and questions- I would lose my mind... so, yeah, thanks.

TexGen_SSE_Debug_log.txt TexGen_SSE_log (6-2-2023).txt

[sheson]

19 minutes ago, Wulfga said:

Did what you said, I still get to here (which is farther than I get probably 60% of the time).

[00:57] Creating textures
[01:15]     Creating texture H:\Modding\Tools\DynDOLOD\TexGen_Output\Textures\dlc01\lod\dlc01icewalllod.dds with H:\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\Render\Skyrim\Objects\dlc01\lod\dlc01icewalllod.nif

If you got to "there" why is that not the last line of the logs you uploaded? The log and debug log show it started to gather base records for billboards (uses CPU) and did not start to render a texture yet.

19 minutes ago, Wulfga said:

I can hear the fans spin up a little, then it stalls out and eventually the screen disappears. It took longer to crash this time but I never got past this line. the TexGen_SSE_log (6-2-2023).txt is the run with your ini edit in place.

You probably have a hardware, driver, overclocking, BIOS setting, OS issue. TexGen using Open GL API or Tecconv using DirectX API is not supposed to be able cause this no matter what they do. What is reported in the Windows event log?

[Wulfga]

Quote

If you got to "there" why is that not the last line of the logs you uploaded? The log and debug log show it started to gather base records for billboards (uses CPU) and did not start to render a texture yet.

I guess I did a bad job explaining that part. That window with the scolling text... if that's your debug log, it doesn't save at all when it just errors out and ends abruptly. I only get it to close normally and create the logs I've attached one out of every... maybe 9 attempts. I'm in the hundreds probably. 

I have removed overclocking from the CPU, yesterday I think. My graphics card memory is overclocked a little but extremely stable. Attached CPU-Z, because running out of ideas.

Attached the only additional log file that survived long enough in that temp folder to grab it. 

Error log from Event Viewer:
Faulting application name: TexGenx64.exe, version: 3.0.0.128, time stamp: 0x646a6e33
Faulting module name: nvoglv64.dll, version: 31.0.15.3598, time stamp: 0x646dfba9
Exception code: 0xc0000005
Fault offset: 0x0000000001550f2a
Faulting process id: 0x0x5484
Faulting application start time: 0x0x1D995612705F484
Faulting application path: H:\Modding\Tools\DynDOLOD\TexGenx64.exe
Faulting module path: C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_3c2bd4a1ec6d228e\nvoglv64.dll
Report Id: fabd6cbe-c4a7-44ed-9ac3-f7166bb8d365
Faulting package full name: 
Faulting package-relative application ID: 

Info log from event:

Fault bucket 1897463078308581007, type 4
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: TexGenx64.exe
P2: 3.0.0.128
P3: 646a6e33
P4: nvoglv64.dll
P5: 31.0.15.3598
P6: 646dfba9
P7: c0000005
P8: 0000000001550f2a
P9: 
P10: 

Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.190bcaf4-91c6-4d6b-aaa4-a1c764e90a88.tmp.dmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.143f5221-3e03-4c96-b9e7-e10fa80b639e.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.e5c8fd98-60a4-4bee-9a87-9c3566ef8a34.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.165cd335-cfd1-4050-92c5-b7d3037f165d.tmp.txt
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.43564062-c08f-4f02-b8e7-7a71c81d2a0d.tmp.xml

These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_TexGenx64.exe_6f6a94369d9c1185cd99bbdf7a6bac316c9e971e_5b7d448d_8f98ccab-d9b2-4a22-81d8-9332586eff8a

Analysis symbol: 
Rechecking for solution: 0
Report Id: fabd6cbe-c4a7-44ed-9ac3-f7166bb8d365
Report Status: 268435456
Hashed bucket: 1dd0260b7426beeeea55249dd5008e8f
Cab Guid: 0

WER.297e2947-b1c3-4f61-b940-af707c587f6e.tmp.WERInternalMetadata.xml GHOST-CPUZ.txt