Great that you did all that testing. I will have to wait for the deluge of error reports from all the other users before I attempt to reproduce the "DynDOLOD issue" that all of sudden befell it. Test with the x86 version or vice versa the x64 version.
In the meantime maybe you could double check the .NET 4.0 installation and the Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 and 2019. Maybe a recent update to those causes issues.
If problem persists post error report with entire contents (not just the last couple lines) of ..\DynDOLOD\bugreport.txt (if it exists) and ..DynDOLOD\Logs\DynDOLOD_[GAMEMODE]_log.txt
If you see problems with LODGen.exe again, maybe you could test the earlier versions included in xLODGen beta 42 or beta 45.
I have already updated my .NET and VC++ redistributable a week ago to resolve a different problem with 2.65 (which btw also looked like a concurrency/synchronization issue).
Regarding attempting to reproduce this specific issue, I can only say that from my experience with multi-thread/multi-process programs such concurrency/synchronization issues are often quite hard to impossible to reproduce on a different system. I have seen synchronization issues which after they have been identified you scratch your head "how the hell did this ever work?" and yet it worked in production on many many machines without any problems until this one machine on which the issue "suddenly" surfaced. Hence my offer to help in any way I can to investigate it on my machine.
In the meantime, I possibly found a workaround, by disabling all three of the "FasterXXX=0" in the DynDOLOD_SSE.ini (possibly disabling only "FasterBase=0" is enough). When disabling all three the runtime only slightly increases (from ~ 14 mins for all worlds to ~ 15.5 mins). Since I have done this I have not seen the "Error reading NIF" even once. Oddly when trying to test the stability of these options by selecting only the Sovngarde world (for quicker runs so I can test it multiple times quickly), it seems to deadlock on "Preparing texture data" about 50% of the times. At this point I have run quite a few runs on all worlds (including Sovngarde) with these options and none of them deadlocked. I am not sure how to explain this.
I have also managed to reproduce the LODGen error with 2.5.6 (the version inside "Edit Scripts" of the xLODGen beta 42 archive):
This still happens very rarely for me (a total of 3 times till now, once with 2.65, once with 2.66 and LODGen 2.6.2 and now once with LODGen 2.5.6).
Btw using the new LODGen 2.6.2 (as opposed to version 2.5.6) DynDOLOD runs slightly faster and the result is smaller without any quality loss I can discern (do note I am not sensitive to delicate difference in quality). So at least from my point of view, very good job on the new LODGen.
Meanwhile, I have actually managed to clean my tree mods and reach a DynDOLOD result I am pleased with .
The only problem I still have, is that when generating "Ultra Trees" (TreeLOD=0), as I close in on far away trees they switch almost instantaneously from the LOD to the full model. Its definitively not the 2.7 seconds in the DynDOLOD MCM menu. I have tried to increase this setting to the maximum of 5 seconds with no noticeable difference. This bothers my eyes enough that I think I even prefer the much less refined TreeLOD=1 LODs, on which the transition is gradual (most likely the 2.7 seconds from the config, although I didn't bother to measure it).
Is there something I can do to both have "Ultra Trees" and a gradual transition from the LODs to the full model?
BTW many thanks for this great tool and your dedicated support.