InvokeWorkflowFile fails with "Application Control policy has blocked this file (0x800711C7)" when loading compiled child workflow DLL

Help Studio
1

I’m getting a runtime error when invoking a child workflow via Invoke Workflow File. This started after editing the child workflow (PortalDispatch.xaml) — other child workflows in the same project still invoke fine.

Error:

PortalDispatch - Invoke Workflow File (ChildPortals\PortalDispatch.xaml): 
Could not load file or assembly 
'C:\Users\HP\Documents\ui-path-GeneralMasterWorflow\.local\install\Gener
![Screenshot (283)|690x388](upload://xNBruak0oKBOReXMRQmtak0ssLX.png)
alMasterWorkflow.ChildPortals_PortalDispatch.dll'. 
An Application Control policy has blocked this file. (0x800711C7)

Setup:

  • UiPath Studio (Windows), project uses a GeneralMasterWorkflow → PortalDispatch.xaml dispatcher pattern, invoking multiple child workflows under ChildPortals\
  • UiPath.UIAutomation.Activities = 26.10.0, UiPath.System.Activities >= 26.6.1
  • Project folder: C:\Users\HP\Documents\ui-path-GeneralMasterWorflow\
  • Windows 11 Pro, company-managed machine

What I’ve checked so far:

  • The .xaml itself is valid — re-verified structure, no corruption from the edit
  • InvokeWorkflowFile correctly points to ChildPortals\PortalDispatch.xaml
  • Error only appeared after this specific child workflow was edited/recompiled; other ChildPortals\*.xaml invocations still work fine
  • Checked Windows Security → App & browser control: Reputation-based protection is off; Smart App Control shows no clear on/off toggle (likely centrally managed, not locally controllable)
  • Deleted .local\install to force a clean recompile — [state result once tried]

My IT team’s response: I raised this with our internal IT support team, and they’ve stated this is an application-side issue, not a Windows/network security policy on their end. I’m not fully clear whether they mean this needs a UiPath Studio-side fix, or whether it’s a different security/endpoint product (antivirus/EDR) flagging it independently of standard Windows Application Control (WDAC). Posting here to get clarity on whether this is something fixable from the UiPath project/Studio side, since the error text itself (“Application Control policy”) appears to be an OS-level message rather than something UiPath generates.

Question:
Has anyone run into Application Control blocking the auto-compiled .dll for an Invoke Workflow File target after editing the source .xaml? Specifically:

  1. Is there anything on the UiPath/Studio side that could trigger this independent of Windows WDAC/AppLocker (e.g., digital signing of compiled workflow DLLs, Studio trust settings)?
  2. Is there a known way to get UiPath to reuse/sign the compiled DLL consistently so it doesn’t get re-flagged on every recompile?
  3. Any recommended project folder location/practice that avoids this?

version was latest verison

2

@Ravi_Gandroli

Did you tried by deleting the invoke workflow and readding again.
And ensure that xaml file location is inside of your project folder, if already inside then change the location and try.