Jump to content
Registration disabled at the moment Read more... ×

Der schöne Günther

Members
 View Profile  See their activity

  • Content Count

    739

  • Joined

  • Last visited

  • Days Won

    12

Posts posted by Der schöne Günther

  2. Posted

    I have reverted the firmware of the device in question to an earlier version and so far, no crashes in the Delphi app anymore. I am not sure if this is just a happy coincidence or really the cause.

     

    Still, I haven't been able to reproduce it which is really frustrating.

  3. Posted · Edited by Der schöne Günther

    57 minutes ago, Remy Lebeau said:

    Best to give each thread its own connection if possible.

    This is deliberate, because the device is a simple controller that cannot serve multiple requests. It can only keep one socket connection open. Therefore, the Delphi app is only opening one connection and sharing it throughout the code.

     

    57 minutes ago, Remy Lebeau said:

    Debugging via forum isn't a good way to handle this. You need to actually debug the program directly and try to reproduce the issue.

    I know. It's not that easy to debug software on an industrial line that is processing tons of raw materials while the line is also on display for an exhibition. I'm doing what I can 😳

     

    52 minutes ago, Kas Ob. said:

    How frequent this happen ? can you reproduce or predict the moment of this crash ?

    I haven't been able to reproduce it. There are other lines running the exact same software and configuration, and they're fine too. I am currently investigating a different software version on said microcontroller, but I am still at loss how this could affect the Delphi app so deeply.

     

    51 minutes ago, Kas Ob. said:

    Confirm if this crash happen with the same exact addresses/parameters , specially the "Fault Offset", it is important.

    Thank you, I will check.

     

     

    Many thanks for all your replies so far! ❤️

  4. Posted

    1 minute ago, Remy Lebeau said:

    There is really no way for anyone to diagnose this problem for you with such limited information.

    Is there anything else I can include?

     

    I've tried running a debug build with "Debug DCUs", Range and Overflow Checking enabled, but that didn't change anything.

     

    As of now, I had to disable integration of that one device, and the software has been running completely fine since then.

  5. Posted

    24 minutes ago, DelphiUdIT said:

    you cannot use Indy (and ModBus too of course) from differnt Threads (you spoke about use it in Main Thread too)

    Are you 100 % certain? I have been doing so for many years. I am aware of things like Windows GDI resources which can only be used from the thread they were created (something like this), but I suppose Indy should absolutely be fine, as long as everything is properly serialized through things like critical sections...

     

    21 minutes ago, PeaShooter_OMO said:

    Do you call the Connected function anywhere?

    Yes, I eventually do.

    21 minutes ago, PeaShooter_OMO said:

    I used to ask via Connected if the connection was still there and that caused issues

    That sounds exactly what my code is doing. Thank you! I will investigate.

  6. Posted · Edited by Der schöne Günther

    I have a Delphi app that is running 24/7, around the globe. On one very important installation, it will just crash and terminate, with no sign of an error message. Of course, I do log full stack traces on any exception as well as Windows resource exhaustion and other things. But this time, I am really stuck.

     

    Here is what is happening:

    1. The app is constantly polling another device through TCP. I am using the delphi-modbus library, which is, of course, based on Indy.
    2. At some point, the main thread will also talk to the device, and fail with a custom exception type. What bothers me, is at the exact same time, the background thread will also fail polling the device. That points to a resource being used by two threads at once, but the connection is entirely guarded by a Critical Section.
    3. Now the really interesting part: A third thread (one of Indy's scheduler threads) will now crash with an Access Violation. And at that moment, Windows shuts down my entire application.

     

    I have not attached the callstacks for (2) because I don't think they provide any useful information.

     

    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

    Then, Windows will log the following two entries in the event viewer:

     

    First, there is an exception of 0xc0000409, which, according to Raymon Chen, just means "that the application decided to terminate itself with great haste" 

    Event[1]:
  Log Name: Application
  Source: Application Error
  Date: 2025-07-24T14:31:32.4810000Z
  Event ID: 1000
  Task: Application Crashing Events
  Level: Error
  Opcode: Info
  Keyword: Classic
  User: N/A
  User Name: N/A
  Description: 
Faulting application name: MyStuff.exe, version: 63.4.0.0, time stamp: 0x67b5aae0
Faulting module name: MyStuff.exe, version: 63.4.0.0, time stamp: 0x67b5aae0
Exception code: 0xc0000409
Fault offset: 0x020b025d
Faulting process id: 0x1e5c
Faulting application start time: 0x01dbfc922ab483ef
Faulting application path: C:\Users\Public\MyStuff.exe
Faulting module path: C:\Users\Public\MyStuff.exe
Report Id: 2a531142-03f7-461e-9fa5-9f50df86ef33

    A few milliseconds afterwards, the access violation is also logged 

    Event[0]:
  Log Name: Application
  Source: Application Error
  Date: 2025-07-24T14:31:32.9150000Z
  Event ID: 1000
  Task: Application Crashing Events
  Level: Error
  Opcode: Info
  Keyword: Classic
  User: N/A
  User Name: N/A
  Description: 
Faulting application name: MyStuff.exe, version: 63.4.0.0, time stamp: 0x67b5aae0
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0xf0a79e3d
Faulting process id: 0x1e5c
Faulting application start time: 0x01dbfc922ab483ef
Faulting application path: C:\Users\Public\MyStuff.exe
Faulting module path: unknown
Report Id: 9b3d67f1-32be-44df-bae9-466d2f36d1b8
Faulting package full name: 
Faulting package-relative application ID:

    For me, it looks like 

    1. "Something" triggers stack corruption, which windows logs as a "Stack Buffer Overrun"
    2. Possibly within Indy's code (TIdTask)
    3. Windows will then shut the process down, wrapping it in an unhandled "Access violation"

     

    My dilemma:

    How on earth can I get behind this? I see I can use tools like procdump to automatically create a dump when the application gets shut down, but even then, I don't know what I would to with it.

    I have looked up the "fault offset" in the first exception (adding the base address to 0x020b025d), and I don't see any useful code there.

     

    Of course there is probably something wrong with my code, but I am rattled by Indy code being the final code running before the lights go out. Maybe @Remy Lebeau does have an idea?

    My Indy version (10.6.2.5311) is an older one. I have tried looking up changes since then, but Github doesn't go that far back. Where else can I check?

  7. Posted

    We are still using it, but nobody has touched that code in years.

     

    I honestly wouldn't use it again. For our next product, we will probably go straight to html and then print or PDF-export straight from a WebView.

  10. Posted

    I am using TEdgeBrowser excessively, up to the point of completely replacing a VCL-based UI with a web-based interface, as well as injecting and calling JavaScript at runtime.

     

    Can you provide a minimal example of your project?

     

    One caveat is that you have to wait for the TEdgeBrowser to finish navigation and _then_ do something with its content, but I suppose that is the same when being wrapped by TWebBrowser.

  13. Posted

    12 hours ago, Brandon Staggs said:

    On the flip side, however, since ARM-based Windows machines run x64 apps just fine, there is no real pressure on Embarcadero to rush offering a compiler. 

    Thank you for your first hand insights into using a Windows ARM machine with Delphi.

    I stopped following the progress on WindowsOnARM a few years ago, so I am not up to date.

     

    Would you be willing to tell more about your daily usage, maybe in a separate thread? I'd be absolutely interested in typical day to day usage, battery runtimes, standby/wakeup times and where it could start to get tricky (old printer drivers, shell extensions, obscure software,...).

    • Like 1

  18. Posted

    Embarcadero has been having too many coals in the fire for years now. Instead of opening the next can of worms, they should be fixing basics like code completion.

     

    I remember being in the Microsoft Technology Adoption Program where you got Teams meetings with the developers behind WinUI and other Windows components, got shown not yet released roadmaps and got to ask questions. Back then, it was basically impossible to properly use WinUI outside of Microsoft's Visual Studio (not sure if it was WinUI2 or 3). At that time, they openly replied to me that they had no plans to change that.

     

    On 3/22/2025 at 11:50 PM, bravesofts said:

    Embarcadero could wrap WinUI 2 & WinUI 3 &+ controls in a native VCL/FMX layer, similar to how TEdgeBrowser integrates WebView2.

    Except WebView2 has been usable for basically everybody from everywhere, and it's actually good. You can see it being used in a lot  of software, not just Microsoft's own products. 

    Just look at how much stuff Microsoft has abandoned in the last couple of years, how much of the "Universal Windows" approach has been dialled down or completely removed already. Not to mention that new GUI stuff has been highly dependant on the most current Windows version. WebView2 even works in Windows 7.

     

    I honestly was interested in WinUI around 2018 to 2020 or so, but it certainly never took off. I firmly believe it is not relevant anymore.

    • Like 3

  19. Posted · Edited by Der schöne Günther

    Thank you both, that is exactly what I was looking for. 😇

     

    It's a pity the VCL itself uses it just this once but I am sure there were performance considerations.

     

    I think this brought me on the right track. I will probably use a TVirtualMethodInterceptor and use the OnBefore hook to watch for methods like ['Repaint', 'Update', 'SetBounds', 'DefaultHandler'] and then call CheckNonMainThreadUsage(). Not sure if it will be sufficient to just use one interceptor on a TForm or TFrame, or if I will need to have a VirtualMethodInterceptors for every kind of control (Buttons, Panels, ...). I will still need to figure that out. 🤔

  20. Posted

    Thank you, I am well aware of that.

     

    I am not directly accessing any GUI elements from threads. I am invoking events to which a VCL form or frame might be subscribed. Or background event handler might trigger something else that might then update the UI.

     

    Similar to like FastMM can throw an access violation at runtime when using memory after it has been freed, I am looking for something that might ~detect~ accessing the VCL in the context of a different thread.

     

  21. Posted

    I am fully aware that Delphi's VCL interface library exclusively lives in the main thread. Everything VCL related must happen in the main thread. Do not access VCL elements, don't even create and destroy something like a VCL Bitmap or Canvas in a thread. Maybe you don't have to be that cautious, but that's what I remember.

     

    Yet, it still occasionally happens to us. An event that used to run in the main thread gets moved to a different thread. Sometimes, things might trigger something that might cause the UI to refresh something.

     

    I know that with perfect documentation and more attention this probably wouldn't happen. Yet, it does.

     

    My question:

    Are there any kind of "runtime checks" I can enable to "detect" -anything- from outside the main thread touches the VCL?

     

    My motivation is to easier "find" places where the UI layer is accidently accessed from outside of the main thread.

  22. Posted

    I cannot contribute how to solve this, but having dealt mostly with Windows I also was surprised recently to find out about how differently this is handled on other platforms like macOS or Linux.

     

    Delphi's standard library was initially built for Windows and suggests you could easily enforce this on other platforms as well. For other languages like C++ or Rust, the standard library's file access mechanism don't even support any way "sharing" or "locking". Their default implementation is even "Don't lock anything, allow everything" which I found surprising. Maybe that was just my old Windows habits.

  24. Posted · Edited by Der schöne Günther

    Can you narrow it down further if the click you want to catch will be

    1. Still inside your own application
    2. Outside of your application, causing it to lose focus
    3. If mouse coordinates matter of you're just interested that a click happened
×