A student sees the following error when running a workflow for the second time.
Yep, first time runs fine, second time it won’t run.
Edit: change actual name to just name
Error] System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
—> System.IO.FileLoadException: Could not load file or assembly ‘C:\Users\name\Documents\UiPath\Working with Files.local\install\Working with Files_Expressions_Main.dll’. An Application Control policy has blocked this file. (0x800711C7)
at Working_with_Files.Main..ctor()
at Working_with_Files.Main..ctor()
at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean wrapExceptions)
— End of inner exception stack trace —
at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean wrapExceptions)
at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object args, CultureInfo culture)
at System.Activator.CreateInstanceInternal(String assemblyString, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object args, CultureInfo culture, Object activationAttributes, StackCrawlMark& stackMark)
at System.Activator.CreateInstance(String assemblyName, String typeName)
at UiPath.MapFilePathToActivity_93063903935340c8aab522ec692cb083.MapFilePathToActivity(String relativePath)
at UiPath.Executor.WorkflowLoader.GetWorkflowActivity(String xamlRelativePath, Assembly assembly) in D:\a\1\s\Robot\UiPath.Executor.Core\NetCore\WorkflowLoader.cs:line 112
at UiPath.Executor.WorkflowLoader.<>c__DisplayClass14_0.b__0(WorkflowFile workflowFile) in D:\a\1\s\Robot\UiPath.Executor.Core\NetCore\WorkflowLoader.cs:line 86
at System.Collections.Concurrent.ConcurrentDictionary2.GetOrAdd(TKey key, Func2 valueFactory)
at UiPath.Executor.Core.WorkflowBuilder.Build() in D:\a\1\s\Robot\UiPath.Executor.Core\WorkflowBuilder.cs:line 79
at UiPath.Executor.RobotRunner.BuildWorkflow() in D:\a\1\s\Robot\UiPath.Executor.Core\RobotRunner.cs:line 360
at UiPath.Executor.RobotRunner.InitWorkflowApplication() in D:\a\1\s\Robot\UiPath.Executor.Core\RobotRunner.cs:line 344
at UiPath.Executor.RobotRunner.ExecuteJob(Boolean preLoaded) in D:\a\1\s\Robot\UiPath.Executor.Core\RobotRunner.cs:line 629
“An Application Control policy has blocked this file.”
This appears to be a Windows security or Application Control policy issue rather than a UiPath workflow issue.
Please ask the IT administrator to check whether AppLocker, Windows Defender Application Control (WDAC), or another security policy is blocking the generated _Expressions_Main.dll file.
You can also try:
Close UiPath Studio.
Delete the project’s install folder.
Reopen the project and run it again.
Check whether the project folder or generated DLL files are being blocked by Windows Security/AppLocker.
Try running the project from a different local folder to confirm whether it is a folder or policy restriction.
Since the first run works but the second run fails, the generated assembly may be getting blocked after it is created.
It would also be useful to check the Windows Event Viewer or security logs to identify which Application Control policy is blocking the DLL.
This looks like a Windows Application Control/AppLocker issue. The error specifically says the generated .dll is being blocked.
Try running the project from a different folder. If the issue remains, the IT administrator needs to allowlist the UiPath project/install folder or the generated DLL.
Since the first run works and the second fails, it is likely a security policy rather than a workflow issue.
thanks for all the suggestions guys, but this is a student’s personal pc so there’s no IT admin
I’ll try checking windows security and let you know if I manage to solve it
The most important part of the exception here is actually not TargetInvocationException or the UiPath workflow stack trace.
It’s this:
An Application Control policy has blocked this file. (0x800711C7)
And the file being blocked is the generated:
_Expressions_Main.dll
Since the workflow runs successfully the first time and fails on the second run, I’d investigate the Windows application-control/security layer rather than the workflow itself.
I’d check:
Windows Event Viewer → CodeIntegrity / AppLocker-related logs
Whether WDAC/AppLocker or another endpoint security product is blocking the generated DLL
Whether the UiPath project is running from a folder covered by an application-control policy
Whether moving the project temporarily to another local directory changes the behaviour
Whether deleting the .local\install output and rebuilding causes the DLL to be generated again before being blocked
If this is a managed/student machine, I’d also ask the administrator whether a recent security policy was applied.
The fact that the first execution succeeds but the second fails makes me particularly interested in what happens to the generated DLL between those two executions.
If you can share the corresponding CodeIntegrity/AppLocker event for the blocked DLL, that should tell us much more than the UiPath stack trace.
we checked event viewer and found the following in :
Microsoft → Windows → CodeIntegrity → Operational
Code Integrity determined that a process (\Device\HarddiskVolume3\Program Files\UiPathPlatform\Robot\26.0.201-cloud.24739\UiPath.Executor.exe) attempted to load \Device\HarddiskVolume3\Users\RPala\Documents\UiPath\Working with Files\.local\install\Working with Files_Expressions_Main.dll that did not meet the Enterprise signing level requirements or violated code integrity policy (Policy ID:{0283ac0f-fff1-49ae-ada1-8a933130cad6}).
Code Integrity determined that a process (\Device\HarddiskVolume3\Program Files\UiPathPlatform\Robot\26.0.201-cloud.24739\UiPath.Executor.exe) attempted to load \Device\HarddiskVolume3\Users\RPala\Documents\UiPath\Working with Files\.local\install\Working with Files_Expressions_Main.dll that did not meet the Enterprise signing level requirements
same opcode
the dependency is system activities, version 26.8.0 latest causes this issue, the old version 22.10.4 does not produce the issue.
That’s a very useful finding. At this point we can narrow this down considerably.
The Code Integrity event confirms that Windows is blocking the generated _Expressions_Main.dll when UiPath.Executor.exe tries to load it:
...\.local\install\Working with Files\_Expressions\_Main.dll
And the fact that changing UiPath.System.Activities from 26.8.0 to 22.10.4 makes the problem disappear is a strong indication that the issue is related to the newer package/runtime combination rather than the workflow itself.
I would do one more controlled test before settling on the workaround:
1. Try 26.8.1 if it is available in your feed.
UiPath released System Activities 26.8.1 on September 4, shortly after 26.8.0. The current release notes show that 26.8.1 contains fixes for issues introduced in 26.8.0.
2. If 26.8.1 still produces the same Code Integrity event, keep the 22.10.4 version as the known-good baseline.
3. Compare the generated _Expressions_Main.dll between the working and failing versions, if possible. The important question is whether the assembly generated/loaded with 26.8.0 has different signing/metadata characteristics that cause the Enterprise Code Integrity policy to reject it.
4. Keep the Code Integrity event details, especially the Policy ID:
{0283ac0f-fff1-49ae-ada1-8a933130cad6}
That gives you something concrete to provide to UiPath Support if 26.8.1 doesn’t resolve it.
So I agree that the System Activities version is now the strongest lead. I just wouldn’t classify 26.8.0 itself as the confirmed root cause until we test 26.8.1 or reproduce the same behaviour in another environment with the same Code Integrity policy.
Nice investigation — the Event Viewer entry was much more useful than the original UiPath exception.
0x800711C7 points to Windows Smart App Control or Code Integrity blocking the generated UiPath expression DLL. I’d confirm the block in Windows Security first and test with a current UiPath.System.Activities version before changing SAC settings, since turning SAC off is not easily reversible.
Thanks for your response … which is interesting, because we are using the latest version, that at the same time is causing different issues leading to the suggestion that we should use version 24 - I think someone else suggested version 22.
Will these bugs be fixed do you think, or are you suggesting it’s actually windows that is at fault here?
Hi @Nick_Scott, it’s Windows doing the blocking, so I wouldn’t wait on a package fix. Smart App Control only loads code that Microsoft trusts or that’s signed, with no per-app exception, and the DLLs Studio compiles for each project are unsigned unless you set a Dynamic DLLs Certificate under Settings > Locations. On your own PC, the practical fix is turning Smart App Control off in Windows Security > App & browser control, and recent Windows updates let you turn it back on later without reinstalling. Studio settings
