Welcome!

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

SignUp Now!

tcc shell window does not disappear

James Miller

James Miller

Mar
16
0
Hi,

I run tcc version 13.04.58 on Windows 8.1 but I reproduced this problem with version 20.11.40.

TCC 20.11.40 x64 Windows 8.1 [Version 6.3.9600]

[i:\home\jhm\arc]services.msc

[i:\home\jhm\arc]exit

Using Sysinternals process explorer, I notice after executing the "exit" command or clicking on the TCC window's X, tcc.exe terminates but the conhost.exe child does not. The TCC window disappears and the conhost.exe process terminates when either the mouse clicks the TCC window's X a second time or if the child process (mmc.exe in this case) terminates. If the TCC window has no child process other than conhost.exe, the TCC window disappears after typing exit. This problem does not occur running Windows 7.
 
Last edited:
Is there a creative way to kill the associated conhost.exe after typing exit or clicking on the TCC window's X to make its window disappear?
 
Last edited:
How can you click TCC's "X" a second time ... after the window has disappeared?

I have never seen conhost hang around. Does Windows 8 act differently from Windows 7?
 
yes, Windows 8 does act differently than Windows 7. I recently migrated to Windows 8 on a newer machine. A TCC window does not disappear after the first X click on Windows 8 if a process like mmc.exe was previously launched via the TCC command line.

FWIW, if I run cmd.exe and then services.msc then type exit, the cmd.exe window disappears and the associated conhost.exe terminates on Windows 8.1.
 
Last edited:
Same on Windows 10 (6.3.14393 x64):

- Start TCC.exe
- Enter command: notepad dummy.txt
- Enter command: EXIT

The TCC.exe process will be killed (according to taskmgr, procexp and the like), but the TCC window stays visible.
Clicking on the "X" will remove the TCC window.


@James Miller is right: On Windows 10 (I guess the same goes for Windows 8) the conhost process *IS* started as a childprocess of TCC (idem for CMD, btw)
That is what causes this: TCC gets "killed"; the conhost child process (that is sort of a proxy for TCC <-> user communication) "stays alive".
Clicking the "X", closing notepad or killing the conhost process finally removes the TCC window.

On Windows 7 conhost is an "independent" process (child of the Client/Server Runtime Subsystem. Conhost is *not* the parent process of TCC.exe.
 
It's a Windows bug / behavioral change. The TCC process is in fact gone, but the console window is still held open by conhost (look at task manager). I'll have to run CMD under the debugger to see what it's doing differently; I suspect it's more likely to be an issue with CreateProcess than with the exit.
 
MaartenG said:
On Windows 7 conhost is an "independent" process (child of the Client/Server Runtime Subsystem. Conhost is *not* the parent process of TCC.exe.
Click to expand...

Well, if we're getting picky, there's no such thing as "parent" or "child" processes in Windows. However, conhost is handling the message queue for the TCC console process, and it's the one doing all of the I/O, so in effect it's *acting* like a parent process.
 
rconn said:
Well, if we're getting picky, there's no such thing as "parent" or "child" processes in Windows. However, conhost is handling the message queue for the TCC console process, and it's the one doing all of the I/O, so in effect it's *acting* like a parent process.
Click to expand...
That's a little too philosophical for me: Who is the real dad? The one that is on the birth certificate (=who created the process), but left his child right after birth? Or the guardian that acts on behalf of the child in communcation with the outside world (=what I roughly described as a UI proxy) and thus feeds this child?

EDIT: In Windows 8 the process mechanism has changed a little. I don't remember the exact name of it (and neither does Google with the (apparently wrong) keywords I used), but it had something to do with clustering processes.
Maybe that helps (:-S) in analyzing what's going on here ..
 
Last edited:
Oddly enough, I am currently working on an independent but related problem that uses the Windows CreateProcess library function.

I recently wrote a C language Windows utility called detach.exe compiled with MingGW that calls CreateProcess with the CREATE_NEW_CONSOLE creation flag.

If I run "detach.exe notepad.exe" from a TCC shell and then type exit the TCC window disappears.

If I run "notepad.exe" from a TCC shell and then type exit the TCC window does *not* disappear.

Similarly, if I use the internal TCC detach command to run "detach notepad.exe" and then type exit the TCC window does disappear.

I uploaded a detach.zip archive with the utility's source and executable if interested.

Does this behavior warrant a fix? I have a TCC license for v13.04.58 x64.

I see this behavior with Windows 8 [Version 6.2.9200]. I do not see it with Windows 7 [Version 6.1.7601].
 

Attachments

Last edited:
This is a Windows 8 (& early 10) bug in CreateProcess. The latest Windows 10 builds work, as do all Windows 7 builds.

So far the workarounds I've come up with all break something else (like the ability to pipe to a GUI process, which VIEW uses in TCC). Still working on a Windows 8 solution, but the ultimate fix may well be to tell people to update to Win 10.
 
A couple of days ago I decided to leave these forums, but also don't like loose ends.
So, as a reprise:

try this in your TCEXIT.btm:
Code: 
if %[_transient]%[_pipe]0 ne 0 quit
set KILLTHIS=%@word[0,%@execstr[tasklist /z conhost | findstr "%_pid"]]
if defined KILLTHIS defer TASKKILL.EXE /PID %KILLTHIS /F

It will find all conhost processes and if one of those is the child-process of the current TCC, it will kill this conhost process (using defer and taskkill.exe).

You can't use taskend instead of taskkill.exe, because otherwise TCC would still be running.
The /F (forced kill) parameter of taskkill.exe is necessary. Without it, conhost won't get killed.

If you started Notepad before, it will keep running.

@James Miller : your detach.exe Notepad.exe will probably do the same as start notepad.exe . (That would be another workaround)
 
creative work-around! I am currently running TCC v13 that does not offer the tasklist /z option. If JP Software does not provide a fix, I will likely pursue a variation of your suggestion. Thank you!
 
Sorry, overlooked the version 13 part ....

Code: 
set %@execstr[2,wmic process WHERE "ParentProcessID=%_PID AND Caption='conhost.exe'" get ProcessID /VALUE] >nul
if DEFINED ProcessId defer TASKKILL.EXE /PID %ProcessId /F
(Not tested; I'm on a Windows 7 machine right now. But should work ...)

Can probably be done more elegant with a %@WMI function (that is in version 13), but that is up to you :-)
(this "code" took me a around a minute; converting it to @WMI probably would take me half an hour to learn it's syntax and other quirks)

BTW: Thanks for the "Like" !!
 
James Miller said:
Oddly enough, I am currently working on an independent but related problem that uses the Windows CreateProcess library function.

I recently wrote a C language Windows utility called detach.exe compiled with MingGW that calls CreateProcess with the CREATE_NEW_CONSOLE creation flag.
Click to expand...

The Windows CreateProcess bug in TCC isn't because of the absence (or presence) of the CREATE_NEW_CONSOLE flag, it's because of the handle inheritance. Your app doesn't inherit handles, so it doesn't have the problem. Unfortunately, TCC has to pass the STDxxx handles, or redirection & piping won't work.
 
rconn said:
I (finally) found a workaround for the Windows bug, that doesn't seem to adversely affect any other features. I'm regression testing everything today; if everything goes OK I will upload a new 20.11.43 build tomorrow.
Click to expand...

I tested v20 out and it works!

Would it be possible to back port this change to v13?
 
You must log in or register to reply here.
Back
Top