X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 577D7385842C
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1674787470;
	bh=N0FpJEE12JgWjlPukwnQRLwdB9kdA5sBLYjzv9ePoGc=;
	h=Date:Subject:To:List-Id:List-Unsubscribe:List-Archive:List-Post:
	List-Help:List-Subscribe:From:Reply-To:From;
	b=AJaX90UjWDITwn9md/sOl8BXPzwEkqhG2hrBJvLSXkW1/cfX46fTr+zvvK+1y3vD/
	4c35Hwm+8hT7UM12hi0oiunhfTS/ghqhLdgif0lOBNITFvYOKiNFqGYsdzWg1T/tyG
	CvFsGJHrkCytOkd0Tea9bpygKoEQ8jh2l/aJfT9o=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org DFD433858D20
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20210112;
	h=to:subject:message-id:date:from:mime-version:x-gm-message-state
	:from:to:cc:subject:date:message-id:reply-to;
	bh=6f4N+ayl+8uKQVr7aR1MK37n9utyGD3xmJxpRCO6Tb8=;
	b=lR4b9zg+LXqI+2jZeLYenohSV1U06vvpcwoGlAoV8FXux2fxciQ5Ny4OpCVyDv6jvL
	U/cu91TiGmfNFxdxackO+DtfhrHOcGcwB3Aujl275wrfZOfckGagNuCu5y/gwCsHmU2d
	gR+raQGAC2z9SjQLhDK8sp84ddqcSheZg8Y40tBzeRipfQ0V3p4D7mEdL+s5cHRtfNvk
	kQiU9wvKyMfGB2Zs8cZP/I8faEj71c6PSUVMidsQluJK6Xto8WoYs6qiskwQjM/4qVii
	NRkuAG6ITiDd3RRI2Pyz9jtK4xxuMykdB7eOI9yIjfqauvvnUWVTu/CM0HqRDIgpwK9a
	L4XQ==
X-Gm-Message-State:	AO0yUKXANCyS07UDUcAJGVRsdC1VopZfg5aHFMvqhvGDQyZhzPkkJSAx
	28rTu0tgu0SXectIjFEro3IvZCcE5hY6X0JrmIUni3ZeVhalQCmsl9g=
X-Google-Smtp-Source:	AK7set83WhhyCCn/7FWdWT4+oHn8XATlJwrTU7TOTL/3qu2kjZjXqrlREOPUIsKElmyNo2/+iLWftMFAe0sI295ZAuc=
X-Received:	by 2002:a05:6871:b0d:b0:163:28ab:c4ca with SMTP id
	fq13-20020a0568710b0d00b0016328abc4camr666401oab.195.1674787422640; Thu, 26
	Jan 2023 18:43:42 -0800 (PST)
MIME-Version:	1.0
Date:	Thu, 26 Jan 2023 18:43:31 -0800
Message-ID:	<CAGJ7yHC1UxsYeV9dM03+CJiHYyj85opu8yt7tzCzQ9qE8OL4GA@mail.gmail.com>
Subject:	BUG: Log on Scheduled Task invisible/empty window blocks input
To:	cygwin AT cygwin DOT com
X-Spam-Status:	No, score=-0.6 required=5.0 tests=BAYES_00, DKIM_SIGNED,
	DKIM_VALID, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS,
	TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version:	SpamAssassin 3.4.6 (2021-04-09) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Ross Patterson via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Ross Patterson <me AT rpatterson DOT net>
Sender:	"Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

TL;DR: I needed to run a Cygwin process at user log on with highest
privileges to perform some operations that are not allowed any other
way without requiring a UAC prompt.  This results in a window without
any border, close button or any other decoration that is most often
invisible/transparent, sometimes opaque white, and most rarely with
black unusable left/bottom scroll bars.  The window is always on top,
accepts no inputs at all, and blocks input to windows below.  The only
way to get rid of the windows is to kill the scheduled task process or
trigger a UAC prompt.  More details below.

It seems like this probably is a bug, so feel free to consider this a
bug report, but I'm mostly writing this up so others can find it and
my workarounds and hopefully save them some hassle and I probably
won't be doing much followup.  Both the edge cases and observed
results are numerous and each test iteration is time consuming, but
I've done my best to get as complete coverage as I could and to
tightly control conditions for reliable results.

There are a few things I want to do through Cygwin that require
privileges that cannot be attained through a service or a scheduled
task with an "At startup" trigger.  The only way I've found to run the
process with the required privileges without a UAC prompt and without
disabling UAC completely is a scheduled task with these settings:

