Crash Offsets

000078d3 - called as part of pub::SpaceObj::Dock - This is fixed in flhook plugin 1.6.1 by wrapping the call in an exception handler. This works well enough.

There are a few dirty hacks in CrashCatcher.cpp in the player control plugin that wrap exception handlers around a few common crash point (on discovery anyway).

I have crashes at server.dll 0002247f dunno what does this mean…

06D02465 6800000200          	push	00020000
06D0246A 8D88E4000000        	lea	ecx, [eax+E4]
06D02470 FF152440D606        	call	[Common.?FindFirst@CEquipManager@@QAEPAVCEquip@@I@Z]
06D02476 50                  	push	eax
06D02477 FF15E445D606        	call	[Common.?cast@CEEngine@@SAPAV1@PAVCEquip@@@Z]
06D0247D 8BF8                	mov	edi, eax
06D0247F 8A4754              	mov	al, [edi+54]

// C++ pseudocode
CEquip* equip = CEquipManager::FindFirst( 0x20000 );
CEEngine* engine = CEEngine::cast( equip );
bool cruise = engine->cruise; // crashes here

```So, at a guess, it's trying to activate cruise on a ship that has no engine.

Thanks!

Pfff…

0000: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 46 61 69 6c ion Fail
0010: 75 72 65 20 20 66 6c 73 ure fls
0018: 65 72 76 65 72 2e 65 78 erver.ex
0020: 65 20 34 2e 38 35 2e 33 e 4.85.3
0028: 2e 32 20 69 6e 20 6e 74 .2 in nt
0030: 64 6c 6c 2e 64 6c 6c 20 dll.dll
0038: 35 2e 31 2e 32 36 30 30 5.1.2600
0040: 2e 35 37 35 35 20 61 74 .5755 at
0048: 20 6f 66 66 73 65 74 20 offset
0050: 30 30 30 31 31 36 38 39 00011689
0058: 0d 0a …

Looks like something wrong with os/hardware?

<version>, <error dll=“”>, <dll version=“”>, <crash offset=“”>.
4.85.3.2, engbase.dll, 1.11.0.173, 0000b8ae.

Anyone know anything about this one? Aparently it’s happening when someone tries to load a character.

EDIT: After the VersionNumber and ProductNumber were changed in engbase.dll, it seems to have been fixed. (Which is odd, because I can run FLServer fine with the original file.)</crash></dll></error></version>

Help please… i’m in desperation…
Freel server (mod) crashes when jumping inside Kepler system…
000c465f in content.dll

I wonder, can this be used to point out why a server crashes? Sounds like a stupid question, but my issue this. I have created a new ship, but the server and game both crash as I try to undock. Will this point me in a direction to look?

Oh, and FF, I love that sig LOL

ZetaPirate wrote:
I have created a new ship, but the server and game both crash as I try to undock. Will this point me in a direction to look?

Trouble may presist in wrong-built sur of the ship, or something wrong in goods.ini

w0dk4 wrote:

0xc458f - very frequent, could be NPC-related

This is related to multiple players/ships suiciding at the same moment into a planet/death zone. At least we could reproduce it that way on Hamburg City.

What did you return in case of an exception (assuming you did surround it with try…catch)?

We dont catch that exception.

Alright, I first tried try/catch (mixed up the return value with another function, for this one the result is never used), but it turned out that there already are exceptions used, since the catch block got executed very often. I now patch directly the part where it crashes and check whether edx is zero. In case it is, I set eax and also ecx+2Ch to zero. Since I could reproduce the bug I could test that this fixes the crash.

Cool, thanks!

Anyone an idea about crash offset 0x00103141 in common.dll?

I tried looking for that offset but found no appropriate function. next to that is only public:

virtual enum Archetype::AClassType __thiscall Archetype::EqObj::get_class_type(void)const 0x063624b0 0x001024b0 2680 (0xa78) Common.dll

or this:

public: virtual enum HpAttachmentType __thiscall Archetype::Commodity::get_hp_type(void)const 0x063624b0 0x001024b0 2788 (0xae4) Common.dll

but they are not at 0x00103141 ;( So the crash seems to have happened +C91h from this.

Tracing it back through the debugger, one time it’s called is through PhySys::PhyCollisionStateManager::enable_collisions.

000603d6 common.dll?
And i see 000c458f in content.dll ;(

603d6 in common.dll is from IObjInspectImpl::is_targetable - looks like it’s targetted something it shouldn’t have.

Thx Adoxa! Are you using ollydbg?

I am, but in this case, searching a disassembly from a customised PeRdr was enough. Names are demangled using my own program (based on the API function), executed through the editor (TDE).

Ah, i am not familiar with programming but have checked #10 by ollydbg, it shows the same x))