Jump to content

HDT Crash ExceptionAddress hdtPhysicsExtensions


Guest

Recommended Posts

Guys is there a way to prevent HDT crashes?


 


I'm getting some CTDs caused by the hdtPhysicsExtensions


 


EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)

ExceptionAddress: 5acae2ec (hdtPhysicsExtensions+0x0015e2ec)

 

Those are from the SKSE\Crashdumps dump files ;(

Link to comment
  • 3 weeks later...

 

Guys is there a way to prevent HDT crashes?

 

I'm getting some CTDs caused by the hdtPhysicsExtensions

 

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 5acae2ec (hdtPhysicsExtensions+0x0015e2ec)
 
Those are from the SKSE\Crashdumps dump files ;(

 

 

I am as well. Perhaps we can compare HDT mods to try and pinpoint the cause.

 

I am using

HDT Physics Extension

HDT Sitting Height Fix

SAM - HDT BBB Bounce v1.2

HDT Floppy SOS

 

For me it happens in only a couple of cases.

1. Game Load, this one happens about 35% of the time. I can get around it by trying again.

2. When followers are teleported to me from a distance, this one occurs far less often.

 

As far as I know all my HDT mods are compatible and up to date. I am super confused.

Link to comment

snip-

 

 

Here are the HDT Stuff I'm using:

 

HDT Physics Extension

Floppy SOS - Light version (NPC floppy but no support for loverslab stuff)

HDT Tails Wearable

HDT Earrings

HDT Arm Straps

HDT KS Hairs

HDT Equipment

HDT Bounce and Jiggles - TBBP - Reduced 7.8

 

I manage to reduce a lot of HDT-PE crashes with 2 changes:

(Could be a placebo effect)

 

I changed the hdtPhysicsExtensions.ini file:

numThreads = 5

 

Replaced the skeleton of all follower mods I had to XPMSE

Most follower mods add old and obsolete skeletons not HDTPE compatible.

 

So far CTDs have reduced a lot ;)

Link to comment

I am lost, I have no idea what is causing my CTDs with HTD.

 

When I get a CTD it shows

hdtPhysicsExtensions+0x0000a5cb

which is odd because a5cB is a landscape in Skyrim.esm, to add to the confusion this is happening while I am in Falskaar. o.O

 

I am so confused as to what might be causing this.

I am beginning to think I am just hitting the memory limit but if that were the case would I really be getting this error?

 

I am curious what setting the numThreads = 5 does ?

 

Link to comment
  • 1 year later...

Sorry for necropost. It is just for additional info. Sometime I also have same crash on savegame load and it happens with next conditions:

--installed crash fixed, loaded with preload, in crashfixes CrashFixPlugin.ini parameter UseOSAllocators set to 1;

--game was saved when player has equipped one or more parts of clothes with HDT-PE physx.

 

It happens only sometime. Also in same conditions after save loaded all parts of equipped clothes usually freezed while player reequipped them.

My mod configuration working mostlly stable only when UseOSAllocators=1 and only rare crashes on save load is what I notices when started to play game with UseOSAllocators=1(and ofcourse other possible problems which already described in crash fixes documentation like crash if select many hairs for main char in racemenu) but on my opinion it much better of standard larged memory blocks (atleast in my very heavy configuration with many mods and several big dynamic patches). With larger memory blocks my game just crash after some little time and I see slow work of perks menu. 

I suppose it is kind compatibily problems of HDT-PE with UseOSAllocators=1 mode from Crash fixes. Still not found solution and it would be very good if somethere will be something like fixed hdtPhysicsExtensions.dll (or sometimes I will learn assembler and will understand how to fix it :)).

 

 

Latest text from crashdump if it will be interested for someone:

Spoiler

