Der schöne Günther

It's an industrial line. There is no internet involved.

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.

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. 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 😳 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. Thank you, I will check. Many thanks for all your replies so far! ❤️

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.

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... Yes, I eventually do. That sounds exactly what my code is doing. Thank you! I will investigate.

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: The app is constantly polling another device through TCP. I am using the delphi-modbus library, which is, of course, based on Indy. 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. 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 "Something" triggers stack corruption, which windows logs as a "Stack Buffer Overrun" Possibly within Indy's code (TIdTask) 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?

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.

This is the same question as last time, right? Problem time execution Mode DEBUG or RUN Library Vosk - Delphi IDE and APIs - Delphi-PRAXiS [en] There is no functional problem, it's just that the performance is not acceptable when being debugged, right? Have you tried using a regular profiler?

As far as I know, nowhere does it specify that keys must be unique.

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.

The TEdgeBrowser has an event handler to catch initialization (OnCreateWebViewCompleted and OnProcessFailed). Have you checked those?

Can you show an example, how you would typically make use of it?

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,...).

For me, the demo code bails out with an exception on SetWindowSize(..). For some reason, GetLargestConsoleWindowSize returns (240, 54) which then causes your function to raise an EArgumentOutOfRangeException. Which seems to be matching the .NET counterpart. So all is fine, and my computer is acting up. Weird.

I don't get a warning for the above code at all 🤷‍♂️