IPADDRESS freeze in Background Script

[GermanDirk]

The Function @IPADDRESS freeze in Background Script. In Foreground (TCC interactiv) is the Function functional. Calling from interactive TCC-Window the Test Script its is the Function functional,
but Starting a CMD with TCC.EXE /C Test.btm then not. This Problem is new under Window Server 2022 OS.

I will migrating Take Command Scripts from Windows Server 2019 to Windows Server 2022, but the File Transfer Scripts dont running. She stopping (freeze forever) by use the Function IPADDRESS.
In the Foreground (interactiv) i can use the Function and can Call the Test.btm succesfull (!), but not per Start TCC.EXE /C Test.btm.
This Effect is present in Windows Server 2022. The used Account(-Rights) have here none other effect. Before in Windows Server 2019 OS is this funtional.
So i test it with the latest JPSoft TCC RT v33, but the same Effect. I have removed the Antivir-SW and reboot the Windows 2022 Server , but the same Result.
I have a new blanko Windows Server 2022 OS installed in a VM, but the same Result. Interactiv OK, in Background NOT.

Test.cmd contains
"your Path\TCC.EXE" /C "your Path\Test.btm"

Test.btm contains
@ECHO Show IPADDRESS[www.jpsoft.com]
@ECHO %@IPADDRESS[www.jpsoft.com]

I have no Idea more ...

 

[vefatica]

This could be related. When TCC is running in a console, this works every time.

v:\> echo %@ipaddress[jpsoft.com]
104.26.3.71

When TCC is running in Windows Terminal it fails every time (does not return, TCC using no CPU).

 

[vefatica]

This could be related. When TCC is running in a console, this works every time.

v:\> echo %@ipaddress[jpsoft.com]
104.26.3.71

When TCC is running in Windows Terminal it fails every time (does not return, TCC using no CPU).

@IPADDRESSN and @IPDHCP work/fail similarly. I didn't try others.

 

[vefatica]

Note: In Windows Terminal echo %@ipaddress[jpsoft.com] will typically fail as mentioned earlier. But it will succeed if I first echo %@ping[jpsoft.com].

 

[vefatica]

This bad behavior in WT goes back to v25; v24 is OK.

 

[rconn]

Hard to imagine how this could be a TCC issue. More likely Windows Policy or console host.

 

[rconn]

I just tried it with TCC v34 in Windows Terminal & Windows 11, and @IPADDRESS works as expected.

 

[vefatica]

I'm just reporting what I see. Here's an interesting one. In a v25 console, the second command below never returns. It's the same with more recent TCCs. This one looks transient-related.

 

[Charles Dye]

I can replicate this, in a console window or a Take Command tab as well as in Windows Terminal.

As per Vincent, @PING seems to prevent the hang. It doesn't need to be the same hostname:

I feel like something isn't getting initialized correctly, but @PING fixes it.

 

[rconn]

@PING has absolutely nothing to do with @IPADDRESS in TCC. If that toggles the @IPADDRESS behavior, it's something going on in the background in Windows.

When you get a hang with @IPADDRESS, what does @IPSTATUS say?

 

[Charles Dye]

Well, add that one to the list. @IPSTATUS also hangs:

... but not if I call @PING first:

 

[rconn]

I ran this several hundred times and got three hangs:

1) Nothing to do with /C
2) It's hanging in the Windows Winsock dll initialization code, for no apparent reason (not my code)
3) The TCC code is never called

 

[vefatica]

 

[Charles Dye]

Vince, your "always works" lines both hang for me. I wonder if we aren't bumping into differences in .INI or TCStart.btm files. Could you try starting TCC in safe mode (/I) and see what happens that way?

 

[vefatica]

That was in a console. None of it works in WT. In a console it's the same with or without /i.

 

[rconn]

1.) Nothing to do with /C
2.) Nothing to do with /K
3.) Calling the @PING code immediately before calling the @IPADDRESS code does not work; there's more going on here
4.) Calling the @PING code in the TCC initialization code does work, for reasons that I do not understand yet
5.) Based on circumstantial evidence, I suspect this is a timing issue in Winsock
6.) Around v24 the internet functions code was switched from the XP-compatible APIs to Win7+ APIs

 

[vefatica]

It was mentioned earlier that, in WT, using @PING first allows a subsequent @IPADDRESS to work.

Using @ICMP (plugin, like @PING) first has the same effect. @ICMP causes an explicit call to WSAStartup() (and later WSACleanup()).

Using @DNS (plugin, like @IPADDRESS) first does not allow a subsequent @IPADDRESS to work. @DNS does not explicitly initialize Winsock; it merely uses DnsQuery (WinDNS.h).

 

[rconn]

Simply calling WSAStartup does not fix the hang.

 

[Alpengreis]

Tested with build .27, no hangs in TCC, TCMD tab and WT with:

echo %@ipaddress[jpsoft.com]
echo %@ipstatus[0]