Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

in TCC I can no longer check for updates with the option command?

R

Rodolfo

May
339
6
Hello, I just upgraded to TCC 36.01.53 x64 in Windows 11 [Version 10.0.26200.8457] English.
I upgraded running the command Option /U.
Now, if I run the same command, nothing happens.
The same (does not) happens if I run the Option command and from there I choose Updates and then Check for Updates.
There is not any message or popup.


Thank You and regards

Rodolfo Giovanninetti
 
I just saw that this issue seems to exist only if I run TCC in elevated mode.
From TCC in not elevated mode it appears a popup that says that I am up to date.
Previously I did not test in not elevated mode, because as a normal user I cannot upgrade a software.


Thank You and regards

Rodolfo Giovanninetti
 
It's the same here with an interesting dependency on TCMD. If elevated and not in TCMD there's no response from updater. If unelevated or in TCMD I get the up_to_date message box.
 
rconn said:
Fixed in 36.01.54 (already uploaded).

Note that the fix is for the updater in build 54, so you'll have to download & install that build before you'll see the fix.
Click to expand...

I manually downloaded the installer for build 54 and installed. These observations remain true when I use OPTION /U.

vefatica said:
If elevated and not in TCMD there's no response from updater. If unelevated or in TCMD I get the up_to_date message box.
Click to expand...
 
Yes, just checked, no message box and updater is not running.

Code: 
d:\tc36> option /u

d:\tc36> ver
TCC 36.01.54 x64 (d:\tc36\tcc.exe)
Microsoft Windows 11 Pro for Workstations
10.0.26200.8457 (25H2)
WindowsTerminal 1.24.2605.12001 (1.24.1321.0)
 
I said

If elevated and not in TCMD there's no response from updater. If unelevated or in TCMD I get the up_to_date message box.
Click to expand...

That means it's OK in TCMD, elevated or not. It's not OK in elevated WT or in an elevated console.
 
I still cannot reproduce the issue here, with or without Windows Terminal.

However - if something on your system (not TCMD) is starting TCC in a job and then restricting breakaway for subprocesses, you'll get exactly those symptoms. I have added more error checking for build 55 to detect the relevant error (ERROR_ACCESS_DENIED).
 
In a console, TCC is not in a job and OPTION /U works in any case. My earlier test with a console was flawed because I was starting the console from WT.

In WT, TCC is in a job and I see these:

Code: 
Elevated:   JOB_OBJECT_LIMIT_BREAKAWAY_OK is not set

Unelevated: JOB_OBJECT_LIMIT_BREAKAWAY_OK is set

Both:       JOB_OBJECT_LIMIT_SILENT_BREAKAWAY_OK is not set
 
Well, that's your problem. If JOB_OBJECT_LIMIT_BREAKAWAY_OK is not set, when TCC tries to launch the updater with the CREATE_BREAKAWAY_FROM_JOB flag, the CreateProcess call fails because WT is blocking it (with an access denied error).

I could then try to start the updater without that flag (or with ShellExecuteEx), but it wouldn't do any good. The updater and installer will be started in the job that TCC inherited, and the installer won't be able to update anything without killing itself.

I do not see the issue with the (older) version of WT I'm running. I don't know if newer WT builds added this or if you have something in your WT / Windows configuration that's doing it. (And what it's doing doesn't make much sense - it seems more logical to allow elevated sessions to do things that unelevated ones can't, not the other way around.)
 
I usually use any of a variety of unzipped WT installs. The store version does not put TCC in job objects and OPTION /U is OK. So don't go out of your way on my behalf.
 
That worked after OPTION /U in an elevated, unzip install of WindowsTerminal 1.25.2605.12002 (preview) (1.25.1322.0). The installer terminated TCC (and WT with it) and continued.
 
You must log in or register to reply here.
Back
Top