Automation Anywhere A360 Capture Command Crashes on Windows Server 2019: Causes and SFC /Scannow Fix

Overview of the Issue

Automation Anywhere’s Automation 360 (A360) platform includes a Capture command (part of the Recorder package) used for capturing interactions with on-screen controls. In A360 build 21023 running on Windows Server 2019, some developers have encountered the Capture command crashing or failing unexpectedly. The issue is perplexing because it persists even after trying typical fixes on the Automation Anywhere side. In such cases, the surprising solution has been to repair the Windows operating system itself using the System File Checker (SFC) tool (sfc /scannow). This article dives into why the Capture action might crash on Windows Server 2019, what underlying causes are at play, and how running SFC resolved the problem when other remedies did not.

Failed Troubleshooting Attempts (Bot Agent Reinstall, Cache Clear, etc.)

When the Capture command begins to crash, Automation Anywhere developers and IT support personnel typically attempt a series of troubleshooting steps at the application level. Common approaches include:

• Reinstalling or updating the Bot Agent service – This ensures the RPA runtime (the Automation Anywhere Bot Agent) is properly installed. For example, Automation Anywhere support often suggests uninstalling and then re-installing the Bot Agent service to rule out any installation corruption. In practice, this involves stopping and deleting the “Automation Anywhere Bot Agent” Windows service and then reinstalling the agent fresh.
  
  
• Clearing the A360 global cache – The “global cache” is a local folder where Automation Anywhere caches bot packages and dependencies. Deleting or renaming this cache (and then restarting the Bot Agent) forces the system to fetch clean copies of any needed files. This can resolve issues where a bot package or dependency was corrupted or stuck in an incorrect state.
  
  
• Other standard fixes – These might include rebooting the server, clearing user-level Automation Anywhere temp data (like the registration.properties file as suggested by support), ensuring the A360 browser extensions are properly installed, or checking for any error logs in the Automation Anywhere Control Room.
  
  

In the scenario at hand, none of these application-level fixes resolved the crashing Capture command. The Bot Agent reinstallation and cache clearing had no effect – an indication that the root cause might not be within the Automation Anywhere software itself. Indeed, a support engineer eventually advised escalating the issue, suspecting something deeper in the environment. This set the stage for a deeper investigation into the Windows Server 2019 system itself.

Root Cause Analysis: Windows System File Issues

The fact that Automation Anywhere’s Capture action was still crashing after reinstalls and cache resets strongly pointed to a problem underlying the application, i.e., the Windows OS environment. Automation Anywhere’s Capture command isn’t a self-contained magic; under the hood it relies on Windows APIs and components to identify and interact with UI elements. In particular, A360’s Recorder and Capture functionality leverage Microsoft’s accessibility and UI automation frameworks. According to Automation Anywhere’s documentation, the universal recorder can interface with Microsoft Active Accessibility (MSAA) and Microsoft UI Automation technologies for recognizing controls. These frameworks are built into Windows and involve a number of system DLLs and components (for example, oleacc.dll for Active Accessibility and UIAutomationCore.dll for UI Automation).

If any of those underlying Windows components are missing, corrupted, or improperly registered, the Capture operation can fail or even crash the bot runner. In this case, evidence pointed to exactly that: a corrupted system file on the Windows Server was breaking the Capture command. Notably, experienced users have reported that certain Windows DLL issues can disrupt applications in strange ways. For example, a missing or damaged Oleacc.dll (the Active Accessibility core library) can prevent multiple applications from running properly – one Windows user noted that an “oleacc.dll is missing” error crippled several programs, and only running System File Checker fixed it. This aligns with our scenario: if the server’s accessibility/automation libraries were compromised, any RPA action depending on them could crash.

Another hint comes from Microsoft’s guidance on UI Automation errors. In one case, after a Windows 10 upgrade, users experienced repeated crashes in UIAutomationCore.dll, which is the core Windows UI Automation library. Microsoft’s recommended steps included checking for driver issues and, importantly, running SFC to repair system files. This shows that corrupted system files in the UI Automation pipeline can indeed cause crashes, and Microsoft explicitly advises using System File Checker to address such problems.

In summary, the root cause of the Capture command crashes was traced to Windows system file integrity issues on the Server 2019 machine. The Capture action likely invoked a Windows API that was failing due to a bad system DLL or resource. Since reinstalling the Automation Anywhere Bot Agent doesn’t replace or repair Windows DLLs, those efforts had no effect. This hypothesis was confirmed when the solution turned out to be fixing the Windows system itself.

