rprichard / winpty

A Windows software package providing an interface similar to a Unix pty-master for communicating with Windows console programs.
MIT License
1.3k stars 166 forks source link

cygwin ssh: Assertion failed: success, file winpty.cc, line 191 #28

Open basinilya opened 10 years ago

basinilya commented 10 years ago

console works locally in mintty, but fails under cygwin ssh:

    $ console cmd.exe
    Assertion failed: success, file winpty.cc, line 191

    This application has requested the Runtime to terminate it in an unusual way.
    Please contact the application's support team for more information.

9a9c148043f84cab8db68466b2e6a321fe36dcd3

OS: Win7 pro SP1, domain user is local admin

silverwind commented 9 years ago

Seeing this too over SSH, the issue points to SetProcessWindowStation

ttimm commented 9 years ago

I made an interesting observation: This error occurs on a machine that has UAC enabled, yet it does not fail on two machines that have UAC disabled. So this problem with SetProcessWindowStation may be UAC related.

rprichard commented 9 years ago

It might be possible to continue if we can't set the process window station. The only reason it's there is to hide the console window, and there are simpler ways to do that. (IIRC, use SW_HIDE in the STARTUPINFO when starting the agent process.)

IIRC, I originally tried using SW_HIDE instead of setting the window station, but winpty's frequent "Select All" operations (to prevent scrolling while we're reading the console buffer) on the hidden console caused problems on Windows XP. Something like: while winpty is in use, visible console windows cannot be moved.

Windows XP does not have UAC, though, so perhaps we can continue using SetWindowProcessStation there, but use a simple hidden window on newer OS's. An interesting case might be Windows Vista, which has UAC but does not have conhost.exe split out from csrss.exe.

basinilya commented 9 years ago

No need to hide console window. It's already hidden, because it's a windows service

rprichard commented 9 years ago

I changed winpty so that it charges ahead if the CreateWindowStation call fails. https://github.com/rprichard/winpty/commit/6e696f8828e9e942c5bcd93c683c03ac10c531f6

rprichard commented 9 years ago

So far, I haven't been able to reproduce this issue. I suspect my CreateWindowStation change may have fixed it, though. I ran into a problem trying to SSH into Windows 10 that I fixed with this additional change to stop setting lpDesktop when no window station is created (https://github.com/rprichard/winpty/commit/e19c29bd03f8420dcd18e4b8bc4a3963ca299dc5).

I am getting a strange error, though, from cmd.exe:

rprichard@vbwin7 ~/proj/winpty/winpty
$ build/console.exe cmd
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
Not enough storage is available to process this command.

C:\rprichard\proj\winpty\winpty>
basinilya commented 9 years ago

On 24 Aug checked on laptop with Win7 home and UAC, didn't work. Now trying on Win7 pro, domain, no UAC - works.

rprichard commented 9 years ago

I'm using Windows 7 Ultimate SP1 32-bit, and it's working for me. I set the User Account Control to the highest of the four options, "Always notify me when:". I tried using my normal Administrator account and also with a test account that wasn't an administrator. So far I haven't gotten it to fail.

I checked in a program, winpty-debugserver.exe that might be helpful in debugging. Compile it with make all / make install. Run it and console.exe on the same computer and under the same Windows account. Before starting console.exe, set WINPTY_DEBUG to 1.

Here's what that looks like when I SSH into a computer and run console.exe:

SSH client output:

rprichard@ryan:~$ ssh rprichard@192.168.1.51
rprichard@192.168.1.51's password: 
Last login: Thu Oct  1 03:53:47 2015 from 192.168.1.50

rprichard@vbwin7 ~
$ export WINPTY_DEBUG=1

rprichard@vbwin7 ~
$ console cmd
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
Not enough storage is available to process this command.

C:\rprichard>exit

debugserver output:

rprichard@vbwin7 ~
$ winpty-debugserver.exe
[89640.645 console.exe,p2324,t4244]: Created agent successfully, pid=2388, cmdline="C:\cygwin\usr\local\bin\winpty-agent.exe" \\.\pipe\winpty-2324-1-control \\.\pipe\winpty-2324-1-data 134 56
[89640.662 winpty-agent.exe,p2388,t1352]: Agent starting...
[89640.662 winpty-agent.exe,p2388,t1352]: setConsoleFont: attempting to set console font to 6px Lucida Console
[89640.679 winpty-agent.exe,p2388,t1352]: setConsoleFont: cur font: fontex.nFont=8
[89640.679 winpty-agent.exe,p2388,t1352]: setConsoleFont: cur font: fontex.dwFontSize=8,14
[89640.679 winpty-agent.exe,p2388,t1352]: setConsoleFont: cur font: fontex.FontFamily=54
[89640.679 winpty-agent.exe,p2388,t1352]: setConsoleFont: cur font: fontex.FontWeight=400
[89640.679 winpty-agent.exe,p2388,t1352]: setConsoleFont: cur font: fontex.FaceName=Lucida Console
[89640.679 winpty-agent.exe,p2388,t1352]: setConsoleFont succeeded
[89640.679 winpty-agent.exe,p2388,t1352]: setConsoleFont: final font: fontex.nFont=1
[89640.679 winpty-agent.exe,p2388,t1352]: setConsoleFont: final font: fontex.dwFontSize=4,6
[89640.679 winpty-agent.exe,p2388,t1352]: setConsoleFont: final font: fontex.FontFamily=54
[89640.679 winpty-agent.exe,p2388,t1352]: setConsoleFont: final font: fontex.FontWeight=400
[89640.679 winpty-agent.exe,p2388,t1352]: setConsoleFont: final font: fontex.FaceName=Lucida Console
[89640.679 winpty-agent.exe,p2388,t1352]: connection to [\\.\pipe\winpty-2324-1-control], handle == 0x3c
[89640.679 winpty-agent.exe,p2388,t1352]: connection to [\\.\pipe\winpty-2324-1-data], handle == 0x48
[89640.679 winpty-agent.exe,p2388,t1352]: CreateProcess: success 4884
[89643.078 winpty-agent.exe,p2388,t1352]: Closing data pipe after data is sent
[89643.095 winpty-agent.exe,p2388,t1352]: Agent shutting down
[89643.095 winpty-agent.exe,p2388,t1352]: Agent exiting...
basinilya commented 9 years ago

Checked on laptop. Now it's really fixed

silverwind commented 9 years ago

I think it could be related to Cygwin permissions too. If I ssh using my real user account, it works. If I ssh using the SYSTEM user, it fails. I'll retest soon.