BUG: Log on Scheduled Task invisible/empty window blocks input

BUG: Log on Scheduled Task invisible/empty window blocks input

[Jason Kim]

Hi,

This particular issue with the invisible windows that pop up seems to be 
a relatively a new issue with cygwin with recent win11.

With a slightly older windows 10, these conhost tasks with their 
invisible windows do not pop up at all (that I've noticed).

And no amount of using "run.exe" to launch seems to help.
Not using Administrator privileges on the shortcut does not seem to help 
either.

All I know is that the same shortcut links and .bat files that worked 
for 10+ years to start x11, start a mintty etc...

are now producing  conhost.exe tasks with windows that are invisble. And 
something triggers these windows to start blocking mouse input. Once 
that happens, ctrl-alt-delete and then pressing escape seems to quiet 
them down (so that mouse selection works again on the blocked areas of 
the desktop, for a short while at least.

Killing the conhost tasks resolves the mouse i/o issue, but it seems to 
interrupt copy/paste of text.

How can I fix this?
Please help!
Thank you
-Jason

Re: BUG: Log on Scheduled Task invisible/empty window blocks input

[Ross Patterson]

On Sun, Jan 29, 2023 at 3:48 PM Brian Inglis <Brian.Inglis@shaw.ca> wrote:
>
> Best to hide that inside a script, rather than deal with mixing Windows and
> shell quoting rules!

Tested and confirmed to be working with other scheduled tasks that exit.

> Services drop privileges to $USER privileges unelevated.

What I'm saying is that the requirement from my OP is that what is run
has highest priveleges from *the windows side* regardless of what
system/tool initially invokes it.

> > Have you tested the first, most simple, test case from my OP?  It's a
> > very elemental test and reproduces the issue reliably for me so it
> > would be interesting to hear what you (or anyone else) observes from
> > that test case.
>
> It is unlikely it will be different: do they matter?

From my experience with software, troubleshooting and support, testing
the simplest possible case is best practice to eliminate variables
*and assumptions*.  That's why my OP starts with such test cases.
It's fine if you don't want to run that test otherwise be helpful, why
don't we let others weigh in.  Thanks anyways!

> Most programs probably use regular startup code that opens the stdio handles,
> whereas most shells support non-interactive operation that doesn't.

I've also tested moving the commands being run into `*.cmd` and
`*.ps1` scripts and running them that way, including various handling
of stdio, all still reproduce the blocking window.

> Doing anything with a console in Scheduled Tasks or any detached background task
> will pop up console windows, perhaps full screen and/or UAC modal if elevated -
> no surprise - don't do that if you don't want to see them!

I don't understand how that's meant to be helpful.  Did you read all
the various cases I detailed?  I cover cases that *do* open functional
console windows and how that's not the issue I'm reporting.

> Use run like XWin startxwin which does not display console windows:
>
> %CYGWIN_ROOT%\bin\run.exe --quote /usr/bin/bash -l -c "cd; exec /usr/bin/startxwin"

See the cases using `> run.exe` in my OP.  Though I haven't tried
adding `$ bash -c` as a layer.  I'll try that out if I get more time
to do more testing.  Thanks for the specific helpful suggestion.

> Services should be started by cygrunsrv elevated so they get the environment
> they expect to run under.

My OP covers why Windows services are not an option, again highest priveleges.

> There are lots of unhelpful interactions between Cygwin and Windows environments
> and programs: you have to pick and choose one and do everything only with those
> programs in that environment. The twain can never (mostly) mix (without effort).

I concur, which is why I cover that running the commands that
ultimately need to be need highest privileges from the Windows side
and that Scheduled Tasks are the only way to do that.  I wouldn't be
messing with this if I could just do this all from inside Cygwin.

> Your tests are play toys: what exactly are you actually trying to do?

Not play toys, they are minimal test cases to reproduce an issue.  In
my experience in software, that's not only preferred but often
surprisingly difficult to get from users reporting issues, so I guess
we just don't see eye to eye.  Thanks anyways!

> and note that all stdio is redirected within the script > /var/log/...log 2>&1,
> < /dev/null if necessary, so that the Windows console is never involved.

Thanks, that's a helpful specific suggestion I'll try when I next get
time to do further testing.

Thanks much for your help, lets let others weigh in and you can have
your time back,
Ross

Re: BUG: Log on Scheduled Task invisible/empty window blocks input

[Brian Inglis]

On 2023-01-29 15:55, Ross Patterson wrote:
>> dash (or bash if required) native path with WD /var/log/ native path e.g.
>> %CYGWIN_ROOT%\bin\dash /usr/local/bin/....sh WD %CYGWIN_ROOT%\var\log

> I'm not understanding the use of `WD` here, can you clarify/elaborate?

Working Directory entry

> At any rate, I forgot to mention that I also tried adding output
> redirection to the end of the action's ""Add arguments (optional)" and
> did so in various combination with the other variants described in my
> OP:
>      ... >> C:\...\log\....log 2>&1
> And I observed the same or similar mix of different blocking window types.

Best to hide that inside a script, rather than deal with mixing Windows and 
shell quoting rules!

>> For normal scripts and schedules, I use cron job commands or scripts which log
>> everything under /var/log/.
> 
> In that case, I'd still need `# crond` to run with highest privileges
> as those are the privileges I ultimately need what it would run to
> have.  But maybe I'll try that if I get time to do more testing.

Services drop privileges to $USER privileges unelevated.

> Have you tested the first, most simple, test case from my OP?  It's a
> very elemental test and reproduces the issue reliably for me so it
> would be interesting to hear what you (or anyone else) observes from
> that test case.

It is unlikely it will be different: do they matter?

Most programs probably use regular startup code that opens the stdio handles, 
whereas most shells support non-interactive operation that doesn't.

Doing anything with a console in Scheduled Tasks or any detached background task 
will pop up console windows, perhaps full screen and/or UAC modal if elevated - 
no surprise - don't do that if you don't want to see them!

Use run like XWin startxwin which does not display console windows:

%CYGWIN_ROOT%\bin\run.exe --quote /usr/bin/bash -l -c "cd; exec /usr/bin/startxwin"

Services should be started by cygrunsrv elevated so they get the environment 
they expect to run under.

There are lots of unhelpful interactions between Cygwin and Windows environments 
and programs: you have to pick and choose one and do everything only with those 
programs in that environment. The twain can never (mostly) mix (without effort).

Your tests are play toys: what exactly are you actually trying to do?

How to successfully run Cygwin scheduled tasks without seeing windows:

>> I use scheduled tasks with actions running scripts from /usr/local/bin/ under
>> dash (or bash if required) native path with WD /var/log/ native path e.g.
>>
>> %CYGWIN_ROOT%\bin\dash /usr/local/bin/....sh WD %CYGWIN_ROOT%\var\log
>>
>> with various options (mainly user SYSTEM, logged in or not, highest privileges),
>> and triggers.
>>
>> I never see any windows appearing as the scripts log everything under /var/log/.
>>
>> The scripts run as tasks start and stop Cygwin services, init and run smart
>> reporting, clean up cron job remnants before smart reporting, terminate all
>> processes before running setup.

and note that all stdio is redirected within the script > /var/log/...log 2>&1, 
< /dev/null if necessary, so that the Windows console is never involved.

Have you tried running a non-interactive script from a non-interactive shell as 
suggested?

-- 
Take care. Thanks, Brian Inglis			Calgary, Alberta, Canada

La perfection est atteinte			Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter	not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer	but when there is no more to cut
			-- Antoine de Saint-Exupéry

Re: BUG: Log on Scheduled Task invisible/empty window blocks input

[Ross Patterson]

> dash (or bash if required) native path with WD /var/log/ native path e.g.
>
> %CYGWIN_ROOT%\bin\dash /usr/local/bin/....sh WD %CYGWIN_ROOT%\var\log

I'm not understanding the use of `WD` here, can you clarify/elaborate?

At any rate, I forgot to mention that I also tried adding output
redirection to the end of the action's ""Add arguments (optional)" and
did so in various combination with the other variants described in my
OP:

    ... >> C:\...\log\....log 2>&1

And I observed the same or similar mix of different blocking window types.

> For normal scripts and schedules, I use cron job commands or scripts which log
> everything under /var/log/.

In that case, I'd still need `# crond` to run with highest privileges
as those are the privileges I ultimately need what it would run to
have.  But maybe I'll try that if I get time to do more testing.

Have you tested the first, most simple, test case from my OP?  It's a
very elemental test and reproduces the issue reliably for me so it
would be interesting to hear what you (or anyone else) observes from
that test case.

Note that the totally invisible/transparent version of the blocking
window is only observable by an area of the display that doesn't
respond to mouse inputs.  Also note that if your display resolution is
high enough, or scaling settings accomplish the same, you need to be
able to look for blocked mouse input all over your screen.  In my case
where it's a 10-foot UI, the default window size blocks most of the
display which makes finding blocked mouse input easy.  I also find it
easiest to test for the presence of the blocking window with something
that responds to mouse over inputs with a clear visual signal across
the whole display, Kodi in my case.

Ross

On Fri, Jan 27, 2023 at 11:39 AM Brian Inglis via Cygwin
<cygwin@cygwin.com> wrote:
>
> On 2023-01-26 19:43, Ross Patterson via Cygwin wrote:
> > 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.
>
> I use scheduled tasks with actions running scripts from /usr/local/bin/ under
> dash (or bash if required) native path with WD /var/log/ native path e.g.
>
> %CYGWIN_ROOT%\bin\dash /usr/local/bin/....sh WD %CYGWIN_ROOT%\var\log
>
> with various options (mainly user SYSTEM, logged in or not, highest privileges),
> and triggers.
>
> I never see any windows appearing as the scripts log everything under /var/log/.
>
> The scripts run as tasks start and stop Cygwin services, init and run smart
> reporting, clean up cron job remnants before smart reporting, terminate all
> processes before running setup.
>
> For normal scripts and schedules, I use cron job commands or scripts which log
> everything under /var/log/.
>
> --
> Take care. Thanks, Brian Inglis                 Calgary, Alberta, Canada
>
> La perfection est atteinte                      Perfection is achieved
> non pas lorsqu'il n'y a plus rien à ajouter     not when there is no more to add
> mais lorsqu'il n'y a plus rien à retirer        but when there is no more to cut
>                         -- Antoine de Saint-Exupéry
>
> --
> 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

Re: BUG: Log on Scheduled Task invisible/empty window blocks input

[Brian Inglis]

On 2023-01-26 19:43, Ross Patterson via Cygwin wrote:
> 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.

I use scheduled tasks with actions running scripts from /usr/local/bin/ under 
dash (or bash if required) native path with WD /var/log/ native path e.g.

%CYGWIN_ROOT%\bin\dash /usr/local/bin/....sh WD %CYGWIN_ROOT%\var\log

with various options (mainly user SYSTEM, logged in or not, highest privileges), 
and triggers.

I never see any windows appearing as the scripts log everything under /var/log/.

The scripts run as tasks start and stop Cygwin services, init and run smart 
reporting, clean up cron job remnants before smart reporting, terminate all 
processes before running setup.

For normal scripts and schedules, I use cron job commands or scripts which log 
everything under /var/log/.

-- 
Take care. Thanks, Brian Inglis			Calgary, Alberta, Canada

La perfection est atteinte			Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter	not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer	but when there is no more to cut
			-- Antoine de Saint-Exupéry

BUG: Log on Scheduled Task invisible/empty window blocks input

[Ross Patterson]

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