Welcome!

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

SignUp Now!

Reboot and exit reason

  • Thread starter Thread starter rps
  • Start date Start date
Jul
442
6
v21.01.51
C:\JPSoft>ver

TCC 21.01.51 x64 Windows 10 [Version 10.0.15063]

When I issue a REBOOT /L the value of _exit is 0.

Based on my understanding of this variable, I was expecting a value of 5 for "LOGOFF_EVENT".

If this is by design, I suggest the documentation for REBOOT be expanded to include what each option should return in the internal variable _exit. This would be helpful even if the above is not by design.
 
REBOOT /L calls the ExitWindowsEx function and never returns, so there's no way it could set _exit.
What never returns? The docs say ExitWindowsEx returns (and the shutdown may or may not proceed (asynchronously)). When Windows does actually exit, I figure TCC would hear about it (WM_QUERYENDSESSION and the like) and set _EXIT by other means. Yes/no?
 
What never returns? The docs say ExitWindowsEx returns (and the shutdown may or may not proceed (asynchronously)). When Windows does actually exit, I figure TCC would hear about it (WM_QUERYENDSESSION and the like) and set _EXIT by other means. Yes/no?

No. It doesn't send a WM_QUERYENDSESSION to TCC, and TCC exits immediately after the ExitWindowsEx.
 
No. It doesn't send a WM_QUERYENDSESSION to TCC, and TCC exits immediately after the ExitWindowsEx.
If TCC didn't exit immediately, wouldn't it get WM_QUERYENDSESSION (from Windows) when (and if) the shutdown happened?
 
No, because it's a console app and it doesn't get those messages from Windows (conhost does).

And why would TCC need to know that it's being shut down when it's the one that told Windows to shut down?
1. I'm surprised
2. Regardless of whether the user initiated the shutdown with TCC, TCEXIT will be run (won't it?) and what it does may depend on _EXIT.
 
When you shutdown or logoff (not using REBOOT) TCC exits gracefully so I figure it's somehow becoming aware of what's happening (Ctrl handler?) Can't REBOOT just leave TCC alone and let it terminate more normally?

IMHO, if TCC is closing itself, it should always run TCEXIT.
 
No, because it's a console app and it doesn't get those messages from Windows (conhost does).

And why would TCC need to know that it's being shut down when it's the one that told Windows to shut down?
The reason why is so that a user (me) can log the reason for TCC "shutdown" based on the docs for _exit.

Using TCC 21.01.51 x64 Windows 10 [Version 10.0.15063] when I restart from Windows. Here is the log with 3 TCC tabs in TCMD, with _exit==2
Code:
    "$$$$$ Executing tcexit.btm for 21.01.51 (4376) $$$$$"


    "$$$$$ Executing tcexit.btm for 21.01.51 (3224) $$$$$"

    "$$$$$ Executing tcexit.btm for 21.01.51 (7324) $$$$$"
These status lines come from my tcexit.btm file, so it appears that tcexit.btm is at least started. Later on in tcexit I test for the reason based on the value of _exit and would add the reason to the log if tcexit.btm got that far, which clearly doesn't happen on a Windows restart or closing a TCC tab with X, at the top right.
I have experimented a great deal and have only been able to successfully detect and log an exit event. _exit set to 0. As seen above a close event is recognized but tcexit.btm only executes a couple statements.

That being the case; when is _exit set to anything other that 0 or 2 as document?
Code:
_EXIT returns the reason for exiting TCC. The possible values:

0        EXIT command
2        CLOSE_EVENT
5        LOGOFF_EVENT
6        SHUTDOWN_EVENT
Is there any way to detect and log a value of 2,5 or 6?
If this isn't possible at present; Is it even possible?
No sense in adding a suggestion if it isn't even possible.
 
Back
Top
[FOX] Ultimate Translator
Translate