Crash Offsets

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?

engbase.dll, 1.11.0.173, 000124bd

I need to track this one down if possible, this is the only one that shows up on the server.

@Nightstalker: That function already tests if its input is 0 or -1, so you must have a major bug if it’s failing. Unfortunately, all I can tell you is that it’s called (at least) from GetRoot and IsDescendant.

@Helloween: EAX is the index; EDX is the base and the reason for the crash. It creates a list of items (not sure what, possibly ship types), but it expects at least one item; the crash occurs when there are no items. Here’s a patch that seems to work: content.dll, 0C456A, 07->2A. Of course, that just hides the problem, it doesn’t fix it.