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

Remoting SDK
,
1

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?

image
image792×372 23 KB

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.

2

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.

3

Thanks,

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

4

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

Untitled
Untitled892×626 94.5 KB

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
    Untitled
    Untitled892×626 94.5 KB
  • 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
5

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)

6

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

7

i was thinking about a runtime check to verify the build was OK

… but I guess the constants are accessible

thanks

8

Hi,

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