Crash Offsets

Ah edx. thx.
I will try the fix at home

It only fails intermittently (No pattern that I can find, ranges from once every two weeks or can go a month or more sometimes), usually in intense NPC combat or PVP. GetRoot and IsDescendant, does this refer to sur files??

Adoxa you are master of Freelancer reveЯce engenееring, thx - all NY now under the Wilds control at my local machine

00010dea, common.dll?

-1<–—
06310DE1 mov edx, [eax+01h]
06310DE4 add edx, [ebx+00001450h]
06310DEA jmp 06310E31h
-1<–—
…

• Reference to USER32.MessageBoxA
  …
  06310E31 test esi, esi
  06310E33 jle 06310E4Fh

brrr if esi<=esi then jump?

@Nightstalker: I sympathize, such intermittent bugs are hard to track down. GetRoot accepts a CObject* and returns a CObject* (presumably a parent relationship). IsDescendant takes two longs (presumably hashes) and returns bool (the first object is a descendant of the second).

@Alex: Looks like you have a good without an equipment line.

@Helloween: Sorry, you’re way off, you want 6270DEA (6260000+10DEA).

Edit: test reg,reg/jle is actually if (reg <= 0).

Why sorry? I trying to learn

Thx, will take a note.

drops assembler reference from window

TEST is an AND that discards the result. ANDing something with itself yields itself, but affects the flags. It is commonly used as a short way to test for zero, but it can also test for negative numbers, when the high bit is set. So test reg,reg preserves reg, clears the carry flag and sets the zero and sign flags accordingly.

Reading old paper tutorials, but without good reference hard to understand…

What assembler reference you will recommend?

I use these two:
Intel Architecture Software Developer’s Manual - google it, 3 pdfs.
http://faydoc.tripod.com/cpu/

oh, there’s actually third in my bookmarks: http://ref.x86asm.net/

Thx again, server much stable x)

server.dll, 0076fdf

?get_behavior_id@IObjInspectImpl@@UBEHXZ

Wrong behaviour? Right?

Um, yeah. That address is part of a function at 06D56FD0 (ie. server.dll has a base address of 0x6CE0000, add 0x76FDF and backtrack). Tracing it through the disassembly, it seems to be used when loading a player.

So perhaps it’s a corrupt character? Non-latinic name or something?

It seemed we have corrected all errors, but now happens only

ntdll.dll, 00011689

Os error?

Debug shows

[23.07.2010 12:12:53] void __stdcall HkIServerImpl::BaseEnter(unsigned int,unsigned int)
[23.07.2010 12:12:53] iBaseID: 2805853963
[23.07.2010 12:12:53] iClientID: 4

I have a problem to get more information ;(
I have a crash at 0x0004f486 in common.dll that appears very often. With a dll viewer the address should be somewhere between:

protected: virtual __thiscall CObject::~CObject(void) 0x062af440 0x0004f440 565 (0x235) Common.dll D:\Games\Freelancer\EXE\Common.dll Exported Function

and

public: unsigned int __thiscall CObject::AddRef(void) 0x062af600 0x0004f600 1197 (0x4ad) Common.dll D:\Games\Freelancer\EXE\Common.dll Exported Function

Am i on the right was assuming that it must be somewhere either in destroying an object or adding a reference (whatever ref is meant with it)? Because that are the addresses situated next to the crash offset.

Is there a way to get to the direct address that is crashing? Windbg? Any other tool?

Related to ntdll.dll - not supported/equipable archetype in players char file.

Use Player Cleaner or DSAccount manager with all check options on.

@Huor: At least in XP, the crash report itself should give you the address. Here’s one I prepared earlier… But you’ve got the right address, anyway, it’s part of the destructor.

Is there any possibility to get a kind of callstack of a current happended crash? It would be nice if its logged somewhere in a file… I have tried to debug a crash offset (by using breakpoints) but the routine is way too much called to trigger any crash reason ;(

So actually when the crash happens and having the callstack would be a really great…

Finally ntdll.dll crashes - Not supported parameter or typing error

@Huor try WinAPIOverride32