We are seeing connection issues and crashes in our code.
When analyzing the issue it looks like something related to DNS resolving in windows which fails sporadically for hostnames without domain (netbios?)
There are 2 things I would like to verify with you
What could cause the bind events trigger twice without the connect event?
In the logs we see BeforeBind, SocketAllocated & AfterBind occur twice.
Typically we see these 3 events + clientconnected.
What could cause this & is there a way to trigger this (to debug possible errors in our code triggered by this condition)
[T2594][25-09-2026 10:16:26.088][INFO(4)]RO connection for thread id 00002594 BeforeBind event
[T2594][25-09-2026 10:16:26.088][INFO(4)]RO connection for thread id 00002594 ClientSocketAllocated event
[T2594][25-09-2026 10:16:26.088][INFO(4)]RO connection for thread id 00002594 AfterBind event
[T2594][25-09-2026 10:16:26.092][INFO(4)]RO connection for thread id 00002594 BeforeBind event
[T2594][25-09-2026 10:16:26.092][INFO(4)]RO connection for thread id 00002594 ClientSocketAllocated event
[T2594][25-09-2026 10:16:26.092][INFO(4)]RO connection for thread id 00002594 AfterBind event
2. Another thing we see in our crash reports is the TIdStackWindows.HostByName function failing.
This occurs sporadically and the hostname that needs resolving is a windows machine in the LAN.
You can see a callstack below. Does this ring a bell? Any tips on how to prevent this? or analyze this further?
uncomment {.$DEFINE RemObjects_INDY10E} in RemObjects.Inc
{ Indy }
{ If you are using Indy 10.6.2 (2016-01-16 and later) or the latest just uncomment the
RemObjects_INDY10E DEFINE right below, and remove the Indy
package references from the Requires section of RemObjects_Indy_Dx.dpk
before re-compiling your RemObjects Indy package. }
{.$DEFINE RemObjects_INDY10E}
launch C:\Program Files (x86)\RemObjects Software\Build\install_DA.cmd (or install_RO.cmd) with admin rights for rebuilding packages
you can check constants from Indy10\System\IdVers.inc for Indy version.
for D12, it is C:\Program Files (x86)\Embarcadero\Studio\23.0\source\Indy10\System\IdVers.inc
I have pinned down the issue to somewhere in windows.
Calling a dns resolve via indy or directly via winsocks api fails if it is netbios based in very few occasions (<0.1% of the resolve dns calls, certain moments a day (lasts only 1 or a few seconds)
The issue has crept into windows 11 in the last month or so.
Unfortunately it won’t leave
So not a RemObjects issue. I can bypass it by doing the resolve myself and caching the ipaddress before i set urls in my remobjects channels