OPC DA连接失败主因是DCOM权限配置错误或位数不匹配：需以管理员身份在组件服务中为OPC服务器设置启动/访问/配置权限，标识选“交互式用户”；并确保C#项目平台（x86/x64）与regsvr32注册的OPCDAAuto.dll位数一致。
OPC DA连接失败：先看DCOM权限和位数匹配
绝大多数 COMException（错误码 0x80040154 或 0x80070005）不是代码写错了，而是Windows系统层面没放行。KepServerEX V6这类OPC DA服务器必须通过DCOM与C#客户端通信，哪怕你连的是本机localhost。
关键操作有三步：
- 以管理员身份打开“组件服务” → 展开“计算机” → “我的电脑” → “DCOM 配置”，找到你的服务器名（如
Kepware.KEPServerEX.V6）→ 右键“属性” - 在“安全”页签里，把“启动和激活权限”、“访问权限”、“配置权限”三项全设为“自定义”，点击“编辑”，添加当前用户并勾选“允许”全部权限
- 在“标识”页签中，必须选择“交互式用户”——即使程序跑在Windows服务里，本地调试时也得这么配，否则
Connect()会静默失败
位数不匹配是另一个高频死因：如果你的C#项目目标平台是 x86，但注册了 C:\Windows\System32\OPCDAAuto.dll（64位），或反过来，就会报“类未注册”。务必确认：regsvr32 路径和项目平台严格一致。
Item路径写错：别猜，用KepServer诊断工具验证
Opc.Da.Item.ItemName 字符串不是自由格式，它必须精确匹配KepServer中已启用的标签路径，且大小写敏感、不能有多余空格。常见错误包括：
- 写成
"PLC1.Tag1"，实际应为"Channel1.Device1.Tag1"（取决于你在KepServer里建的通道/设备名） - 误加前缀如
"ns=2;s=..."（那是OPC UA的NodeId，DA里完全无效） - 用了中文字符或特殊符号（如顿号、括号），而KepServer默认不支持
最稳的办法：打开KepServerEX自带的 KepServerEX Diagnostic Client，连接后浏览地址树，复制完整路径粘贴到代码里。不要依赖文档或别人给的示例路径。
Read()调用崩溃：检查返回值和索引边界
server.Read() 成功返回后，values 数组长度不一定等于你传入的 items 长度。某些标签可能未激活、地址不存在，或权限不足，此时对应位置会是 null 或抛出异常，而不是填入默认值。
典型陷阱代码：
var values = server.Read(items, ...);<br>Console.WriteLine(values[0].Value); // 一旦第一个item读失败，这里直接NullReferenceException
正确做法是逐项检查：
- 先判断
errors输出参数是否为null或含非零错误码 - 遍历
values，对每个元素判空：if (values[i]?.Value != null) - 读取前确保
server.ServerState == (int)OPCServerState.OPCRunning，否则Read()可能直接抛COMException
为什么Python/Matrikon能连，C#却不行？
这几乎可以锁定为环境隔离问题。Python用的OPC库（如 opc-da）或Matrikon测试工具，往往自带独立的COM注册和DCOM配置逻辑；而C#项目依赖系统全局的 OPCDAAuto.dll 注册状态和当前用户的DCOM策略。
排查顺序必须是：
- 确认C#进程运行用户和Matrikon工具是同一个Windows账户（尤其注意“运行方式”是否勾选了“以其他用户身份运行”）
- 用
Process Monitor抓取C#进程对OPCDAAuto.dll的加载路径，验证是否从SysWOW64或System32正确加载 - 检查KepServerEX服务登录账户——如果它用的是“本地系统账户”，而你的C#程序用的是普通域用户，DCOM跨账户通信默认被禁用，需手动在DCOM配置中授予该用户“启动和激活权限”
工业现场最常被忽略的一点：KepServerEX安装后默认只允许“本地激活”，远程客户端连不上。这个开关藏在DCOM属性的“位置”页签里，必须勾选“在此计算机上启用分布式COM”并重启服务。
