SSIS Issue
Hello,
I am experiencing an issue when running SSIS packages via a Windmill worker.
The package runs perfectly locally on the VM using the account zvmfrtwsp01\claranet.
When I run the exact same package via a Windmill worker (started with the same account), the execution fails with the following error:
Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
This error comes from an SSIS Execute SQL Task that uses ADO (msado15.dll).
I have checked: the DLLs are properly registered, the package is launched in 32-bit mode (dtexec.exe x86), and the environment PATH is the same in both contexts (all Sybase and SQL Server DLLs are accessible).
A PowerShell test with New-Object -ComObject "ADODB.Connection" works correctly via Windmill, so the ADO COM object itself is available.
In summary:
👉 The issue only occurs when the SSIS package is executed by a Windmill worker, while it works locally with the same account and the same dtexec.exe binary.
👉 This strongly suggests that the Windmill worker is running in a context that does not have full access to the COM runtime (for example, a non-interactive service context).
Could you please confirm if Windmill workers run in a restricted environment for COM/DCOM, and if there is an option or configuration to grant them a full execution context (equivalent to an interactive session)?
Thank you for your help.
11 Replies
@Alain you're running the binary directly? We're not familiar with COM/DCOM but one particularity is that we clear the env variable and then fill it properly. I assume COM/DCOM require some env variable to be passed from context?
if you clear the env before running that powershell program, can you reproduce the windmill error? what env variable do you need to add to make it work again?
Yes, when I run the binary directly, it works locally, but fails in Windmill.
I checked, and the issue seems related to environment variables being cleared. Can we configure the worker to preserve envt variable ? I tried to inject envt variables before dtexec command but it still doesn't work 🙁
No but you can display the env variables when it works and it will be helpful to us
And if you can clear the env and isolate which one is responsible that would be most helpful
When I tried locally :
When I Tried with windmill worker :
Before running it locally, you can clear the env (not sure what command it is on PowerShell) and reproduce the error
Then you can add back env variable one by one until you have isolated the correct one
Hi Ruben,
Following our thread, I found the root cause and a reliable workaround.
Symptom
Running an SSIS package via a Windmill worker (same Windows account as local) failed with:
Class not registered (HRESULT: 0x80040154 REGDB_E_CLASSNOTREG)
This occurred in an Execute SQL Task returning a Full result set (which uses ADO/OLE DB COM ADODB.Recordset). The same package ran fine locally.
Root cause
Windmill workers start with a cleaned environment. SSIS + ADO/OLE DB + Sybase/SQL providers rely on several environment variables (e.g., SYBASE, SYBASE_OCS, INCLUDE, LIB, and a fully populated PATH) to load their COM/Native dependencies in the 32-bit dtexec context. With the env cleared, COM activation during the “Full result set” step failed.
Fix / Workaround
I now re-inject my full environment at the start of the PowerShell script the worker runs:
From a working local session, I exported all env vars to JSON.
In the worker script, I import that JSON and set each variable into the process environment (I merge PATH instead of overwriting it),.
After injecting the environment, the package runs successfully in the worker.
Request / Suggestion
Could you provide an option to:
preserve or inherit the user’s environment for a worker job, or
allow configuring a per-worker (or per-job) environment map (whitelist) that gets injected before execution?
This would avoid having to ship a custom env bootstrap in each script.
Thanks a lot
can you just let us know which env variables are required, we will not inject the full env but we can whitelist a few
Sorry Ruben, I didn't have time to test the variables needed for proper execution.
if we can whitelist them selectively, it will allow it to work ootb without requiring any configuration
ok ruben, i will keep you informed when we do further tests