New SKSE, New EXE - Skyrim SE CTD in opening seconds with NTdll.dll fault

[BlueGunk]

I updated my Skyrim SE today to 1.5.73, SKSE 2.0.15 and all seemed to go well. Game loads up, goes on scene. After a few seconds the sound pops in and out, and CTD.

This message in the Administration Events:

 

Faulting application name: SkyrimSE.exe, version: 1.0.0.0, time stamp: 0x5c7ec169

Faulting module name: ntdll.dll, version: 10.0.17763.348, time stamp: 0xca65c822

Exception code: 0xc0000374

Fault offset: 0x00000000000faf49

Faulting process ID: 0x2844

Faulting application start time: 0x01d4e7393e4e62ea

Faulting application path: G:\GAMES\Steam\steamapps\common\Skyrim Special Edition\SkyrimSE.exe

Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll

Report ID: 241ad5ce-1b89-4bbd-9928-89591e70f88d

Faulting package full name:

Faulting package-relative application ID:

 

I'll see if I can generate a DMP report. But it looks like heap corruption? I guess it's a DLL blow-out? SKSE bug?

System: Win 10 home, i7-4790, GTX908Ti 6GB, 16GB RAM. Skyrim on an SSD away from C:Program Files.

 

My previous version has been running well for months.

 

Any help please - much appreciated. Thanks.

 

UPDATED: I believe I have tracked this fault to FISS and so I have contacted the author for help.

[Deleted58783396User]

before we get into the gritty solution: can you completely uninstall FISS to see if your crash continues, so we can see if your NTDll is not corrupt.

 

should that not solve the problem continue reading below:

 

 

to problem solve this, is not simple (if you wish to problem solve based on the Crash Report)

 

you will be required to download a dissembling program (such as Windbg), or Visual Studio, you will need windows symbols, and will need to understand the Call stack, this means you will need to be able to Read Assembly *ASM* for short.

 

you will be reading the same language that your hardware understands

 

Low Level Programming language

 

the Call Stack will tell you all the information you desire, especially what caused the crash, however understand, that it is completely written in Machine Code

 

the crash log you have, already gives you a massive helping hand, as you would then go to the Offsets it listed (the Exception is the Offset you need to go to) then read all information before it got to the Fault Offset to understand the process that lead to the Crash

 

basically this is advanced problem solving. this is a guaranteed way to problem solve an Application, but also the hardest as you need very good knowledge on Low Level Programming. which a typical computer user would not have (Generally Speaking).

[BlueGunk]

Thank you!

 

Yes, removal of FISS solves the crash problem completely. Re-acquiring the mod in game causes the crash and it is repeatable-specific. So FISS is the culprit.

Fortunately I use it to support only one other mod, and I can progress without it for a while until it is fixed.

 

Thanks for the second part - I did have Visual Studio on my previous PC to interpret DMPs, but I am not a computer programmer and most of it was way beyond me.

(The nearest I came to programming was in 1978 with routines on punched cards and ribbon. Lol :geek: )

Now I send DMPs for 3rd party unpacking so I can scan through and at least get a sense for the type of fault I am looking for.

 

But I could not find a DMP report for this particular crash.

 

Thanks for stopping by and offering some suggestions. I'll look out Windbg and see what I can make of it.

 

Cheers! I dropped you a Kudos on your FO4 profile.

 

UPDATE - oh no it doesn't.....

[BlueGunk]

Oh wait. Nope! I started playing the game without FISS. After one successful session I'm back to crashing with the NTDll.dll fault.

 

I need to pin this down, now. I've installed Windbg and dug out the DMP relevant to this.

Whilst I'm no programmer, I can at least make an effort.

 

Well.......The only familiar thing I can find is HDTPhysics64 cropping up.

 

OK, from what I can read of the various numbers displayed all over the place (lol :cool: ) I am seeing this tid-bit of interest:

 

In the Stack view window I have two entries for HDTSSEPhysics

0x14 HDTSSEPhysics + 0x116c4

0x15 HDTSSEPhysics + 0xf32d8

 

And both of these in the @$curstack.Frames panels, under both LocalVariables and Parameters throws up "The scope specified was not found followed by the value. [Parameter value]

 

The gist of what I am seeing is some kind of permissions error?

 

Well. I'll park this here and hope that you, xXxPYR0ST0RMxXx might call back and see if I am at least pinpointing the faulting mod!

 

In hope. Thanks!

[Deleted58783396User]

the issues you want to be looking for will be at this offset: faf49

 

in the call stack look for offsets starting with said offset above, what ever is happening at said offset above, is causing the compiler to crash.

 

disable Hdt Physics and see if the crash continues. debugging it, is only good if you yourself can fix the program. otherwise, the information you are reading, wont help (for the most part).

 

Debugging is mainly for Program Creators to fix their Product. it is not really good information to have for End Users as you would not know how the Program Was Created (you would not have the Source Code, or information on how it is programmed). well techinically it is good information to have, if the cause for the CTD was Client Side, however if the program itself is causing the Crashing, then their will not be much you can do, unless you can fix the program yourself.

 

basically i am saying Debugging can take a very long time. where as simple disabling the program (which only takes a few seconds), should suffice.

 

so it can be hit or miss. i suppose it is good idea to debug programs, but as said you really need to understand exactly what you are reading. Debugging is Proffesional level Problem Solving. which has no simple solution. their can be many reasons why the program is causing the Crash.

 

