Crash Offsets

<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))

Anyone know what 000c458f in content.dll is?

Yep - 8B!

=Alex= wrote:
Anyone know what 000c458f in content.dll is?

In my case it was patrol_path related(wrong encounter). so seems like encounters.

Actually if i see this offset i know that I’ll have to look through encounters once more, especially patrols(map and encounter-related files).
For example encounter is not listed in system .ini file or encounter.ini has some problems(not-existent shipclass etc.)

About 000c458f in content.dll

I have found on my local machine that if solar have wrong destructible archetype (NewArk for example is fuchu_core with hit_pts = 0 - different from client and server in my case) and player taken off from nearest base of this archetype (Manhattan)- server crashes instantly!

So the prob in an destructible archetype somewhere near player trying to take off.

P.S. It is about server-side on our Dod

Next researh:

also 000c458f error arises when nearby stations (within a zone? Vitaly?) are reputed not coinciding with reputation on the client-side.

But if to change reputation only one station on a server - all works

P.S. edx = 0 when debugger reach this offset (usually edx =1), may be there is workaround to prevent this register set to null?