Problem with RunWait

[mueer01]

Hello,

I can successfully run the examples

RunWait("notepad.exe", "")
or
RunWait("mspaint.exe", "")

But I always get the Error "1932: WinExec: Function Failed" when I try

RunWait("SnippingTool.exe", "")
or
RunWait("c:\Windows\System32\SnippingTool.exe", "")

All 3 executables exist in c:\Windows\System32
What's different with snippingtool.exe ?

Regards,
Erhard

[td]

The RunWait function often offers detailed information on an error 1932 by pressing the "More Error Info" button. If the button is enabled when the error pops up, press it to see more about the cause.

On my Windows 11 system, RunWait launches SnippingTool.exe without issue as long as I do not include the path. This is because the exe is not in the "System32" directory. It is in the WindowsApp directory "C:\Program Files\WindowsApps\Microsoft.ScreenSketch_11.2310.54.0_x64__8wekyb3d8bbwe\SnippingTool"

[td]

SnippingTool.exe is a "managed" application. There are multiple reports of unpredictable behavior when launching MSFT provided managed applications in different contexts. For example, on Windows 11 Notepad.exe launches without issue using either Run or ShellExecute from a script. However, if you attempt to launch it from a restricted admin account and the Windows UI shell (think a FileMenu menu file), it only starts if you use the Run function. This is not a WinBatch problem per se. Several developer forums report similar problems with managed apps and other products but MSFT has not documented nor addressed it. The worst part is that the behavior can vary from OS version to OS version and feature release to feature release. The variability is another indicator that the problem is likely a Windows bug or bugs.

[ChuckC]

That's where UWP [Windows Store] apps are stored on disk.

Over time, Microsoft has been converting many well known built in programs from regular Win32 desktop applications into UWP apps, so their location on disk has changed, say, going from Windows 8.1 to Windows 10 & newer [e.g., Calculator], or just from Windows 10 to Windows 11 [e.g., Notepad].  In some cases, even the program file name changes [e.g., "calc.exe" -> "CalculatorApp.exe"].

Windows has a highly convoluted algorithm it uses to find program files not fully qualified by a full path, and anything under "C:\Program Files\WindowsApps" cannot be directly launched by its program file name using CreateProcess(), etc.  However, there may be "execution aliases" present for backwards compatibility.  An execution alias can exist in 2 different forms; one is a special kind of reparse point that appears as if it were a program file but with a zero length, while the other is actually a stub form of a Win32 desktop application containing code which invokes the COM App Launcher interface to launch a UWP app.  For the reparse point, there is UWP app launching information embedded in the reparse data and various Win32 API functions used to launch apps know how to utilize the reparse data to launch the associated UWP app.

The big take away w/respect to UWP apps is that there can be multiple programs getting launched in sequence and so RunWait() may end up failing anyway as the first program launched will launch a second program and then terminate immediately.

[td]

I have found that some Microsoft provided managed applications (a.k.a. Windows Store Apps for marketing reasons) do launch using CreateProcess based functionality depending on context (see the above description of NotePad.exe) without a sub executable in System32. But the real problem is the inconsistency of the behavior - some MSFT managed applications do launch using CreateProcess and others require ShellExecuteEx. For example, SnippingTool.exe does not have a stub exe on Windows 11 but does launch using the WinBatch Run command without a path.

[ChuckC]

It may be tied to whether they are of the "fully trusted" type, of which only a subset of Microsoft's UWP apps qualify for.  All fully trusted UWP apps are capable of being run elevated with admin rights, while basic UWP apps can only run restricted in a sandbox subject to capability access checks being performed for every resource access via a companion instance of "runtimebroker.exe" which actually makes the low-level API calls to open handles to different resources.  In a nutshell, a fully trusted UWP apps makes full use of the WinRT presentation layer but also has full access to the entire Win32 API as well.

The UWP form of Notepad is definitely fully trusted, as is Windows Terminal.  For Windows Terminal, there is an execution alias named "wt.exe" which works for command line launching via any API function that can launch a Win32 desktop application.

[td]

Notepad.exe worked with CreateProcess-based functions for a while. Later it didn't and then it did again on Windows 11. When it stopped working with those functions ShellExecuteEx was the workaround. Then a feature update or two ago that all flipped around. This all happened after Notepad changed from a "native" application to a "managed" application so the switch was not in and of itself the cause of the changed behavior. Running as a restricted admin or elevated admin did not in any of the above cases change the described behavior. This has all the symptoms of a bug.

[mueer01]

Hi all,

many thanks for all your replies.
It's good to know, that the problem was not caused by me.

Merry Christmas,
Erhard

[ChuckC]

One other very important difference between UWP apps and regular Win32 desktop apps is the "scope" of the installation.  Despite the fact that the files for a UWP app are all places in appropriately named folders under "C:\Program Files\WindowsApps" upon first installation by a user, the actual ability to successfully launch the app from different user accounts is predicated upon a per-user installation being performed via the Windows Store or via PowerShell.  Installation of a UWP app by one user, even an administrative user, does not automatically convey to other user accounts on the same computer.

For Win32 desktop apps, installation via an admin user allows for system-wide availability of the entire application, although private user-specific installations are allowed to be performed where the program files end up located under "C:\Users\<profile>\appdata\...".  For example, the Cricut Maker software always performs a per-user installation into the user profile rather than a system-wide installation.

[td]

Hi all,

many thanks for all your replies.
It's good to know, that the problem was not caused by me.

Merry Christmas,
Erhard

You might try the WIL ShellExecuteEx function with and without the "RUNAS" verb in the last parameter. No guarantees it will work. Another test is whether the app will start from the start menu Run item (windows key + R).

I keep a "pristine" version of Windows 10 and 11 as virtual machines on my workstation. On the Windows 11 VM, the SnippingTool.exe file is located under the User\AppData folder instead of under Program Files which is what Chuck mentioned above.

[td]

Just to follow up. On a pristine Windows 11 VM both RunWait and ShellExecuteWait successfully launched "SnippingTool.exe" in the context of either an elevated admin or restricted admin. This is with the SnippingTool installed in the "C:\Users\<USER>\AppData\Local\Microsoft\WindowsApps" folder.