Crash Offsets

After a clean install this morning without flhook the problem still persists. although frequency of the crash is up to 1:10.

Seems to be related to the HUD - made any changes to DATA\INTERFACE\hud.ini?

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.

Freelancer.exe

The description for Event ID ( 1000 ) in Source ( Freelancer ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: freelancer.exe, 6.66.0.0, ntdll.dll, 5.1.2600.2180, 000122ba.

```Only on my machine. Others, so far don't have troubles.
FLSpew seems clean.
[EDIT] * Sims its Win related error, no one has same problem and other stuff refuse to load (HardCMP, Blender, …), so ignore it.

ntdll.dll crashes - Not supported parameter or typing error, not supported/equipable archetype in players char file.

Ty, I look into that.

Thaddeus wrote:
Getting a reasonably consistant ctd on freelancer.exe at offset 0x00149e35

Had another look at this, but not really any more to say. The offending address is set to 0 when you load/land on a base; it is set to whatever it should be (non-zero) just before you launch (or load in space); the crash occurs just after launch because it is now zero. If you can debug, set a write h/w breakpoint on 674AA0. On a base, it should break at 4DA799 (that’s where it gets zero); on launch, it should break at 4DA229 (non-zero). And that’s it - if it doesn’t break at 4DA229, it’s not being set as it should; if it breaks anywhere else, something’s broken somewhere.

Thanks, when I run client and server on the same machine I dont get this problem. So I did a file by file comparsion and found an updated .sur file that wasnt matched on server. Re-syncing the files seems to have alleviated the problem, it still happens but back to being random again.

Forgive my ignorance but what program do I need to debug this

Thaddeus wrote:
Thanks, when I run client and server on the same machine I dont get this problem. So I did a file by file comparsion and found an updated .sur file that wasnt matched on server. Re-syncing the files seems to have alleviated the problem, it still happens but back to being random again.

Forgive my ignorance but what program do I need to debug this

Could you tell me please what this file was?

I run server and client on the same machine, but through a
LAN(if the LAN is disconnected, you can’t connect to the server) for better test porpouses, and it appears to be quite random as you said. However, no this issue under FLHook 2.0

You’re right its not an FLhook2.0 problem. I’ve removed it from the development server and I’m still getting this offset crash occasionally. Mismatched file was a ship .sur I was working on. There was a vanilla .sur on server and a new (Schmacks) .sur on my client. Could be a red herring as I did do a complete reinstall on the server at the time.

Thaddeus,

so I updated my JFLP from 1.20 to 1.21, tested with 88Flak FLHook(for long time, guess no less than 150 - 200 landings and launches in a row) and had no CTDs so far.

Will inform if I find out anything else.

@Thaddeus: OllyDbg is what I use. If you want to give it a try… If you already have Freelancer running, switch to windowed mode and do File|Attach in OllyDbg; if not, File|Open, browse to Freelancer.exe and add -w to the arguments. (Bear in mind, the first time will take a while as it analyses everything, which will probably cause your connection to timeout.) Select the dump window (Shift+Tab twice), press Ctrl+G and enter 674AA0. Now Shift+Right four times and press Shift+F5, then Down to select Write and Enter (who uses the mouse? ;)). Those four bytes will turn red, indicating there’s a breakpoint there. Press F9 to run and just wait for the break…

Thanks, I’ll give it try next time I’m on the server

Someone knows whats 0006c033 at content.dll means?

EDIT:

06F0C031 8B08                	mov	ecx, [eax]
06F0C033 8B01                	mov	eax, [ecx]

Whats the meaning?
Anyway when ecx is null it crashes.

Changed 0006c031 8B08->9090

No crashes and no visible side-effects.

I have falls server error server.dll 00017f38 what can this mean?
I shall be grateful to any information

Seems to be loadout problem when space object respawns.

Thanks. I shall search in this direction

OutCast wrote:

adoxa wrote:
common.dll
0005e010 - part of function Fuse::UnBurn, if that helps

first - probably caused by faulty fuse we had in our cruisers. it crashed several times during tests when nanobots were used while fuse being already ignited.
^^

@Outcast
Did you ever identify a fix for the fuse? We’re using the default fuses found in the jflp files and are experiencing exactly what you’re describing here. When a player with a Kusari Destroyer dies, if the player hits the regens while dying the server crashes.

I’m looking at the fuses and nothing is jumping out at me as being an obvious error such as a faulty reference.

R

Bump.
Anyone have a fix for this glitch?