重新连接Excel工作簿时出现OLEDB AccessViolationException问题

我之前也碰到过几乎一模一样的场景——本地测试顺风顺水，一部署到云VM就炸资源访问异常。结合你的情况，咱们从这几个核心方向排查和解决：

一、先把OLEDB驱动的版本/位数匹配问题捋清楚 #

Azure VM默认的Office或驱动大概率是64位，但如果你的UiPath是32位运行的，就会出现位数不兼容的隐形冲突，重连时资源释放逻辑直接混乱。

• 先查UiPath Robot的运行位数：打开UiPath Assistant，右上角设置里就能看到是32位还是64位
• 对应装匹配的驱动：如果是32位UiPath，就装32位的Microsoft Access Database Engine（注意如果已经装了64位Office，必须用被动安装命令：AccessDatabaseEngine.exe /quiet，否则会报错）
• 验证连接字符串的Provider：统一用Microsoft.ACE.OLEDB.12.0就行，但要确保驱动版本和UiPath位数完全对应

二、强制确保资源彻底释放（这是最常见的坑！） #

本地环境的GC回收机制比较宽松，哪怕你手动Close()后没彻底释放对象，系统也能偷偷帮你擦屁股，但Azure VM的资源管控很严格，只要有一个文件句柄没释放，重连时直接触发异常。
你的VB代码必须用Using语句包裹所有OLEDB相关对象，确保自动、强制释放资源，示例写法：

' 正确的资源释放模板，别再手动Close()了
Using conn As New OleDbConnection(connectionString)
    conn.Open()
    Using cmd As New OleDbCommand(sqlQuery, conn)
        Using reader As OleDbDataReader = cmd.ExecuteReader()
            ' 这里写你的数据处理逻辑
        End Using ' 自动销毁DataReader，释放关联资源
    End Using ' 自动销毁Command
End Using ' 自动销毁Connection，哪怕中途报错也会执行

Using语句会在代码块结束时自动调用对象的Dispose()，直接释放文件句柄，比手动调用Close()靠谱10倍。

三、检查Azure VM的文件锁定与权限 #

• 给文件所在文件夹加足够权限：UiRobot运行的账号（通常是Local System或你指定的服务账号）必须有该文件夹的完全控制权限，不然断开后可能残留锁定
• 避开后台进程干扰：Azure VM上的杀毒软件、OneDrive这类同步工具会后台扫描文件，导致文件句柄迟迟释放不了。可以临时关掉这类工具测试，或者把Excel文件放到本地磁盘（别用网络共享文件夹）
• 重连前加个短暂延迟：有时候系统释放文件句柄需要1-2秒的缓冲，在断开连接后加个Delay活动（UiPath里直接搜就行），等1秒再尝试重连

四、调整UiPath的运行隔离设置 #

在UiPath项目的Project Settings里，把Runtime选项中的Isolation改成Process，让每个流程实例都在独立进程里运行，避免多个任务共享资源导致的冲突。如果是用Orchestrator部署，还要确保机器人的执行环境没有残留的旧进程。

你可以先从资源释放的代码检查入手，这是90%的人碰到这个问题的根源，排查完再看驱动和权限的问题。

内容的提问来源于stack exchange，提问作者JerryCrowley