Using SFC /Scannow to Repair Windows and Resolve the Crash

For example, running the SFC /scannow command in an elevated Command Prompt will initiate a scan of all protected system files. The tool checks the integrity of each file and automatically replaces any corrupted copies with the correct version from Windows’ cached repository. In the screenshot above, SFC has completed a scan (Verification 100%) and reported no integrity violations. If corrupt files were found, the output would instead state “Windows Resource Protection found corrupt files and successfully repaired them,” or indicate if some files could not be fixed.

System File Checker (SFC) is a built-in Windows utility designed precisely for scenarios like this. When you run sfc /scannow on a machine, the tool scans all protected operating system files and replaces any corrupted or missing ones with the correct versions from a cached store (usually located in %WinDir%\WinSxS). Essentially, SFC compares each critical system file against a known-good copy; if a file is corrupted or modified, it will restore the original. Microsoft documentation notes that SFC can fix a wide range of issues – if “critical Windows system files are missing or corrupted, some Windows features may stop working correctly or Windows may stop responding altogether,” and running SFC repairs those files (often preceded by a DISM image repair step if needed).

In our context, running sfc /scannow on the Windows Server 2019 machine indeed found problems and repaired them. (It’s a good practice to run this in a Command Prompt with Administrator privileges, and to reboot after the scan if any files were repaired.) After SFC completed, the log indicated that one or more system files had been corrected. While the specific files repaired weren’t explicitly named in the user’s report, it is very likely they were related to UI automation or graphics capture components – for instance, SFC might have restored a damaged Accessibility.dll or oleacc.dll, which are known to fall under Windows Resource Protection. In one SFC log example, a missing Accessibility.dll (part of the .NET framework’s accessibility support) was detected, demonstrating that SFC does target these UI-related libraries. By fixing such a file, SFC would restore the expected functionality that Automation Anywhere depends on.

Once the SFC scan repaired the Windows system files, the Capture command in A360 stopped crashing. This outcome confirmed that an OS-level fault was the culprit all along. Essentially, the System File Checker resolved an issue in Windows that was indirectly causing Automation Anywhere to fail. It’s worth noting that when SFC reports its results, you’ll see messages like these:

• “Windows Resource Protection found corrupt files and successfully repaired them” – meaning SFC detected issues and was able to fix them.
  
  
• “Windows Resource Protection found corrupt files but was unable to fix some of them” – meaning further manual repair or DISM tool usage would be needed.
  
  
• “Windows Resource Protection did not find any integrity violations” – meaning the system files are fine (in our case, this is not what we saw initially – we only reached this healthy state after the repairs).

In the scenario at hand, the first message (“corrupt files… successfully repaired”) is the one that gave the green light. After seeing that and rebooting the server, the Automation Anywhere Capture functionality was tested again. This time, no crashes occurred – the bot was able to use the Capture command normally. The previously failing bots could now identify and interact with UI elements without error, confirming that whatever system discrepancy existed before had been corrected by SFC.

Why Corrupted System Files Interfered with the Capture Command

It’s important to understand why a corrupted Windows file can crash an RPA action like Capture. The Capture command works by hooking into the target application’s UI elements – essentially, it uses Windows’ mechanisms to “see” and control another window or control (for example, to get text from a text box or click a button). Windows provides standardized ways to do this through Active Accessibility (AA) and UI Automation (UIA). Automation Anywhere’s recorder is built to leverage these: according to documentation, as long as the environment has those standard frameworks (which Windows Server 2019 does), A360 can capture controls from browsers, Java apps, and Windows native apps via AA/UIA interfaces.

However, if the underlying Windows API calls or COM interfaces are broken due to a bad system library, the bot’s action can throw an exception or hang. For example, if UIAutomationCore.dll (which contains core UI Automation functions) is faulty, any software calling into it might crash unexpectedly. This isn’t just a theoretical concern – as mentioned earlier, an enterprise hit a situation where UIAutomationCore.dll was causing crashes, and the resolution path included updating system files and drivers. Likewise, if oleacc.dll or its associated registry entries were corrupted, any attempt by Automation Anywhere to use MSAA to capture an object could fail. In fact, oleacc.dll issues are known in the Windows world; the file is a “Microsoft Active Accessibility Core Component”, and problems with it can stop GUI automation tools in their tracks. SFC specifically targets and protects this file (as it’s a system DLL), so running SFC often resolves those issues (this aligns with the user who said System File Checker fixed an oleacc.dll missing error that was preventing apps from running).

