Crash Offsets
-
adoxa wrote:
Here’s a new plugin for the content 124bd problem. This one only logs on a bad address (also eliminating the crash), so you should have no problem on a running server. It will generate EXE\EngBase-0124BD-bad.txt, logging the values of the previous call.2011-06-30 02:29:37.481: Common.0630E681
Bad address = CDCDCDCD
Previous call:
cmp -> equipment\models\weapons\ku_hornet_launcher.cmp
part -> k_hornetlauncher_base_lod1020829120522.3db2011-06-30 02:45:49.832: Common.0630E681
Bad address = CDCDCDCD
Previous call:
part -> equipment\models\torpedoes\ge_torpedo.3db2011-06-30 21:56:49.318: Common.0630E681
Bad address = CDCDCDCD
Previous call:
cmp -> equipment\models\turret\li_turret03.cmp
part -> base021119202809.3db2011-07-01 21:59:10.152: Common.0630E681
Bad address = CDCDCDCD
Previous call:
cmp -> equipment\models\weapons\ku_hornet_launcher.cmp
part -> k_hornetlauncher_base_lod1020829120522.3db2011-07-02 01:51:27.616: Common.0630E681
Bad address = CDCDCDCD
Previous call:
cmp -> equipment\models\turret\ku_turret04.cmp
part -> base021119202046.3dbGot crashes - where to dig?
-
adoxa wrote:
Wasn’t this resolved to the lack of hardpoints (hpid) in the sur?I dunno about it, aby prooflink?
-
I get Crash at Fault offset: 0x00021117 in Common.DLL
it is appeared here:
.text:06281105 loc_6281105: ; CODE XREF: DamageList::operator=(DamageList const &)+91j .text:06281105 mov [eax+4], edi .text:06281108 mov [esi+4], eax .text:0628110B mov edx, [eax+4] .text:0628110E mov [edx], eax .text:06281110 add eax, 8 .text:06281113 test eax, eax .text:06281115 jz short loc_6281128 .text:06281117 mov ecx, [ebx+8] ; <-here .text:0628111A mov [eax], ecx .text:0628111C mov edx, [ebx+0Ch] .text:0628111F mov [eax+4], edx .text:06281122 mov ecx, [ebx+10h] .text:06281125 mov [eax+8], ecx
Whats wrong may be?
-
Crashes detected by me or our server:
content.dll
000db0f1 - bad patrol(i think)
0009100f - bad tradelane(i think)
0009566d - bad tradelane(i think)
000d8e14
00016bb3
000ab23d
000d8e14
00013bb3freelancer.exe
0013d13a
0013b395
001545f7
00006100- bad wireframe(Adoxa)remoteserver.dll
00012460common.dll
0010960c
0005be63 - non existing exclusion zone, but is called in asteroid/nebuda file - look to FlSpew.txt for zone nickname
00025cc9 - bad surface file
000f2597
00103141
00025cc9x86math.dll
0000189frendcomp.dll
00011163 - bad hash at <vmeshlibrary>example <li_gunboat.3db.lod0.vms include=“li_gunbship_cmp\lod0.vms.xml”>but hash is li_gunboat.lod0.vmsthorn.dll
0002c9ae</li_gunboat.3db.lod0.vms></vmeshlibrary> -
Uh
not sure if i post this here or not, but FLServer crashes on me before it finishes even starting up. Don’;t know if this is correct, but
Offset 0x00003de4 in DACOM.dll -
Got strange offset at flmaterials.dll
0x00005b33
At flspew.txt:
C:\work\builds\dalibs\dalibs-build\build\Src\RendComp\VMesh\VMPartArch.cpp(697) : NOTICE:General: VMESH: couldnt find material 65536 C:\work\builds\dalibs\dalibs-build\build\Src\RendComp\VMesh\VMPartArch.cpp(697) : NOTICE:General: VMESH: couldnt find material 327684 C:\work\builds\dalibs\dalibs-build\build\Src\RendComp\VMesh\VMPartArch.cpp(697) : NOTICE:General: VMESH: couldnt find material 589832 C:\work\builds\dalibs\dalibs-build\build\Src\RendComp\VMesh\VMPartArch.cpp(697) : NOTICE:General: VMESH: couldnt find material 851980 C:\work\builds\dalibs\dalibs-build\build\Src\RendComp\VMesh\VMPartArch.cpp(697) : NOTICE:General: VMESH: couldnt find material 1114128 C:\work\builds\dalibs\dalibs-build\build\Src\RendComp\VMesh\VMPartArch.cpp(697) : NOTICE:General: VMESH: couldnt find material 1376276
Tried to find this values by FL Developer - no luck
Happens mostly at one system - bw08 (Tau-23)
Digging fl forums i see not only me had this problem…
Someone solved? -
Try to remove
….
[Object]
nickname = Bw08_suprise_ge_train_1
ids_name = 261761
pos = 21340, 0, 22673
rotate = 30, 0, 20
archetype = suprise_ge_train
visit = 16
ids_info = 66426
loadout = SECRET_train_bw08
……and check if it still happens.
I encountered various texture related problems
using the HD texture mod.
Dragging that one down was real pain. -
Yeah, b!g thanks F!R!
Works ferroconcretely -
Nova wrote:
Help please… i’m in desperation…
Freel server (mod) crashes when jumping inside Kepler system…
000c465f in content.dllIt is because of mixed non-patched and 1.1 patched files.
P.S. Alows to run Itano Circus Server (Woohoo) -
Getting a reasonably consistant ctd on freelancer.exe at offset 0x00149e35
multiple characters, always at launch to space. Only change in the mod has been updating the jflp.dll to the new ver. 1.21. Restored jflp back to version 1.2 with same results, I now have less than 50/50 chance of getting into space without crashing.
Any ideas? I know there is a thread on this offset, but it doesn’t draw any real conclusions and the idea of deleting all character files on the off chance that it might work would not go down well
-
Thaddeus wrote:
Getting a reasonably consistant ctd on freelancer.exe at offset 0x00149e35multiple characters, always at launch to space. Only change in the mod has been updating the jflp.dll to the new ver. 1.21. Restored jflp back to version 1.2 with same results, I now have less than 50/50 chance of getting into space without crashing.
Any ideas? I know there is a thread on this offset, but it doesn’t draw any real conclusions and the idea of deleting all character files on the off chance that it might work would not go down well
This topic:
topicWhat I found: the crash seems to be random.
After I uninstalled FLHook 1.6.9(88Flak FLHook) and changed it to FLHook 2.0 –-> NO CRASHES.
I use 1.21 JFLP by Jason Hood.
So the reason in my case seems to be 88Flak FLHook?!
Hope this helps.
-
Thanks Vital. I’m using flhook 2.0 already. The problem used to be quite random as you say, but now its more than ever other time I launch I get dumped to desktop
-
And the 1.21 jflp.dll didn’t fix it? We had some minor issues with the client CTD’ing but Adoxa was able to isolate the issue within the dll and published the 1.21 which so far seems to have fixed our problem.
We do NOT use FLHook.
-
After a clean install this morning without flhook the problem still persists. although frequency of the crash is up to 1:10.
-
HUD? Running vanilla hud.ini as supplied with the quickfix1.0. no changes as far as I can see. No hud mods except I am running your hudshift, that runs faultlessly (afaik…?)
-
adoxa wrote:
Seems to be related to the HUD - made any changes to DATA\INTERFACE\hud.ini?Added opacity to some hud using utf editor, this actually presents in some hud already, that’s the only thing.
BTW, I had JFLP 1.20. Updated to 1.21 and didn’t notice any crashes with FLHook 2.0, didn’t test with 88Flak FLHook.