The program does not terminate

[krovit]

Hello everyone!
This code performs some operations on network interfaces and the system date.
Considering that the executable has administrator privileges, I note that the executable does not terminate and the execution remains suspended.
The code includes delays to allow the execution of commands, especially on network interfaces, which notoriously take time.
I also note that the execution goes all the way through (the network is reactivated and the system date is restored correctly) but the output on the screen (which is also misaligned with the window) stops at the executed ping.
Is this a bug or what? Any suggestions?

Thank you!

Code: (Select All)

SHELL ("powershell -Command " + CHR$(34) + "Get-NetAdapter | Enable-NetAdapter -Confirm:$false" + CHR$(34))





ex$ = MID$(DATE$, 7, 4) + "-" + MID$(DATE$, 4, 2) + "-" + LEFT$(DATE$, 2) + "T" + TIME$



' Disabilita le schede di rete

SHELL "cmd /c powershell -Command " + CHR$(34) + "Get-NetAdapter | Disable-NetAdapter -Confirm:$false" + CHR$(34)

PRINT "step 1 fatto"



SLEEP 5 ' Attendi un momento per assicurarti che le schede siano disabilitate



' Controlla se la rete è disattivata

PRINT "Controllo stato della rete..."

SHELL "cmd /c ping -n 4 8.8.8.8" ' Pinga un server per verificare la disattivazione della rete

PRINT "Ping eseguito."



' Imposta la data e l'ora

SHELL "cmd /c powershell -Command " + CHR$(34) + "Set-Date -Date 2023-10-01T14:30:00" + CHR$(34)

PRINT "step 2 fatto"



SLEEP 2 ' Aggiungi un ritardo



' Imposta la data e l'ora attuale

SHELL "cmd /c powershell -Command " + CHR$(34) + "Set-Date -Date " + ex$ + CHR$(34)

PRINT "step 3 fatto"



SLEEP 2 ' Aggiungi un ritardo di 2 secondi



' Riabilita le schede di rete

SHELL "cmd /c powershell -Command " + CHR$(34) + "Get-NetAdapter | Enable-NetAdapter -Confirm:$false" + CHR$(34)

PRINT "step 4 fatto"



SLEEP 2 ' Aggiungi un ritardo finale

PRINT "Comandi eseguiti."

[krovit]

I checked the execution of the code in the very old version 1.3 and it works!
As the versions progressed, something got lost along the way (it happens!).

With version 3.13.1 it no longer works (and not even with the latest one).

[krovit]

I have verified.
Version 3.12.0 is the last one that works!
The following ones do not.

[SMcNeill]

This runs and performs with no issues on my laptop.  Does changing the delays affect it at all?  Is there some race condition at work here, perhaps?

[krovit]

This runs and performs with no issues on my laptop.  Does changing the delays affect it at all?  Is there some race condition at work here, perhaps?

Thank you for the response.

The delays do not affect the execution or compilation of the code in any way. They can be removed, and it doesn't change anything.

I tested the code on three PCs with Windows 10 in the versions I mentioned, and the last one that works is 3.12.0.

In the subsequent versions, the execution gets stuck, and as I wrote, strangely, the execution continues, but the output on the screen is not coherent. I have to forcefully terminate the execution.

I would like to add that the compilation with version 3.12 is very fast (the first time. With all versions, it is always slow - I don't know why), while with the later versions, it is very, very slow.

For now, I will stick with version 3.12, but I am sorry to miss out on the updates.

[SMcNeill]

Attempt to add a _DISPLAY statement after each PRINT, and tell me how that affects things on your system.  If it changes anything at all.

[krovit]

Attempt to add a _DISPLAY statement after each PRINT, and tell me how that affects things on your system.  If it changes anything at all.

 No, it doesn't change anything.

[krovit]

Attempt to add a _DISPLAY statement after each PRINT, and tell me how that affects things on your system.  If it changes anything at all.

 No, it doesn't change anything.

Certainly, it seems to depend a lot - indeed, very much - on the date format of the system (which each regional version of Windows has) that one is trying to manipulate and impose on the system itself.

With PowerShell, it is possible to determine what it is, but it seems that it doesn't work the same way. Perhaps the CMD commands work better, but it would still be preferable to use PowerShell.

In any case, this does not explain why version 3.12 of QB64 poses absolutely no problem and does not cause any errors with the code syntax, while later versions - on the same machines - do not behave as one would expect.

[Pete]

In terms of forcefully having to terminate a QB64 exe, I have had that 'randomly' happen in many versions of QB64 on rare occasions, but never consistently. On rare occasions of a SHELL process hanging, I've had to use _DONTWAIT and add a delay. If a developer can reproduce your results, from the working version to the latest version, hopefully going backwards in the build can spot whatever it is that is causing the program to run differently.

Pete

[DSMan195276]

@krovit I think I figured it out, 1.13.0 and later versions of QB64PE freeze if you set the system date backwards. I believe I know what the issue is and will probably have it fixed in the next version.