Environment: - Ui.Vision IDE version: 10.0.178 (the standalone command-line-launched IDE app for Windows, used for scheduled/production runs — not the browser side panel)
- Storage Mode: File system (on hard drive)
- Macro:
DENSO_AIRCOOL\I161_DENSO_AIRCOOL_G01_HENKO_DL (failing inside sub-macro I161_DENSO_AIRCOOL_20_Henko_Search)
Summary: This production macro has been calling an external VBS script directly via XRunAndWait for a long time, using the .vbs file itself as Target (no interpreter specified): XRunAndWait | ${_scrFolder}UpdateHtml.vbs | “${_pLastDate}”
This has always worked. It started failing today (2026-08-31), which lines up with the IDE having updated to v10.0.178 a few days earlier (2026-08-27 per the Chrome Web Store listing for the browser extension of the same version).
Exact error from the log panel:
[error] Line 10 (Sub: I161_DENSO_AIRCOOL_20_Henko_Search): run_failed: C:/Users/webedi/Documents/iMacros/Scripts/UpdateHtml.vbs: %1 は有効な Win32 アプリケーションではありません。 (os error 193) At Line 11 in DENSO_AIRCOOL\I161_DENSO_AIRCOOL_G01_HENKO_DL (English translation of the OS message: “%1 is not a valid Win32 application”, i.e. Windows error 193 / ERROR_BAD_EXE_FORMAT.)
Analysis: Error 193 is a standard Windows CreateProcess error that occurs when the OS is asked to directly execute a file that isn’t a real .exe binary — a .vbs file needs an interpreter (cscript.exe/wscript.exe) to run;
it is not itself a Win32 executable. CreateProcess does not resolve file-extension associations; only ShellExecute (or a shell/cmd wrapper) does.
My working theory:
whatever native-host code previously handled XRun/XRunAndWait resolved the Windows file association for .vbs (so pointing Target directly at the .vbs file “just worked”, effectively like ShellExecute). After the update to v10.0.178, the process-launch code path seems to have changed to a stricter direct-exec method that no longer resolves that association,
hence Error 193. I checked the official XRun/XRunAndWait docs and forum examples for other script types (PowerShell, Python, batch) — they all set Target to an actual executable (Powershell.exe, python.exe, etc.) and put the script path in Value. I could not find any official example using a bare .vbs file as Target, so this specific usage may have always been unsupported/undocumented, and only “worked” because of how the previous native host launched processes.
Workaround that fixed it for me:
Point Target at the script engine explicitly, and pass the .vbs path as an argument in Value
instead: XRunAndWait | C:\Windows\System32\cscript.exe | “${_scrFolder}UpdateHtml.vbs” “${_pLastDate}”
(use wscript.exe instead if the script shows GUI dialogs such as MsgBox/InputBox). ${!xrun_exitcode} still works as expected.
Questions for the team:
1. Can you confirm whether the process-launch method for XRun/XRunAndWait changed around v10.0.178 (e.g. from an association-aware launch to a direct CreateProcess-style launch)?
2. If this is an intentional/permanent change, could the docs explicitly state that Target must always be a real .exe (interpreter), and that a bare script file (.vbs, .py, etc.) as Target is not supported? This broke a production automation running for years without warning.
3. Is there any way to pin/lock an IDE or extension version for production environments, so an update like this doesn’t silently break running macros?
A changelog note about this kind of breaking change would also help a lot.
Happy to share more logs/screenshots if useful.
Thanks for the great tool — flagging this so others don’t hit the same production outage after updating.
Best Regards,
Akira Yoshino
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.