eM Client 11 Beta: three MAPI/MMGA error dialogs after MSI-to-MSIX upgrade

After upgrading an existing 32-bit eM Client installation to eM Client 11 Beta using the recommended MSI upgrade path, Windows displays three MAPI-related error dialogs after every logon.

System:

  • Windows 11 x64
  • eM Client Beta 11.0.108.0, x64 MSIX
  • Package: eMClient.20054CA46072C
  • eM Client (Updater): 11.0.108.20915
  • Previous installation: 32-bit eM Client
  • Classic Outlook is installed for occasional institutional use, but eM Client is my default mail application

Initially, the dialog was titled “Microsoft Office Outlook” and claimed that no default email client was available or that the current client could not fulfil the messaging request.

After backing up and removing only Outlook’s PreFirstRun message text, the underlying failure remained, but Windows displayed this generic dialog instead:

Zum Ausführen der gewünschten Aktion ist kein E-Mail-Programm zugeordnet. Installieren Sie ein entsprechendes E-Mail-Programm, oder erstellen Sie in der Systemsteuerung unter „Standardprogramme“ eine Zuordnung, wenn bereits ein Programm installiert ist.

Important findings:

  • The problem occurs even when both eM Client startup entries are disabled.
  • Neither eM Client nor MailClient.exe is running when the dialogs appear.
  • The dialog appears exactly three times.
  • Each dialog leaves one C:\Windows\System32\MmgaServer.exe -Embedding process behind.
  • After the third dialog, Task Manager shows three MMGA Server processes, misleadingly grouped under the eM Client icon.
  • The direct parent process is svchost.exe -k DcomLaunch -p .
  • Starting eM Client manually works correctly.
  • Mail accounts and normal eM Client operation are unaffected.
  • Repairing the MSIX app through Windows Settings completes successfully but does not fix the problem.

Current registration:

  • The default value under both 64-bit and 32-bit HKLM\SOFTWARE\Clients\Mail is PackagedMail .
  • HKCU\SOFTWARE\Clients\Mail is also set to PackagedMail .
  • The Windows MAILTO UserChoice is eM Client.Url.mailto .
  • Windows Default Apps assigns the relevant email associations to eM Client.

Possible upgrade residue:

C:\Program Files (x86)\eM Client contains only the small 32-bit MailClient.exe launcher and InstallMsix.ps1 .

MailClient.Mapi.dll is not present there, although old classic eM Client registry entries in both registry views still reference:

C:\Program Files (x86)\eM Client\MailClient.Mapi.dll

This looks like inconsistent legacy MAPI registration left behind by the MSI-to-MSIX migration.

I do not want to make Outlook the legacy MAPI default as a workaround, and eM Client otherwise works perfectly. I also do not want to rebuild all accounts, credentials, and settings merely to remove three startup dialogs.

Has anyone else reproduced this with the v11 Beta upgrade? Is there a supported way to repair only the eM Client PackagedMail /MAPI registration without resetting or recreating the existing eM Client profile?

I have also reported this to the eM Client beta testing address.

Related issue: Cannot make eM Client the default mail handler Windows
That thread describes eM Client reporting that it is not the default mail handler even though Windows associations are correct. My case additionally produces three actual MAPI/MMGA error dialogs and three MmgaServer.exe processes after logon, so it appears to go beyond the incorrect status indicator inside eM Client.

After upgrading an existing 32-bit eM Client installation to eM Client 11 Beta using the recommended MSI upgrade path

Windows displays three MAPI-related error dialogs after every logon.

Windows 11 x64 / eM Client Beta 11.0.108

As you are getting errors after updating, then suggest “if you made a backup prior to updating” as was recommended on the Beta installer page, then uninstall your current version and “delete the database” when asked on the uninstall wizard.

Then If still exists, delete C:\Program Files (x86)\eM Client folder,

Then if you originally installed eM Client from the webpage “reinstall the same version you had prior to the upgrade” from the release history page.

Then open eM Client and “Skip the setup wizard” and restore your backup via “Menu / File / Restore” and check that is opening and running ok without errors.

Then “close eM Client” and try updating again to V11.0.108 (.msi) via the release history page.

Thanks for these suggestions but to be honest, I really I do not understand them:

The same version I had prior to the upgrade was opening without errors.
The errors started exactly with the upgrade.

So why should I revert to the same previous version and then do again what I already did, namely upgrade to v11 beta?

Wat else could result from these two steps if not the same situation with the MAP/MMGA error dialogs I am asking help for?

So why should I revert to the same previous version and then do again what I already did, namely upgrade to v11 beta?

