我之前也碰到过一模一样的情况，文件损坏大概率和你猜测的一致——要么是FetchXML返回的documentbody字段被截断，要么是Base64字符串处理环节出了问题。下面是几个经过实际验证的解决方法：

1. 改用Retrieve方法获取单条批注记录 #

FetchXML配合RetrieveMultiple查询时，偶尔会因为大字段的返回限制导致documentbody截断（尤其是文件较大时）。改用Retrieve方法直接获取单条批注记录，能确保拿到完整的Base64字符串：

// 假设你已经初始化了OrganizationService实例service，且拥有目标批注的ID annotationId
var annotation = service.Retrieve(
    "annotation", 
    annotationId, 
    new ColumnSet("documentbody", "filename", "mimetype") // 明确指定需要的字段，避免冗余
);

// 安全获取Base64字符串，防止空引用异常
var base64Content = annotation.GetAttributeValue<string>("documentbody");
if (string.IsNullOrEmpty(base64Content))
{
    // 处理批注无附件的情况
    return;
}

2. 清理Base64字符串中的无效字符 #

有时候CRM返回的Base64字符串会带有换行符（\r\n）或空白字符，这些额外字符会导致Convert.FromBase64String转换不完全，进而损坏文件。转换前务必先清理这些无效字符：

// 移除所有换行、空格等干扰字符
base64Content = base64Content.Replace("\r", "").Replace("\n", "").Replace(" ", "");
byte[] fileBytes = Convert.FromBase64String(base64Content);

3. 检查文件大小是否超过字段限制 #

Dynamics CRM中，annotation实体的documentbody字段最大支持10MB的Base64字符串，对应实际文件大小约7.5MB（因为Base64编码会增加约33%的体积）。如果你的文件超过这个阈值，documentbody会被自动截断，直接导致文件损坏。

这种情况下，建议将文件存储到SharePoint，然后通过批注关联SharePoint文档，而非直接把文件内容存在documentbody中。

4. 快速验证Base64字符串的完整性 #

可以通过简单的对比判断Base64是否完整：

• 计算实际文件的大小，乘以1.33得到Base64字符串的大致长度（比如7.5MB的文件，Base64长度约10MB）。
• 对比你从CRM获取的documentbody字符串长度，如果明显偏小，说明确实被截断了，这时候就需要调整查询方式或文件存储策略。

按照上面的步骤处理后，应该能解决文件损坏的问题。

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