Alternatives to OSR Crash Analysis site?

[Seijin8]

Seems that http://www.osronline.com/page.cfm^name=Analyze.htm is no longer usable for crash dump analysis for SKSE minidumps.  Anyone know of alternatives to this site? I've tried a few programs (WhoCrashed, BlueScreenView) that are recommended as alternatives, and these seem unable to read an SKSE minidump.

[GenioMaestro]

10 hours ago, Seijin8 said:

read an SKSE minidump

I not know WHY you want read a SKSE MiniDump. The 99% of the time say C0000005 in TesV.exe and that mean a memory problem solved with the stablity tools.

The only usefull information that you can get form a minidump is what process cause the crask but Windows already say that with the error code. If the crash is in TesV.exe is a memory problem but if the crash is in a dll you can have some clues about what dll have the problem. The rest of the the info is totally unusefull because you not have the source code and i presume you not understand assembler and you not know how view the content of the memory with the address of the crash.

 

But maybe you are a powerfull developer in assembler and for view the minidump you can use WinDbg that show exactly the same information showed in OSR because it is only an interface for upload the minidump, execute WinDbg and show the result.

But i alert you. WinDbg is not a easy use tool. Is included in Windows SDK and is intended for use with WDK. Is a very powerfull tool used by people developing Drivers for Windows and you can debug the Kernel of windows with WinDbg. The tools only show a window in text mod and you must write commands like as you are in a CMD prompt. You can see the detailed instructions here.

 

For me is much more easy download and install the FREE Visual Studio 2017 and activate the Just In Time Debuger because you can launch the debuger in each crash, not need load the minidump, and you can view much more info like the call stacks, the dll's calls, the memory map... You can see the same info with WinDbg typping commands. Of course you must be a very advanded developer and you must have a high knowledge about debuging.

[Seijin8]

16 hours ago, GenioMaestro said:

I not know WHY you want read a SKSE MiniDump. The 99% of the time say C0000005 in TesV.exe and that mean a memory problem solved with the stablity tools.

 

Not remotely 99% of the time.  Maybe 5% of the time.

 

"c0000005" in my experience is usually the result of a a bad package process call, often a result of modding with xEdit, or of mods forcing packages active through script instead of through conditions and alias package stacks.  The suspect process when loaded into the CK reads <unknown> in the package's process tree, and is usually easily remedied if you know what to look for (determining which package went active at what time is usually the tough part).

 

