From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x36.google.com (mail-oa1-x36.google.com [IPv6:2001:4860:4864:20::36]) by sourceware.org (Postfix) with ESMTPS id DFD433858D20 for ; Fri, 27 Jan 2023 02:43:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DFD433858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rpatterson.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rpatterson.net Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-16332831ed0so4830397fac.10 for ; Thu, 26 Jan 2023 18:43:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rpatterson-net.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=6f4N+ayl+8uKQVr7aR1MK37n9utyGD3xmJxpRCO6Tb8=; b=dtgBj8DqYoYQ3bSjUaBcMf0n2diQBTm1F8mIG//0w9UeYe0DHLkwCfmPi3HaaQ4NW8 u9zkoF26MYF1xWpYSczENt1Hx3ICHKFPlw3O3XB3KiS9GKcpxLmKBoVkoBOXgpfj/FdL Khq2OIMaDaxfpzUskFT1GkfJ0E3TXXcsN9tXLhleKMiT2P2z4kBTrtBwKo0GOzPNv4zc 7kz61VEZsWyaZKwrTLG7Zc4ZV3pY/WhmVI2wIigpsIUM9/wuoXR7YcZq96Bi+v6kxlUd AbpiC/eLg0xTJeSFHZ29dJkT8baedznaxVSA4+2yBTX3pWhktWNL4cWGDmAgeYThwdNT XaJQ== 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 From: Ross Patterson Date: Thu, 26 Jan 2023 18:43:31 -0800 Message-ID: Subject: BUG: Log on Scheduled Task invisible/empty window blocks input To: cygwin@cygwin.com Content-Type: text/plain; charset="UTF-8" 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 List-Id: 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