Beyond accessibility libraries, the Capture command might also utilize other Windows components, such as GDI (for screenshots or coordinate calculations) or even the Desktop Window Manager if capturing layered windows. A corruption in any of these could also cause a low-level failure. In Windows Server environments, especially if the “Desktop Experience” is installed (which is required for graphical automation), all normal Windows 10 GUI components are present. Thus, a Server 2019 instance is not immune to the same file corruption issues a client OS might face. It could be something as simple as a damaged OneDrive integration DLL or a bad Windows update that left some system files in a weird state – running SFC has been known to fix strange crashes in many cases where “nothing made sense” until the OS was scanned and healed.

In short, Automation Anywhere’s stability is indirectly dependent on the host operating system’s health. When core OS files that Automation 360 relies on (like those enabling UI automation) are not functioning, the bot can crash in the middle of a Capture. No amount of reinstalling the bot software will fix this, because the problem lies one layer below, in Windows itself. The successful repair via SFC /scannow underscores that point.

Conclusion and Best Practices

The case of the crashing Capture command on Windows Server 2019 (A360 build 21023) ultimately highlights a valuable lesson: RPA solutions run on top of the OS, so OS integrity matters a great deal. In this instance, the root cause wasn’t a bug in Automation Anywhere’s code, but rather a subtle corruption in the Windows environment. All the typical RPA troubleshooting (reinstalling the Bot Agent, clearing caches, checking settings) proved ineffective. Only after the Windows System File Checker utility identified and repaired corrupted system files did the issue resolve.

For experienced RPA developers and IT support personnel, this example reinforces a few best practices:

• Don’t overlook the OS: If you encounter unexplained errors or crashes in your RPA bots, especially after ruling out logic errors or misconfigurations, consider the health of the operating system. Check the Windows Event Viewer for any application error logs that might point to system DLL faults. It may save you time to run maintenance tools like SFC or DISM on the machine to ensure no fundamental system issues are present.
  
  
• Use SFC /scannow when applications misbehave inexplicably: SFC is a safe-first step to repair the environment. As Microsoft notes, it will scan and replace broken system files with known good copies. It’s straightforward to run and can often resolve “mystery” problems. In our scenario, SFC literally saved the day – it fixed what dozens of re-install attempts could not. (For completeness, if SFC cannot fix a file, Microsoft recommends running the DISM tool to restore the component store, then re-running SFC.)
  
  
• Ensure Windows is updated and feature-complete: Especially on servers, ensure that the Desktop Experience (GUI components) is enabled if you plan to run attended automation, and that no recent Windows Update has failed or left files in limbo. Sometimes RPA issues emerge after a Windows patch; if so, SFC/DISM can help repair any patch-related file anomalies.
  
  
• Leverage vendor support but share system findings: If you do escalate to Automation Anywhere support, it’s useful to share that you ran SFC and the results. In similar community cases, AA support might ultimately ask for environment details or suggest a clean OS install if nothing else works. Being proactive in checking OS integrity can speed up the resolution.

In conclusion, the Capture command crash on Windows Server 2019 was solved by addressing the underlying Windows system file corruption. The sfc /scannow command proved to be the turning point, repairing Windows’ own UI automation libraries, which in turn allowed the Automation Anywhere bot to run smoothly. This deep dive exemplifies that sometimes the fix for an application-level problem lies in the platform it runs on. For technical professionals, it’s a reminder to keep both the RPA tool and the operating system in healthy shape for successful automation deployments. With a stable Windows foundation, your Automation Anywhere bots can reliably do what they’re designed for, including capturing screen elements, without crashing.

References:

1. Automation Anywhere Community Thread – “Error Performing Capture Operation”, suggesting Bot Agent reinstallation and cleanup.
2. Stack Overflow – A360 Bot stuck in “Download Dependencies”, user attempts including reinstalling Bot Agent and clearing Global Cache.
3. Automation Anywhere Documentation – Using the Capture action, notes on support for MS Active Accessibility and UI Automation.
4. Microsoft Support – System File Checker (SFC) tool, description of sfc /scannow scanning and replacing corrupt system files.
5. Microsoft Community Forum – user report that oleacc.dll missing prevented applications from running, fixed by SFC.
6. Microsoft Q&A – discussion of crashes in UIAutomationCore.dll after Windows update; recommendation to use SFC to repair system files.
7. Windows Central – Guide on System File Checker, showing typical SFC result messages (“found corrupt files and successfully repaired them”).