(dns resolve related) Connection issues related to windows update of september 2026

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

  1. 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?

FYI: The errors seem to occur more frequent since september.

It looks like rolling back some windows updates resolves the issue

wusa /uninstall /kb:5129195
wusa /uninstall /kb:5124008
wusa /uninstall /kb:5126052

Replacing the hostname by the ipv4 address also seems to solve the connect issues.

Hi,

as I can see, you are using Indy.
I can suggest to update to the latest Indy snapshot and retest.
it may fix this issue.

also you can report about issues if this case isn’t fixed yet.

Thanks,

Is the procedure explained somewhere to put the latest indy under our delphi remobjects SDK?

Hi,

Delphi 10 Seattle or later

it is enough to specify paths to github’s indy in your project’s search path.

by other hand, you can specify paths to github’s indy at top of Delphi IDE->Options->Language->Delphi->Library->Library paths like

Delphi compiler will rebuild Remoting SDK units using new Indy files.

other versions of Delphi

  • you should specify paths to github’s indy at top of Delphi IDE->Options->Language->Delphi->Library->Library paths like
  • install Indy packages
  • 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

We have delphi xe12 & xe13, so only the path & performing a full build i presume.

Is there a way to check/list the indy version at runtime (as verification/debug tool)

Hi,

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 was thinking about a runtime check to verify the build was OK

… but I guess the constants are accessible

thanks

Hi,

yes, just reference to IdGlobal.pas in uses and you will have access to constants from IdVers.inc

FYI: The indy version does not solve the issue.

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 :wink:

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

Evgeny,

Do you also have an answer to the first question in my post?

  1. What could cause the bind events trigger twice without the connect event?

The fact that we see this and a crash in our code wants me to reproduce this case and make our code more robust.

TIA, Frederic

Hi,

You may have BindV4 and BindV6. in this case, Indy may call BeforeBind, SocketAllocated & AfterBind twice.

try to grab callstacks for both cases