Hi @ayoshino
thank you for the outstanding write-up - your analysis is exactly right, and we’re sorry this hit a production run.
-
Yes, the launch method changed. The Desktop Automation XModule was rewritten from .NET to a new native host (the 2.x line your 10.0.178 installer bundles). The old host launched processes through .NET’s Process.Start, which by default goes through ShellExecute — that resolves Windows file associations, which is the only reason a bare .vbs as Target ever worked. The new host launches the Target directly via CreateProcess, which never resolves associations, so a script file as Target now fails with exactly the error 193 you saw. As you found, no official example ever used a script file as Target - it was undocumented behavior that worked by accident. But we fully agree that’s cold comfort when a years-old production macro breaks.
-
With the next XModule update it stays strict, but it will explain itself. We considered auto-wrapping script Targets (e.g. via cmd /C), but that reintroduces association lottery and cmd metacharacter parsing on the arguments — a worse class of surprise. Instead, the next XModule release (2.0.13) turns the raw OS error into a self-explaining message: it tells you the Target is a script, that XRun/XRunAndWait launches Targets directly without association lookup, and prints the exact corrected command line for your file (for .vbs:
cscript.exe | "C:\...\UpdateHtml.vbs" <arguments>, with a note to use wscript.exe if the script shows MsgBox/InputBox dialogs). We’ll also update the XRun/XRunAndWait docs to state explicitly that Target must be a real executable and the script belongs in the parameters, and add a changelog note about this behavior change.
Your workaround is the correct permanent fix, not just a stopgap — cscript.exe as Target with the quoted script path in the parameters is the documented pattern, and ${!xrun_exitcode} works exactly as before. One small tip: adding //nologo keeps the cscript banner out of captured output if you ever read it.
- Version pinning: the native XModule host never self-updates, it only changes when an installer is run, so keeping your validated installer effectively pins it. The browser extension auto-updates through the store, we can not change this. The solution is to use a PRO license with upgrade protection or simply use Firefox, which allows blocking extension updates.
Thanks again for taking the time to diagnose this so thoroughly and for flagging it for other users - reports like this one are gold! 