1. "General" tab: "Run only when user is logged on" = SELECTED
2. "General" tab: "Run with highest priveleges" = CHECKED
3. "Triggers" tab: Add an "At log on" trigger for a "Specific user"

As such I've not tested this behavior with different settings on the
"General" tab.

If I add an action that only executes a native Windows command with
the following:

1. "Program/script" = "timeout"
2. "Add arugments (optional)" = "99999"

...and reboot Windows, then on log on I see a fully decorated and
functional console window with a "Waiting for 99999 seconds, press a
key to continue ..." text prompt.  That window can be switched away
from, IOW is *not* always on top, and doesn't block input to other
windows.

If I change the action to use a Cygwin command directly as follows:

1. "Program/script" = "C:\tools\cygwin\bin\sleep.exe"
2. "Add arugments (optional)" = "99999"

...and reboot Windows, then on log on I see a similar console but with
the empty/blank Cygwin `$ sleep` output.

If I change the action to run the desired Cygwin command *through*
Cygwin's `$ run ...` command as follows:

1. "Program/script" = "C:\tools\cygwin\bin\run.exe"
2. "Add arugments (optional)" = "sleep 99999"

...and reboot Windows, then on log on I observe one of two different
conditions.  Rarely, I see an opaque white window with black
left/bottom scroll bars and grey rectangle scroll position controls.
The scroll bars are as plain as possible, no rounding, shading, 3D
effect, etc..  Neither they nor any other part of the window responds
to any input.  The window is always on top as such and blocks input to
all other applications under it.  Most of the time the windows has the
dimensions, behavior and effect but is totally invisible/transparent,
no scroll bars, nothing.  This was the most confounding case until I
understood that it was an invisible window because all the user
observes is that the center of the screen doesn't respond to inputs.
In a 10-foot UI situation in particular, such as a HTPC, this means
only the very edges of other applications underneath it can be seen or
interacted with.  This makes it very difficult to kill the offending
process even through the "Task Manager".  The windows goes away if the
process is killed or if a UAC prompt is triggered.

If I kill the process and then run the task manually through the "Task
Scheduler" UI then the blocking window is recreated.  If I delete the
"At log on" trigger, reboot and then run it manually through the UI,
the blocking window is created then.  However created, if I trigger a
UAC prompt the blocking windows goes away and never comes back even
when I run the task manually through the UI.    This is true even when
I dismiss the UAC prompt without input by hitting `ESC`.  So it seems
like the UAC prompt changes something related to this issue.

If I change the action from to use Cygwin's `$ mintty ...` instead of
`$ run ...` as follows:

1. "Program/script" = "C:\tools\cygwin\bin\mintty.exe"
2. "Add arguments (optional)" = "sleep 99999"

Then a mintty console windows briefly appears but is quickly replaced
with a totally opaque white window with no scroll bars or other
decoration or UI elements that is also always on top and blocks input
as before except this window is positioned in the upper left instead
of the center.

If I add the `$ mintty --window hide` option as follows:

1. "Program/script" = "C:\tools\cygwin\bin\mintty.exe"
2. "Add arguments (optional)" = "--window hide sleep 99999"

Then I don't see the mintty console window and just see the same
totally opaque white window only centered.

If I change the action to run a Cygwin command that forks and
daemonizes as follows:

1. "Program/script" = "C:\tools\cygwin\usr\sbin\ssd.exe"
2. "Add arguments (optional)" = ""

Then no blocking window is created on log on but is created on the
first connection to SSH if the first connection happens right away.
If the first connection is made some time later after log on, however,
then sometimes no blocking window is created while other times one is.

If I change the command to something that doesn't fork and daemonize
on launch as follows:

1. "Program/script" = "C:\tools\cygwin\usr\sbin\ssd.exe"
2. "Add arguments (optional)" = "-D"

Then a fully functional Windows console is created, as with running
Cygwin's `$ sleep` directly above, and connections to `# sshd` do not
create blocking windows.

If I go back to the daemonizing/forking process but change the trigger
to delay for 15 minutes, after the reboot I observe some sort of
middle ground.  There's still a quasi-dead area for responding to
mouse input, but it seems that if I move the mouse slow enough, or
some other factor I'm not perceiving, then it responds
slowly/partially.  If I kill the process, other applications return to
full responsiveness to mouse motion.  That's it, I'm done, screw this
noise!  ;-)

Versions:

$ cygcheck.exe -s
...
Windows 11 Professional Ver 10.0 Build 22623
...
Cygwin DLL version info:
    DLL version: 3.3.6

Dear FSM, please let this be useful to someone!
Ross

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -