Hi everyone, I’m trying to orchestrate a nightly KNIME workflow on a Windows Server using Task Scheduler. The set-up:

KNIME Analytics Platform
1

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!