Crash in dacom…

Huor

Ahoy, i am trying to figure out a crash thats happening quite often in the dacom and i have no idea how i can find out about the reaon, hence i am posting here. Maybe someone from you has an idea.

This is the crash data:

FAULTING_IP: 
dacom!stricmp+c
065b5e6c 0fb60e          movzx   ecx,byte ptr [esi]

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 065b5e6c (dacom!stricmp+0x0000000c)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 0a0f18e4
Attempt to read from address 0a0f18e4

DEFAULT_BUCKET_ID:  INVALID_POINTER_READ

PROCESS_NAME:  flserver.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  0a0f18e4

READ_ADDRESS:  0a0f18e4 

FOLLOWUP_IP: 
dacom!stricmp+c
065b5e6c 0fb60e          movzx   ecx,byte ptr [esi]

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

APP:  flserver.exe

FAULTING_THREAD:  00000ef4

PRIMARY_PROBLEM_CLASS:  INVALID_POINTER_READ

BUGCHECK_STR:  APPLICATION_FAULT_INVALID_POINTER_READ

LAST_CONTROL_TRANSFER:  from 062df4fb to 065b5e6c

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
0464823c 062df4fb 0a0f2010 0a0f18e4 ffffffff dacom!stricmp+0xc
00000000 00000000 00000000 00000000 00000000 Common!pub::StateGraph::get_state_graph+0x3b

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  dacom!stricmp+c

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: dacom

IMAGE_NAME:  dacom.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  3e401cd3

STACK_COMMAND:  ~29s; .ecxr ; kb

FAILURE_BUCKET_ID:  INVALID_POINTER_READ_c0000005_dacom.dll!stricmp

BUCKET_ID:  APPLICATION_FAULT_INVALID_POINTER_READ_dacom!stricmp+c

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/flserver_exe/1_0_1256_11/3ecbb13e/dacom_dll/1_11_0_173/3e401cd3/c0000005/00005e6c.htm?Retriage=1

Followup: MachineOwner
---------

0:029> .ecxr
eax=0000004e ebx=fffff8dc ecx=0a0f18e4 edx=0a0f2010 esi=0a0f18e4 edi=00000000
eip=065b5e6c esp=0464823c ebp=065b5e60 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
dacom!stricmp+0xc:
065b5e6c 0fb60e          movzx   ecx,byte ptr [esi]         ds:002b:0a0f18e4=??

The stricmp compares NOTHING (which is at address 0a0f2010) with something and i cannot find out with what and why its not accessible. When i look at the disassembly for the last transfer this gives the following:

062df4d9 69c02c070000    imul    eax,eax,72Ch
062df4df 8d5808          lea     ebx,[eax+8]
062df4e2 a11cca3f06      mov     eax,dword ptr [Common!FuseDB::m_FuseINIFiles+0x558 (063fca1c)]
062df4e7 33f6            xor     esi,esi
062df4e9 8da42400000000  lea     esp,[esp]
062df4f0 8d0c03          lea     ecx,[ebx+eax]
062df4f3 51              push    ecx
062df4f4 8d540608        lea     edx,[esi+eax+8]
062df4f8 52              push    edx
062df4f9 ffd5            call    ebp
062df4fb 83c408          add     esp,8 <<<<<< address of last transfer
062df4fe 85c0            test    eax,eax
062df500 a11cca3f06      mov     eax,dword ptr [Common!FuseDB::m_FuseINIFiles+0x558 (063fca1c)]
062df505 750a            jne     Common!pub::StateGraph::get_state_graph+0x51 (062df511)
062df507 8b4c2418        mov     ecx,dword ptr [esp+18h]
062df50b 394c0604        cmp     dword ptr [esi+eax+4],ecx
062df50f 7419            je      Common!pub::StateGraph::get_state_graph+0x6a (062df52a)
062df511 8b0d18ca3f06    mov     ecx,dword ptr [Common!FuseDB::m_FuseINIFiles+0x554 (063fca18)]
062df517 47              inc     edi
062df518 81c62c070000    add     esi,72Ch

So “NOTHING” is only contained in some mission files, as state_graph but i dont see why this is used here. And i have no idea where to start looking for an error, in zones, npcs, missions, fuses.

I am even not sure how i could avoid that crash with a server patch. So any info you might throw in is very much appreciated. If you need any more info i could contribute, dont hesitate to ask me.

Thanks in advance.

w0dk4

Just a shot in the dark, but I think many objects actually require a “behavior = NOTHING” entry to function properly as regards their AI.

adoxa

Looks to do with formations - that particular [c]get_state_graph[/c] is called on entering/leaving a formation (verify by looking at [c][esp+0x1c][/c] - the return address from [c]get_state_graph[/c] - which should be either xxxx7244 or xxxx7289 in Content.dll).

Huor

OK, thanks, i will look for an error in our formation definitions. Thanks for the hints. If not i need to get deeper into debugging and set breakpoints at some addresses. Maybe i could track which of the formations is corrupt.