Need help investigating an app crash

[Cristian Peța 123]

20 hours ago, Lars Fosdal said:

Proper stack traces with EurekaLog, MadExcept or similar, are invaluable in such cases.

I second this.

On 7/29/2025 at 10:25 AM, Der schöne Günther said:

As for (3), my app was able to log the following callstack:

24/07/2025 14:31:32
[63.4]
Thread-ID 9052 ("TIdThreadWithTask")EAccessViolation: "Access violation at address 0098638C in module 'MyStuff.exe'. Write of address 00000004"
[0098638C] IdTask.TIdTask.DoBeforeRun
[00CA9106] JclHookExcept.DoExceptFilter
[00CA92D9] JclHookExcept.HookedExceptObjProc
[0040BAA3] System.@HandleAnyException
[004E2399] System.Classes.ThreadProc
[0040C6F8] System.ThreadWrapper

Here I don't see line number in IdTask.TIdTask.DoBeforeRun. I suppose it is the first line. Also the call stack is not what it should.

I would like also assembler code and register values.

Address 00000004 is FBeforeRunDone in TIdTask.DoBeforeRun.

  TIdTask = class(TObject)
  protected
    FBeforeRunDone: Boolean;
  ....
  end;

procedure TIdTask.DoBeforeRun;
begin
  FBeforeRunDone := True; <-- "Access violation at address 0098638C in module 'MyStuff.exe'. Write of address 00000004"
  BeforeRun;
end;

So a reference to TIdTask object is nil but we don't see the call stack to know who is calling this nil reference.

A proper call stack is missing.

[Der schöne Günther 340]

I usually have very good callstacks (using the FastMM4_FullDebugMode.dll), except these rare cases when I don't.

 

I have never bothered with other tools like madExcept because I thought they would output the same anyway. If something corrupts the stack (which is what Windows indicates), then I'm not sure how much of a valid callstack could have been recovered anyway.

[Der schöne Günther 340]

Small update:

 

The exhibition is now underway, and not only did the problems on that one line re-appear, it also started manifesting on a completely different line on another client of ours. ☠️

 

It seems like it was a combined problem of power supply cables and insufficient earthing. I still believe that down there is still another software issue, like invalid data leading to stack corruption deep within the Indy library, but at least the problem seems to be gone now 😌

Edited October 10 by Der schöne Günther

[aehimself 424]

On 9/4/2025 at 9:22 AM, Cristian Peța said:

Also the call stack is not what it should.

 

A proper call stack is missing.

 

On 9/4/2025 at 9:44 AM, Der schöne Günther said:

If something corrupts the stack (which is what Windows indicates), then I'm not sure how much of a valid callstack could have been recovered anyway.

 

It's not necessarily a stack corruption, UPX can also cause this in compiled executables.