Hi everyone, I’m trying to orchestrate a nightly KNIME workflow on a Windows Server using Task Sc...

KNIME Analytics Platform - 4.7.8 (full build, bundled JRE 17)

OS - Windows Server 2019 x64|

Java Embedded JDK 17 in the KNIME package

Workflow - A standard ETL flow that reads/writes to Snowflake and a few local CSVs

I wrote a small batch file to launch KNIME in headless mode. All machine-specific paths have been anonymised below (“

<knime_root>

”, “

<workflow_dir>

”, etc.):

batch

@echo off
setlocal EnableDelayedExpansion
rem ---- absolute paths ----
set "KNIME_==<knime_root>\knime.exe"
set "WORKFLOW=<workflow_dir>\my_workflow"
set "WORKSPACE=<workspace_dir>\workspace_batch"
set "LOG=%WORKSPACE%\run_%date:~-4%%date:~4,2%%date:~7,2%_%time:~0,2%%time:~3,2%%time:~6,2%.log"
rem ---- wipe any GPO-injected heap settings ----
set "_JAVA_OPTIONS="
rem ---- run KNIME ----
"%KNIME_EXE%" ^
-nosplash -consoleLog ^
-application org.knime.product.KNIME_BATCH_APPLICATION ^
-workflowDir="%WORKFLOW%" -reset ^
-data "%WORKSPACE%" ^
--launcher.suppressErrors ^
>> "%LOG%" 2>&1
set RC=%ERRORLEVEL%
if %RC% neq 0 (
echo [%date% %time%] KNIME workflow FAILED with exit code %RC%>>"%LOG%"
) else (
echo [%date% %time%] KNIME workflow completed successfully.>>"%LOG%"
)
exit /b %RC%

What doesn’t

  • When the script is triggered by Task Scheduler (set to “Run whether user is logged on or not”, highest privileges, same user account), KNIME exits almost immediately and Task Scheduler reports return code 4.

  • `knime.log` shows lots of `java.lang.InaccessibleObjectException: Unable to make java.lang.ClassLoader.findLibrary(String) accessible` coming from `DBDriverRegistry$DriverClassLoader`, meaning all built-in JDBC drivers fail to load.

What I already tried

  1. Confirmed `knime.ini` contains all the required `--add-opens` / `--add-exports` flags for Java 17.

  2. Removed `-vmargs` overrides so the INI flags are actually applied.

  3. Cleared any orphaned `.lock` in the workspace.

  4. Added `echo _JAVA_OPTIONS` in the log to prove no rogue heap settings get injected.

  5. Running Task Scheduler job manually (“Run now”) still yields exit 4 with the same driver errors.

Questions

  1. Has anyone else seen exit 4 only under Task Scheduler but not interactively?

  2. Is there a documented way to force Task Scheduler to honour the `--add-opens` directives (or to verify they’re getting through)?

  3. Would exporting the workflow to a `.knwf` ZIP and using `-workflowFile=` make any difference?

  4. Any other tricks (service accounts, “Start in” folder, additional JVM flags) that solved this for you?

Thanks a lot for any pointers!