with that said, i will say,The Cause for this particular CTD is not End User Side, it is the program itself causing the Crashing (however this only applies if said issues you listed are in fact the reason), something End Users Cannot Fix, without having the Source Code to Said Program. so if that is correct, then this issue is down to the Author of HDT, since they failed to Define a Variable, which is apparently causing the Compiler to Crash.

[BlueGunk]

Sadly, I cannot see faf49 (other than a mention in a Dr Watson line) and I don't know where to look for it. :sad:

Here's a screenshot of my Windbg screen on the DMP file. https://postimg.cc/R3bLfHnT

 

I'm navigating in the dark! You see, I can't spot a call stack except for a stack in the bottom-right window.

 

It looks like I may not have the skills to detect where things are going wrong - heck I may not even have the correct items up on my screen!

 

It's probably best you don't waste your time on this.

 

Thanks for your help so far!

[Deleted58783396User]

i will state, that i do not have a lot of expereince in debugging, but i do have expereience in programming (however this was a long time ago), so all the information i am offering, is snippets from a faded memory, as i used to program 15 years ago. and then stopped due to lack of interest, but debugging and programming is connected, however it is very hard to remember perfectly what happened 15 years ago.

 

 

i would highly recommend learning a programming language first (Preferably C++), before jumping into Debugging as that will offer a lot more insight, and would make Debugging much more natural :)

[BlueGunk]

Yes, I agree!

Well, before I go I went back in to WinDBG and looked again at the DMP file and it started to click. Please indulge me one more time because I now believe it is HDTSSEPhysics.dll that's the faulting module.

 

In the debug I got:

 

ADDITIONAL_DEBUG_TEXT: Followup set based on attribute [Heap_Error_Type] from Frame:[0] on thread:[PSEUDO_THREAD] ; Followup set based on attribute [is_ChosenCrashFollowupThread] from Frame:[0] on thread:[PSEUDO_THREAD]

LAST_CONTROL_TRANSFER: from 00007ffc707aaf13 to 00007ffc707aaf49

And I'm guessing (guessing) this is the transfer where the error occurred.

And this is the Stack Table and Frame Index /Name that I copied and pasted into Notepad++

 

 

[0x7] ntdll!RtlDispatchException + 0x40f
[0x8] ntdll!RtlRaiseException + 0x316
[0x9] ntdll!RtlReportFatalFailure + 0x9 <----------------------Attributes 0x7ffc707aaf49 0x7ffc707aaf13 0x187704f100 0x187704f0c0 0x0 1 0x9
[0xa] ntdll!RtlReportCriticalFailure + 0x97 <---------- ---- ---Attributes 0x7ffc707aaf13 0x7ffc707b379e 0x187704f1f0 0x187704f110 0x0 1 0xa
[0xb] ntdll!RtlpHeapHandleError + 0x12 ^^^^^^
[0xc] ntdll!RtlpHpHeapHandleError + 0x7a
[0xd] ntdll!RtlpLogHeapFailure + 0x45
[0xe] ntdll!RtlpHeapFindListLookupEntry + 0x974c7
[0xf] ntdll!RtlpInsertFreeBlock + 0x11d
[0x10] ntdll!RtlpDeCommitFreeBlock + 0x129
[0x11] ntdll!RtlpFreeHeap + 0x991
[0x12] ntdll!RtlFreeHeap + 0x3ee
[0x13] ucrtbase!_free_base + 0x1b
[0x14] hdtSSEPhysics + 0x116c4
[0x15] hdtSSEPhysics + 0xf32d8
[0x16] 0x7ffc00000000
[0x17] 0x3f7259fc00000008
[0x18] 0xc3420e4000000000

 

 

 

And this is why I think hdtSSEPhysics.dll is the faulting module.

 

If I'm an idiot, please tell me so! If I got it right well...I learnt something today.

 

Thank you!

[Deleted58783396User]

its very possible.

 

the 2 other crash dumps i see from 2 different users who both also has HDT physics, both had the exact same offsets listed mentioned (referring to aaf49 and aafa13)

 

so yea. i would say that HDT is indeed the cause for the CTD. it cant be a coincidence that now 3 different crash dumps from 3 different people have the exact same offsets for the crash.

 

i knew this was the case to begin with, but to be fair i am bias against using HDT Physics, simply because i know for a fact this was causing many issues for me and many others back in Oldrim Days.

 

it is still in beta, and is bound to have issues.

 

not too mention that CBP + Ni override exists which literally replaces HDT with a far More Stable out of the box alternative. works absoluty perfect for me

 

unlike hdt, they do not require work arounds, such as back in the day to prevent HDT spamming Magic Effects, via its Cloaks method, somebody created the HDT Physicx Object, to bypass this fatal flaw. but even that was not a sure fire solution. as that in itself would also cause issues.

[BlueGunk]

Agree with you. In Oldrim I had frequent issues with HDT.

 

In Skyrim SE I actually use HDT and CBP-C together (and they work well for me). The earlier SE HDT-SMP files were full of problems, but Hydrogen seems to have a fairly stable issue for Skyrim 1.5.62, which is the set I have had working with CBP-C.

That said there are still glitches, and a few modded items are to be avoided. But it has worked for many hours of play so far.

 

Hopefully s/he will patch the new one. I'll keep an eye on it. Meanwhile I rolled my game back to 1.5.62.

 

As CBP-C develops I hope it will become the main delivery for this sort of thing.

 

Thanks for your help!