1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

tcc shell window does not disappear

Discussion in 'Support' started by James Miller, Feb 19, 2017.

  1. James Miller

    Joined:
    Mar 10, 2013
    Messages:
    7
    Likes Received:
    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.
     
    #1 James Miller, Feb 19, 2017
    Last edited: Feb 19, 2017
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    conhost.exe (which is a Windows app, not part of TCC / TCMD) is the parent of the TCC process, not the child. Windows keeps the conhost processes around for a while in case you decide to launch another console session. They will eventually disappear on their own.
     
  3. James Miller

    Joined:
    Mar 10, 2013
    Messages:
    7
    Likes Received:
    0
    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?
     
    #3 James Miller, Feb 19, 2017
    Last edited: Feb 19, 2017
  4. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    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?
     
  5. James Miller

    Joined:
    Mar 10, 2013
    Messages:
    7
    Likes Received:
    0
    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.
     
    #5 James Miller, Feb 19, 2017
    Last edited: Feb 19, 2017
  6. MaartenG

    Joined:
    Aug 3, 2016
    Messages:
    355
    Likes Received:
    8
    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.
     
  7. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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.
     
  8. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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.
     
  9. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    Well, that's interesting -- I can't reproduce this problem with Windows 10 build 15031. (I could with another machine running 14393.) Apparently Microsoft changed it again, but I'm not sure yet whether for better or worse.
     
  10. MaartenG

    Joined:
    Aug 3, 2016
    Messages:
    355
    Likes Received:
    8
    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 ..
     
    #10 MaartenG, Feb 21, 2017
    Last edited: Feb 21, 2017
  11. James Miller

    Joined:
    Mar 10, 2013
    Messages:
    7
    Likes Received:
    0
    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].
     

    Attached Files:

    #11 James Miller, Feb 26, 2017
    Last edited: Feb 26, 2017
  12. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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.
     
  13. MaartenG

    Joined:
    Aug 3, 2016
    Messages:
    355
    Likes Received:
    8
    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)
     
    James Miller likes this.
  14. James Miller

    Joined:
    Mar 10, 2013
    Messages:
    7
    Likes Received:
    0
    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!
     
  15. MaartenG

    Joined:
    Aug 3, 2016
    Messages:
    355
    Likes Received:
    8
    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" !!
     
  16. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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.
     
  17. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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.
     
  18. James Miller

    Joined:
    Mar 10, 2013
    Messages:
    7
    Likes Received:
    0
    I tested v20 out and it works!

    Would it be possible to back port this change to v13?
     
  19. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    No - there's so little of the affected code in common between v20 and v13 that this would be a major headache (i.e., several thousand lines of code) and would almost certainly break (many) other things.
     

Share This Page