打盹的泡面 · 15省份修改计生条例 北京产假最多可休7个月· 1 月前 · |
活泼的钱包 · Super Cap 超級電容 - ...· 3 月前 · |
活泼的钱包 · Excel或者Word如何实现自动匹配关键词 ...· 5 月前 · |
温柔的汽水 · 要在您的自定义函数中使用 Fortran· 5 月前 · |
Get a customized tour of VisualCron’s automation, integration, and task scheduling capabilities.
Request a DemoExplore VisualCron’s full power at your own pace with a free, all-access trial for 30 days.
Start Free TrialGet a customized tour of VisualCron’s automation, integration, and task scheduling capabilities.
Request a DemoExplore VisualCron’s full power at your own pace with a free, all-access trial for 30 days.
Start Free TrialI think the FAQ in this case might be old but more important, not relevant to all errors reporting "Access denied".
Originally Posted by: Support
Please explain what Task type you are talking about and if you use an AD user or not. And what settings you use at the moment in the Credential.
This is a really big subject. Before digging deeper I wonder if you get the same error if you create a local Administrator instead of using AD. At least we can rule out some things then.
Hi Henrik,
We discovered we need to check Local Login (to ensure thread identity works correctly), so we are doing that now. In addition, we tried "Use Win32 API CreateProcessAsUserW" but the error is still happening.
We thought about changing the VisualCron service account to run as the domain account and remove all special logon credentials for tasks and just letting it run as the service account, but you explicitly stated to another VisualCron user 2 months ago that this is a really bad idea (https://www.visualcron.com/forum.aspx?g=posts&t=7729: "It is not recommended to change the default SYSTEM account for VisualCron.")
Again... what else would you recommend?
I still have a hunch that the underlying problem is VisualCron is somehow exhausting the desktop heap/workstation heap space. But without VisualCron engineers debugging or giving us pointers, this is very hard to confirm.
Any update here Henrik on what we need to do get this error resolved? We facing this error multiple times per day in production and need to determine if VC is capable of running a large number of execute tasks in background mode with a credential. Happy to provide logs or other data to help your team troubleshoot the issue.
I realize the access denied error is the direct result returned by the OS. Are you aware of any limitations on the number background jobs that can be created calling CreateProcessWithLogonW? I did see this in the documentation:
There is a limit to the number of child processes that can be created by this function and run simultaneously. For example, on Windows XP, this limit is MAXIMUM_WAIT_OBJECTS*4. However, you may not be able to create this many processes due to system-wide quota limits.
But this seems to happen when we have 10-20 concurrent jobs running where the limit in documentation is 265 (64*4), so I don't believe this is the issue. Is it possible that this could be related to a threading issue in VC when these WIN32 API calls are being executed? Have you been able to reproduce this issue using a credential with the same settings and running several hundred execute jobs?
We have put together a few test cases and believe that using CreateProcessAsUserW is the correct way to be running these in background given this is the only supported option by Microsoft to run a process as another user from a windows server. This also allows us to run the process without loading the profile.
We are running into the issue with the StdOut files not being able to be cleaned up. To reproduce:
Create a local admin account
Grant the user Logon as Batch Job thru local policy
Setup a new credential with Local Login , CreateProcessAsUserW, Logon32_Logon_Batch
Create 10 jobs with 1 Execute task each that trigger every 30 seconds
The execute task for us is a simple C# console app that performs Thread.Sleep for 10 seconds
Run the jobs
The log will show
2/16/2018 11:49:12 PM Err StartBackgroundProcess->Closing of StdOut failed - trying again, file: D:\VisualCRON\Temp\646bd0ee-d0c4-492e-aa01-daeebb954dbc, error: System.IO.IOException: The process cannot access the file 'D:\VisualCRON\Temp\646bd0ee-d0c4-492e-aa01-daeebb954dbc' because it is being used by another process.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
at OBOKIIHBDBPMCFALPGECCIFHCDJPEDKODDGK.CNOMLBFDJANALDAEIKLKHLCGKEJIGMLIMBLK.LDOOOMNBFEMCMJNDHGGHGOGEMOOGMECJLOPG(String , Boolean , Int32 ) in C:\sourcefiles\code\VisualCronService\Jobs\TaskProcesses\Process\clsProcessTaskExecute.vb:line 295
Can you please provide a timeline for a fix?
NOTE: Originally I had wrote CreateProcessAsLogonW but I meant to write CreateProcessAsUserW. I edited the post to correct this
We have put together a few test cases and believe that using CreateProcessAsUserW is the correct way to be running these in background given this is the only supported option by Microsoft to run a process as another user from a windows server. This also allows us to run the process without loading the profile.
Can you please provide a timeline for a fix?
Thank you for your patience. Please try this build:
https://www.visualcron.c....aspx?g=posts&t=7901
Thank you for your patience. Please try this build:
https://www.visualcron.c....aspx?g=posts&t=7901
VisualCron is an automation, integration and task scheduling tool for Windows .
No programming skills. Easy to use interface. Tasks for everything. Programming interface.
Start automating today!
Get Started