Based on some things we've seen, we put together this list to help you as the first line of defense if you have any issues with VIPRE SafeSend.
Errors
Unknown Data Format
Why do I see "Unknown data format" for the SS_SafeDomains registry value when using SafeSend.ADMX file in Group Policy?
You should only see this error message when using an outdated version of ADMX files for your server operating system. SafeSend’s ADMX file supports Windows Server 2008 R2 or later versions. The setting SafeDomains uses a multi-string type registry value (REG_MULTI_SZ) which requires the latest version of the ADMX templates for your server operating system. The latest ADMX templates can be downloaded from Microsoft here.
Object reference not set to an instance of an object
Do you repetitively see "Object reference not set to an instance of an object" for a specific user?
We have only seen this once for one single user, and it was due to a corrupt .NET framework that needed to be reinstalled. You will see it in the debug log as a line printed directly after the “Time to get unsafe recipients” statement. Please contact us if you see this for any of your users, and we will provide you with a special debug build to verify the issue and provide an appropriate solution. In this case, our special debug build will print “The type initializer for ‘System.MarvinHash’ threw an exception. —> System.ApplicationException: Invalid XML in file ‘C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config’ near element ‘</DbProviderFactories>'” which indicates that the .NET framework needs to be reinstalled.
Do you see "Object reference not set to an instance of an object" for a specific SMTP recipient?
This is because SafeSend cannot resolve the email address of an invalid olSmtpAddressEntry contact. Normally, Outlook never allows typing in an invalid email address as a recipient, e.g., without the @ symbol. However, if you have an Excel macro that is calling Outlook programmatically to send emails this can actually happen. The solution is to reevaluate your problematic recipient if it has a valid email address.
Do you see "Object reference not set to an instance of an object" and then “The operation failed. The messaging interfaces have returned an unknown error. If the problem persists, restart Outlook.” in Outlook?
In this case, the debug log also shows that this is for an olSmtpAddressEntry contact type. This is an Outlook error and not a SafeSend error. Please search online for “The operation failed. The messaging interfaces have returned an unknown error. If the problem persists, restart Outlook.” to find suggested solutions.
An internal support function returned an error
Do you see "An internal support function returned an error"?
This is an Outlook issue and not a SafeSend issue. We have only seen it in Outlook 2007 and Outlook 2010. Please contact us if you receive it and we can guide you.
Changes made to the item were lost due to a reconnect with the server
Do you see "Changes made to the item were lost due to a reconnect with the server"?
This can happen in edge cases on version 4.3.28.0 or earlier of SafeSend when Outlook is running in Online Mode. The debug log also prints an item “Failed to save the message”. Our newer versions have this fixed, but a workaround is to set DisableInternalSave = 1
OutofMemoryException
Do you see "OutOfMemoryException"?
This can happen if the machine or Outlook is under extreme stress. It means that the .NET framework is not able to allocate any memory to SafeSend, and that execution cannot continue. The user will in this case, as with all other unexpected errors, see a confirmation window showing the error message and allowing the user to send the email anyway. If you are running Outlook version lower than 16.0.8528.2147 (that is Outlook 2016, version 1709), then it can help to upgrade Outlook as this version of Outlook introduced something called Large Address Aware (see link). Please contact us if you see this error for further investigation.
STOREDRV.Submit.Exception:TextConvertersException; Failed to process message due to a permanent exception with message data truncated TextConvertersException: data truncated
Do you see "STOREDRV.Submit.Exception:TextConvertersException; Failed to process message due to a permanent exception with message data truncated TextConvertersException: data truncated"?
This can happen in edge cases on version 4.3.28.0 or earlier of SafeSend when Outlook is running in Online Mode. The debug log also prints an item “Failed to save the message”. Our newer versions have fixed this, but a workaround is to set DisableInternalSave = 1.
None of your e-mail accounts could send to this recipient
Do you see "None of your e-mail accounts could send to this recipient" being displayed in Outlook?
This is an Outlook issue and not a SafeSend issue. Please search online for “None of your e-mail accounts could send to this recipient” to find many suggestions on how to fix this.
Unresolved
Do you see "Unresolved" being displayed for a recipient?
In very special cases you can see a recipient being displayed as Unresolved in SafeSend. This can be of several reasons depending on your exact environment and situation:
Case 1 – If all of the following conditions are met:
- Outlook is in Online Mode or your offline address book is not present on the user's machines
- SafeSend is trying to resolve the email address of an Exchange contact
- there is a network issue where the network suddenly stops functioning...
There are several workarounds available if you see this happening frequently. The first one is to consider if you can treat all Exchange contacts as internal automatically without resolving their email addresses. This is the most straightforward workaround and is implemented by setting ResolveGALRecipientsMode = 1. It also has the additional benefit of not causing any network calls and therefore increases the performance of SafeSend when resolving a large number of recipients. The other workaround is to increase the retry count using UnresolvedRecipientRetryCount, or to increase the UnresolvedRecipientRetryInitialDelay from its default value. The third workaround is to treat all unresolved recipients as internal by setting UnresolvedRecipientActionOnFailMode = 1.
Case 2 – If there is a corrupt Outlook contact present in the Outlook address book or the auto-complete cache. This can happen due to migrations from older versions of Outlook. The workaround is to remove the corrupt contact from the Outlook contact book or from the auto-complete cache (NK2 file). Another workaround is to treat all unresolved recipients as internal by setting UnresolvedRecipientActionOnFailMode = 1. You can also apply this setting locally to an individual user if there only one or a few users who are experiencing this.
Resize issue when changing DPI settings
Do you see a resize issue in the SafeSend window when changing DPI settings?
This can happen in Windows if you change DPI settings and you do not log out and log in after the change is applied. It can also happen if you are undocking a laptop connected to two large monitors with SafeSend visible. It normally works absolutely fine to change DPI mode which is happening in these cases, but there are situations where the end-user has to log out and then log in again. It has to do with that WinForms, which is the GUI library we use, do not fully support DPI changes on .NET framework 4.0.
Logs
Refer to Related Articles for more information on how to adjust logging settings.
Debug Log
SafeSend has a debug log window where it prints useful information regarding its internal operations. You can view this log by Outlook -> File -> Options -> Add-ins -> Add-in Options … -> SafeSend -> View live debug log. This window will be cleared from the start and will only fill with data if you do any SafeSend operations such as sending or canceling an email. You can also make debug logging persistent to the normal file log in SafeSend at “%LocalAppData%/SafeSend/SafeSend.log” by setting DebugLogging = 1 and LoggingFileLogEnabled = 1.
Add-in Loading Log
C:\Users\{username}\AppData\Local\SafeSend\adxloader.log. The {username} part should be the username of the user who starts Outlook.