I am not an advanced developer, but I have created an extensive log file of what codes happen and when and what the usual suspect is (if I've ever located one).  It can notify me of a broken or overlapped navmesh, bad process, or simple memory overloads.  Knowing the failed process gives me an idea where to look, or which mod is likely causing the issue, and whether or not it is something I can fix.

 

That one bit of info is all I really need from the dmp file.

[Seijin8]

17 hours ago, GenioMaestro said:

For me is much more easy download and install the FREE Visual Studio 2017 and activate the Just In Time Debuger because you can launch the debuger in each crash, not need load the minidump, and you can view much more info like the call stacks, the dll's calls, the memory map... You can see the same info with WinDbg typping commands. Of course you must be a very advanded developer and you must have a high knowledge about debuging.

And by the way, thank you for that link, this is providing what I needed.  Much appreciated.

[GenioMaestro]

8 hours ago, Seijin8 said:

"c0000005" in my experience is usually the result of a a bad package process call, often a result of modding with xEdit, or of mods forcing packages active through script instead of through conditions and alias package stacks.  The suspect process when loaded into the CK reads <unknown> in the package's process tree, and is usually easily remedied if you know what to look for (determining which package went active at what time is usually the tough part).

The error code that you can get is DIFERENT depending of WHAT utilities you have installed.

 

You can have a DIFERENT error code in TesV.exe depending of if you install Crash Fixes or not. The error code can be DIFERENT if you have SKSE Memory patch or not and can be DIFERENT depending of if you have HDT or not and can be diferent if you have SKSE or not.

But the problems not end here because you can have a DIFERENT error code in TesV.exe depending of what parameters you have inside the INI files of the utilities. For example, change some parameters in crashfix.ini generate diferent errors codes and changing some parameters in nioverride.ini can generate a diferent code and dependding of what parameters you have inside skyrim.ini and inside skyrimpref.ini you can have a diferent code.

For complex the things a bit more, change the graphical resolution of the game or play it in windowed mode or in full screen can give a diferent error code in TesV.exe and finally, depending of your ENB configuration you can get diferent codes.

 

And I am ALWAYS referring to the same CTD caused by the same motive.
Sometimes the error code can be maintained and sometimes it can change. And that depends on how the memory is handled.
For a simple error such as "invalid skeleton" you can have the same or different error code depending on how that npc with the invalid skeleton is generated and depending on the operations that are performed on it.
It is even possible that the CTD is eliminated by disabling a mod that makes a NiOverride modification on that npc with the invalid skeleton and can disapear if you remove the HDT armor.
Because sometimes the error can jump when HDT or NiOverride tries to move the mesh, while other times it can jump when the game tries to execute an animation, and of course generate diferent error codes.

 

 

 

The 90% of the CTD has been analiced and controled by Crash Fixes and automatically solve a lot of them. Take a look to the CrashFix.ini because is very detailled. And take a very good note about HOW crash fixes control and manage the errors. For example, i put some lines here for you:

Spoiler

; Info: Crash happens unknown constructor (TESObjectLAND::unk_24 object)

; Info: Game crashes when strcmp is passed NULL char*
; Address: D573A8
; Cause: Most frequently happens in TthkbClipGenerator::activate (0xBF2FB3),

; Info: Game crashes when strlen is used on NULL char*
; Address: 46EDF0
; Cause: NiNode names are compared, one of the NiNode's name is NULL.

; Info: Unknown, reported as loading save game.
; Address: 8B437C - vtable seems to be 0 or wrong pointer is used.
; Solution: Skip since this is the last part of the function and already has a check anyway

 

As you can see, when the memory address is EXACTLY the same you can have some waranty about that the problem can be the same but that is not enougth and Crash Fixes must verify the TYPE of object and the function and sometimes the code of the object. All of them can give a waranty about the same problem and posible solution. And the creator of Crash Fixes made that in pure asembler.

 

Crash Fixes can made that because force you to configure the game in a concrete and exact way that waranty that you ALWAYS have the same addres when you have the same problem.

 

Crash Fixes force you to install SKSE and SKSE Memory Path and force you to change some parameters in enblocal.ini and force you to make some adjust in skyrim.ini and skyrimpref.ini and that changes WARRANTY that you can have the same memory movement.

 

When Crash Fixes detect a problem in a EXACT memory addres can solve it because Crash Fixes KNOW that, when the crash are caused in THAT memory addres with THAT configuration in the ini files and whit THAT utilities instaled and configured in THAT way, can apply the solution that they found for solve the problem after work a lot of months in Crash Fixes.

 

 

For all the motives that i explain here we have a post called How to debug CTD with 48 pages and the 99% of the messages not have solution. Because the game NOT generate the SAME error code. Because the CODE and the ADDRESS can be diferent depending of the game configuration, the utilities installed, the utils configurations, the mods installed... Each user have a DIFERENT game with diferent configuration that can generate diferent errors with diferent address in the same situations.

 

The 99% of the times the dump info is totally unusefull because say a error code that is not warranticed and give a memory address that is not warranticed.

If the CTD is caused by a mod the problem is of the mod. Talk to the developer of the mod for solve it.

If you make a bad merge is your problem. Learn to make it good.

If you have CTD probably is caused because you have your game bad configured.

But the 99% of the times you can not know the cause of the CTD based in the dump info. You only can made that when you have the source code or when you are a very expert developer in assembler as the creator of Crash Fixes.