这不是工具的bug，是Azure Event Hubs（IoT Hub内置事件端点基于此服务）的连接规则限制导致的，我来给你拆解原因和解决办法：

错误原因解析 #

报错里的核心提示：At least one receiver for the endpoint is created with epoch of 'X', and so non-epoch receiver is not allowed，意思是：

• 你的IoT Hub内置端点的某个消费者组（比如报错里的$default或iothubconsumergroup）已经有一个使用纪元（epoch）值的接收器在运行了
• Azure Event Hubs的规则是：同一消费者组下，一旦有带epoch的活跃接收器，其他非epoch或更低epoch的接收器会被拒绝连接——这个机制是为了确保同一消费者组内只有一个高优先级的"主接收器"，避免消息重复消费或连接冲突

具体解决步骤 #

1. 关闭所有占用连接的进程/会话 #

首先排查并终止所有正在使用该端点的接收器：

• 检查VS2019/VSCode中之前打开的IoT Hub监控窗口，确保完全关闭（包括后台运行的会话，有些工具会在后台保持连接）
• 排查其他可能的连接来源：Azure Portal的IoT Hub消息监控、Azure Stream Analytics作业、你自己开发的使用SDK连接该端点的应用程序（如果代码里用了epoch参数，要确保程序退出时正确调用Close()或Dispose()释放连接）

2. 针对VS2019的操作 #

• 完全关闭VS2019，重新启动后，重新连接你的IoT Hub资源，再尝试右键点击内置事件端点选择"监控消息"
• 如果问题依旧，打开VS2019的Azure资源管理器，定位到你的IoT Hub，展开"内置终结点"，查看对应消费者组的连接状态，确认没有残留的活跃连接

3. 针对VSCode的操作 #

• 关闭VSCode中所有与IoT Hub监控相关的终端或面板，重启VSCode后重新登录Azure账号并连接IoT Hub
• 通过VSCode的Azure IoT扩展，右键点击你的IoT Hub，选择"管理内置事件端点"，检查各个消费者组的连接情况，清理残留的活跃会话

4. 强制接管连接（可选） #

如果确认无法找到并关闭现有连接，可以尝试使用更高的epoch值创建接收器（不过VS2019和VSCode的默认监控工具通常不支持手动设置epoch，所以这一步更适合自定义开发场景）：
在自定义代码中，创建接收器时指定比报错里更高的epoch值（比如报错里是5，就设为6），这样新的接收器会强制替换掉旧的epoch接收器

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