Crash Dump Analysis provided by OSR Open Systems Resources, Inc. (http://www.osr.com)
Online Crash Dump Analysis Service
See http://www.osronline.com for more information
Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
kernel32.dll version: 6.1.7601.24214 (win7sp1_ldr_escrow.180801-1700)
Machine Name:
Debug session time: Fri Sep 28 13:27:41.000 2018 (UTC - 4:00)
System Uptime: not available
Process Uptime: 0 days 0:01:04.000
  Kernel time: 0 days 0:00:25.000
  User time: 0 days 0:01:01.000
TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\oca.ini, error 2
TRIAGER: Could not open triage file : e:\dump_analysis\program\winxp\triage.ini, error 2
TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\user.ini, error 2
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

*** WARNING: Unable to verify timestamp for SKYRIM.exe
*** ERROR: Module load completed but symbols could not be loaded for SKYRIM.exe
TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\guids.ini, error 2
*** WARNING: Unable to verify timestamp for ToggleWalkRunFix.dll
*** ERROR: Module load completed but symbols could not be loaded for ToggleWalkRunFix.dll
*** WARNING: Unable to verify timestamp for hdtHighHeelNative.dll
*** ERROR: Module load completed but symbols could not be loaded for hdtHighHeelNative.dll
*** WARNING: Unable to verify timestamp for JContainers.dll
*** ERROR: Module load completed but symbols could not be loaded for JContainers.dll
*** WARNING: Unable to verify timestamp for XAudio2_6.dll
*** WARNING: Unable to verify timestamp for atiumdag.dll
*** ERROR: Module load completed but symbols could not be loaded for atiumdag.dll
TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2
GetUrlPageData2 (WinHttp) failed: 12029.

FAULTING_IP: 
hdtPhysicsExtensions+15e2ec
6a2ae2ec 8b482c          mov     ecx,dword ptr [eax+2Ch]

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 6a2ae2ec (hdtPhysicsExtensions+0x0015e2ec)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 0000002c
Attempt to read from address 0000002c

PROCESS_NAME:  SKYRIM.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  0000002c

READ_ADDRESS:  0000002c 

FOLLOWUP_IP: 
hdtPhysicsExtensions+15e2ec
6a2ae2ec 8b482c          mov     ecx,dword ptr [eax+2Ch]

FAULTING_THREAD:  00000f30

BUGCHECK_STR:  APPLICATION_FAULT_NULL_CLASS_PTR_READ_AFTER_CALL

PRIMARY_PROBLEM_CLASS:  NULL_CLASS_PTR_READ_AFTER_CALL

DEFAULT_BUCKET_ID:  NULL_CLASS_PTR_READ_AFTER_CALL

LAST_CONTROL_TRANSFER:  from 6a151dcb to 6a2ae2ec

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
3333fe74 6a151dcb 78ebc358 3333fea8 6a15283d hdtPhysicsExtensions+0x15e2ec
3333fe80 6a15283d 00000001 6a15fa61 0da62800 hdtPhysicsExtensions+0x1dcb
3333fea8 6a15512e 3333fed0 78ebc898 78ebc898 hdtPhysicsExtensions+0x283d
3333fee8 6a1568fd 5c015eb0 3333ff1c 6a15ccbd hdtPhysicsExtensions+0x512e
3333fef4 6a15ccbd 3333ff10 4d635280 00000002 hdtPhysicsExtensions+0x68fd
3333ff1c 0045f619 4d9b0748 3333ff94 4d9b0700 hdtPhysicsExtensions+0xccbd
3333ff88 74d3343d 32c58590 3333ffd4 77399832 SKYRIM+0x5f619
3333ff94 77399832 32c58590 54da6fe3 00000000 kernel32!BaseThreadInitThunk+0xe
3333ffd4 77399805 00a4b4a0 32c58590 00000000 ntdll!__RtlUserThreadStart+0x70
3333ffec 00000000 00a4b4a0 32c58590 00000000 ntdll!_RtlUserThreadStart+0x1b


SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  hdtPhysicsExtensions+15e2ec

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: hdtPhysicsExtensions

IMAGE_NAME:  hdtPhysicsExtensions.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  53108655

STACK_COMMAND:  ~32s; .ecxr ; kb

FAILURE_BUCKET_ID:  NULL_CLASS_PTR_READ_AFTER_CALL_c0000005_hdtPhysicsExtensions.dll!Unknown

BUCKET_ID:  APPLICATION_FAULT_NULL_CLASS_PTR_READ_AFTER_CALL_hdtPhysicsExtensions+15e2ec

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/SKYRIM_exe/1_9_32_0/51437ce5/hdtPhysicsExtensions_dll/0_0_0_0/53108655/c0000005/0015e2ec.htm?Retriage=1

Followup: MachineOwner
---------

 

Link to comment
  • 3 weeks later...

In my case it happens(ctd with hdtpe dll) with any variants. Ofcourse all things fully updated(OS, drivers, soft, game, skse plugins, mods) with never possible versions and was used all possible variants of xml and ini options. No any problems( like ass jiggling) with hdt body but only with cloth parts with physix and only in conditions which was described. My heavy modded game with tons of scripted mods working very good because I fixed thousands errors in installed esps and scripts and in most cases I just using exit button from game to exit. And this problem is still exist and sometime happens in described conditions and I cant find fix for it. It will be good if you can recommend which specific configurations and ini options I can try but I suppose I already tried them. Anyway they(ctds righ after game loaded with equipped physix cloth) happens quite rare and it is not so problem like it seems but it is interested to know more about this and find options which can at least reduce it(UseOSAllocators=0 can fix it but it is not a good variant for heavy modded game).

Link to comment
8 hours ago, Tkc said:

working very good

Crash dump says rather otherwise.

 

One of the ingrained issues with PE is if your proc stalls on scripts or the custom race bug, pe or havok or both will straight up fail. Given that PE can't find the cache it's supposed to, it's either not there or your configuration [PE memcache, CFix, ENB] is incorrect.

Link to comment
On 10/19/2018 at 7:41 AM, 27X said:

Crash dump says rather otherwise.

Dump says only about this ctd and only about this problem, not about overall game stability at all.

 

I already talked several times about conditionals only with which it happens but will repeat another time with additional details and screens:

1. It ONLY happens when parameter UseOSAllocators=1 in Crash Fixes ini.

2. It ONLY can happen if was made savegame with equipped cloth parts with hdt physics like "HDT test skirt mod" or HDT wigs.

3. UseOSAllocators=1 causes hdt cloth freeze or stretch when savegame was just loaded and some other item was equipped. After game only loaded it can happen when some mod script automatically equipped something. Freezes\stretches will be fixed when freezed\stretched hdt cloth will be reequipped. Freeze\stretch can be repeaded in some situation lately as I think if was changed location or in something kind of conditions.

3. It is not happen with HDT body\boobs\butt or even with HDT hairs. This parts working as intended and not freezing\stretching or not causing ctd on load.

4. With UseOSAllocators=0 all is working as intended with no any promlems.

 

Here screens with added description which I made:

1. UseOSAllocators=1. Game was only loaded. Mostly it is like vanilla game with several HD texture replacers and couple UI mods. Also installed and equipped Dints Nier Automata Dress HDTPE conversion(HDTPE skirt, HDTPE sleeves on dress, HDTPE wig), HDTPE earrings and HDTPE cloak(Nier boots not equipped). It is place from Alternative Start scenario start "I live in forest" with standart breton race - https://www.dropbox.com/s/uidgkbwvji33ilc/HDTclothfreeze 2018_10_20 10_11_07_63.jpg

2. Screenshot where was equipped boots and HDTPE cloth parts become freezed. Place of player changed to demonstrate cloth freeze. Player was on place of hdtpe parts freeze when boots was equipped - https://www.dropbox.com/s/qd680wff94augna/HDTclothfreeze 2018_10_20 10_16_34_92.jpg

3. Other situation when game was just loaded but instead of boots was reequipped dress and all hdtpe parts was stretched to some other place - https://www.dropbox.com/s/9gekjqwfoi3od17/HDTclothfreeze enb 2018_10_20 10_10_40_24.jpg

3.1 Place in which was stretched hdtpe clothes. It is made in TFC mode on not loaded locations anly only lods on the screen - https://www.dropbox.com/s/srg570tvlzrf3tj/HDTclothfreeze 2018_10_20 10_10_28_60.jpg

 

It happens only with UseOSAllocators=1 and cant be repeatable with UseOSAllocators=0. Same settings and xmls working without any problems with UseOSAllocators=0. And ofcourse with UseOSAllocators=0 no any(even rare) ctd after game loaded. I will repeat I tried tons of variant of setting and xmls from many sites on several completely different mod configurations and only thing which I found it is UseOSAllocators=1. As I talked I still plaing with UseOSAllocators=1 because long play time on very heavy modded game possible only with this enabled parameter. With standart two buffers some game situations with many npcs and magic effects will devour all 32bitSkyrim process memory and game just will crash. Rare crash on load or single hdtpe cloth stretch it is not a big deal for me but it is just very interested(matter of principle) to find find the cause and fix for this.

You talked about memory cache and UseOSAllocators=1 is changing memory using by game and maybe this is have effect on hdtpe dll. I suppose only Hydrogensays would say something about this but I doubt if it is possible to find this autor.

Link to comment
  • 1 year later...

I am working on a fix for the hdtPhysicsExtensions.dll+0x15E2EC; In my case it only happens at the very first load (right after it's finished loading) and it's arbitrary.

This is the only consistent crash I've in my game.

 

The crash happens at mov ecx,[eax+2C]

It happens because the EAX register is NULL (0) while the instruction ends up trying to dereference the address 0x0000002C (invalid).

EAX is NULL because the function that just wrote to EAX ( https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-tlsgetvalue ) returns NULL on failure and HDT PE does not check for that.

eax = TlsGetValue(0x2F);
ecx = *(eax + 0x2C);

The fix I've figured out is to return from the function right away if TlsGetValue returns a NULL pointer.

I've made it return every time at that instruction, even if it returned a valid pointer and it didn't seem to break anything. Game didn't crash or bug out and HDT still worked on both males and females.

Link to comment

The crash is caused by a race condition between HDT PE and something else. If HDT PE executes that instruction before the thread slot value at index 0x2F is set, TlsGetValue will return 0, which HDT PE will not check for and thus crash your game by accessing an invalid memory address when dereferencing EAX.

I am quite surprised so few have this crash when loading a game, considering the nature of this race condition.

I'll be making a plugin to have the thread continue a loop if TlsGetValue returns 0 as to allow the value to be set before HDT PE can continue.

Link to comment

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use