Hundreds or even Thousands of occurrences of the following event ID can be observed over a condensed period of time. Take note of the subject line in the event as it provides the attachment causing the issue.
Event ID: 29132 Unable to convert item content
Reason: Conversion failed (0xc00419e0)
Supplementary Info:
Item: SA:-0
Subject: banner.jpg
Attachment: Bank With Us
Type: jpg
Vault ID: 18E630FD93183F54996EB989C32EC72A01110000uk-evssmtp-01
SaveSet ID: 202201156339122~202107150850060000~Z~5148562EDE7CBCCC6F94704708D8C281
Attachment ID: 3
Archive Name: SMTP Archive 2022
Archive Date: 2022-01-15 08:52:00
This item will be archived without a preview being available to the web application and the content will not be indexed. It is not possible to search on the content but the item can be restored as normal
Dtrace of EVConverterSandbox will show the following:
"(EVConverterSandbox) <260> EV:L {INSOHelper::OpenHTMLDestination} Destination [C$2$DST] Result [file is corrupt (9)]"
The cause of this issue is a corrupt attachment that was sent to 1000's of recipients. In this case it was a corrupt signature file. When Enterprise Vault archives items with attachments it attempts to convert the attachment to html for the purpose of providing an html preview when viewing the item in a search result. The corrupt file causes the process to slow down considerably. In addition, failed conversions trigger a retry mechanism for multiple attempts. This behavior combined with the same attachment being sent to many users will may in some cases create a backlog in the storage queue to the point that it fills up. Then no more items will be archived until the storage queue has an opportunity to clear out. In some cases this can take hours. At which point normal processing will occur.
In most cases end user will not be affected.
A permanent solution would be to track down the corrupt attachment and eliminate it from the environment.
In the event that it is not possible to remove the corrupt attachment from the environment Enterprise Vault has been enhanced in EV 14.1.3 and 14.2.1 to alleviate the issue by eliminating the default retry mechanism for failed conversions.
To resolve the issue, the code has been modified to skip the conversion retry mechanism for certain file types on encountering error. These file types identified by their ‘FileId’ will be read from the registry during the conversion process. On encountering an error, a check will be carried out to see whether the retry mechanism is enabled or disabled for the ‘FileId’ in question and accordingly further processing will be done.
The ‘FileId’(s) will be read from the following registry string value:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KVS\Enterprise Vault\Storage\Content Conversion]
DisableRetryOnFileIds = “.1557.1535”
NOTE: The following file ids translate to the following file types.
1535: jpg
1557: pdf
1998: none
1999: unknown