LODGen.exe Crash: EndOfStreamException

[airbreather]

So I was about to open a new issue over here, but I figured I'd run it by you guys first to see if there's anything I'm missing.  I was just going to paste below what I was about to post and reformat it, but along the way I discovered something that makes me lean towards it being a STEP issue (though I'm still very unsure because of all the different postprocessing that we do during a STEP setup and the fact that ModOrganizer loves to overwrite file data without changing the metadata).

 

I ran into this stack trace when trying to generate LODs for STEP 2.2.9.2:

System.IO.EndOfStreamException: Unable to read beyond the end of the stream.
   at System.IO.BinaryReader.FillBuffer(Int32 numBytes)
   at System.IO.BinaryReader.ReadUInt16()
   at LODGenerator.NifMain.NiHeader.Read(BinaryReader reader)
   at LODGenerator.NiFile.Read(String gameDir, String fileName, LogFile logFile)
   at LODGenerator.LODApp.<>c__DisplayClass4.<GenerateLOD>b__2(Object state)
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart(Object obj)

It was during the generation for Tamriel, of all things.  Being a .NET developer by trade, I know what this means, so I attached a debugger after the exception was thrown.  It revealed that NifHeader.headerString at the time of the crash was:

"DDS |\0\0\0\a\u0010\b\0\0\u0001\0\0l\0\0\0\0l\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\u0004\0\0\0DXT3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\u0010\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\u0002\u0011\u0002\u0011\0\0\0\0\0\0\0\0\0\0\0\0\u0002\u0011\u0002\u0011\0\0\0\0\0\0\0\0\0\0\0\0\u0002\u0011\u0002\u0011\0\0\0\0\0\0\0\0\0\0\0\0\u0002\u0011\u0002\u0011\0\0\0\0\0\0\0\0\0\0\0\0\u0002\u0011\u0002\u0011\0\0\0\0\0\0\0\0\0\0\0\0\u0002\u0019\u0002\u0011****\0\0\0\0\0\0\0\0\"\u0019\u0002\u0019\u0095\u0095\u0095*\0\0\0\0\0\0\0\0\"\u0019\u0002\u0019"

That seemed a bit long and awkward for something that's stored as a string, so pulling up some of the files, I noticed that the ones I randomly picked would tend to start with "DDS |" followed by 0x00, 0x00, 0x00, 0x0a, 0x10, 0x0a (dec: 10) which would cause this code to stop reading the header.  Pulling up SkyFalls + SkyMills \ Textures \ Terrain \ Blackreach \ Objects \ blackreach.objects.dds, it seems to start with "DDS |", followed by 0x00, 0x00, 0x00, 0x07, 0x10, 0x08 and then a few hundred more bytes before a seemingly wild 0x0a shows up.

 

That didn't satisfy me much, so I retried by grabbing the source code, running VS2015 under ModOrganizer, unticking "Optimize Code" in the debug build, and re-ran it with a debugger attached so I could get the details about exactly what's going wrong.  The offender is TreePineForest03_0004B016.dds from "STEP Mod Compilation and v2.2.9.2i Patches", apparently (attached what I've got).  Opening random .dds files in the folder where that came from, it would appear that most of textures in here have the same kind of preamble.  So either I've made a mistake, I've gone mad, the world's gone mad, or xLODGen is perhaps only expecting to deal with a subset of the DDS spec.

 

I've set up STEP 2.2.9 successfully in the past, including the DynDOLOD stuff, but this is the first time I've dealt with the STEP Compilation.  I have yet to try 2.2.9.2 again from scratch.

 

More Info:

1. Windows 7 x64
2. .NET Framework version 4.6.01055 (4.6.1 / release 394271)
3. LODGen.exe 0.8, MD5: 036bdaf45e1299a776fe719bd90f0a2d

Edit: really, truly attached what I've got.

TreePineForest03_0004B016.zip

[zilav]

Nope, it is a faulty nif mesh from one of your mods. I asked Sheson to show mesh name when exception occures, but looks like he forgot to add that. You can try disabling mods to find out the source of issue.

[airbreather]

Nope, it is a faulty nif mesh from one of your mods. I asked Sheson to show mesh name when exception occures, but looks like he forgot to add that. You can try disabling mods to find out the source of issue.

 

Looking through again, I wasn't using the latest TES5Edit, and there may have been some other dirty changes left over in my TES5Edit folder.  Dumping that and all DynDLOD stuff and regenerating those things seems to have fixed it.

[sheson]

Yeah, current versions of LODGen are 1.0 beta x

0.8 is quite old