As something obviously went wrong either during the install or after the install, then we can only recommend steps to try and resolve it, which “starting again with your previous version should hopefully fix it”. If i personally was getting errors like that i would try reverting back & upgrading again. If you still get the same errors then you might have a eg: Windows registry or OS error.

If you don’t want to try reverting back to your previous eM Client version and then upgrading again, or you didn’t make a backup prior to upgrading & carn’t revert back, then “suggest you email the Beta Support Team” via the email address below who might be able to assist you with how to fix those errors. If you do email them, let them know what eM Client version you had prior to the upgrade and link this thread so they can see what errors you are getting.

Note:- If you carn’t get into eM Client to email, then email the Beta team via your webmail.

Quote from the V11 Beta upgrade page

“In case you come across any issues with the Beta version, please make sure to report them to our support team at [email protected] and we will look into each reported problem in detail”.

Update after extensive troubleshooting:

I have now been able to separate two different causes that initially produced very similar MAPI/MMGA error dialogs.

On one computer, gSyncit was involved. After disabling and uninstalling gSyncit, the original sequence of multiple dialogs disappeared.

However, on a second computer the problem persisted even though gSyncit was not installed. I completely removed eM Client and performed a clean v11 installation using the App Installer/MSIX package, without migrating the previous 32-bit installation. Therefore, the old MSI upgrade residue was not the root cause.

On this clean installation:

  • eM Client was correctly assigned to MAILTO, EML, ICS, MSG, VCF, WEBCAL and WEBCALS.
  • eM Client itself confirmed that it was the Windows default email program.
  • Nevertheless, starting eM Client caused Outlook Classic to be activated through COM/DCOM as:

C:\Program Files\Microsoft Office\root\Office16\OUTLOOK.EXE -Embedding

  • Windows Task Manager grouped “Microsoft Office Outlook” underneath eM Client.
  • Outlook then displayed the misleading “There is no default mail client…” dialog.
  • Disabling Outlook’s Check Default Client registry value did not suppress it.

The decisive workaround was to remove only Outlook Classic from the existing Microsoft 365 installation using the official Office Deployment Tool and:

<ExcludeApp ID="Outlook" />

After rebooting:

  • eM Client started normally;
  • no Outlook process was activated;
  • no MMGA Server appeared;
  • and no MAPI/default-mail-client dialog was displayed.

Word, Excel and the other Microsoft 365 applications remained installed. The separate new Outlook app also remained installed and did not cause the problem.

So the remaining technical question is why starting the clean eM Client v11 MSIX installation activates Outlook Classic as a COM server at all, even though eM Client is correctly registered as the Windows default email client.

I have sent these updated findings to the eM Client v11 beta support team as well. My original assumption that the 32-bit-to-64-bit upgrade residue itself was responsible should be considered corrected.

Final update / current conclusion:

eM Client development has confirmed that the MSIX version depends on an undocumented Windows feature that redirects MAPISendMail calls to packaged applications.

eM Client only declares the windows.mailProvider capability. Registration, selection of the default MAPI application, application startup and forwarding of the API request are then handled by the Windows MAPI libraries.

On the affected computer, all relevant defaults were already correct:

  • HKLM\SOFTWARE\Clients\Mail = PackagedMail
  • HKLM\SOFTWARE\WOW6432Node\Clients\Mail = PackagedMail
  • HKCU\SOFTWARE\Clients\Mail = PackagedMail
  • MAILTO and the relevant email-related file and URL types were assigned to eM Client
  • eM Client itself reported that it was the default email program

Nevertheless, starting eM Client caused Windows to activate Outlook Classic through DCOM as:

C:\Program Files\Microsoft Office\root\Office16\OUTLOOK.EXE -Embedding

Outlook then displayed its incorrect “There is no default mail client…” dialog.

The problem disappeared only after Outlook Classic was selectively removed from the existing Microsoft 365 installation using the official Office Deployment Tool with:

<ExcludeApp ID="Outlook" />

After rebooting:

  • eM Client started normally;
  • Outlook Classic was no longer activated;
  • no MMGA Server appeared;
  • and no MAPI/default-mail-client popup was displayed.

Word, Excel and the other Microsoft 365 applications remained installed. The separate new Outlook app also remained installed and did not cause the problem.

My conclusion is that this was an interaction between Windows’ undocumented MSIX/MAPI redirection mechanism and the remaining Outlook Classic COM/MAPI registration. The relevant PackagedMail defaults alone did not prevent Windows from selecting Outlook Classic.

Removing Outlook Classic is obviously not a suitable workaround for users who still depend on it, but it conclusively identified the component responsible for the popup on this system.

I have provided the detailed findings to the eM Client v11 beta team. Further investigation now needs to be done by eM Client and, ultimately, Microsoft.

1 Like