[SOLVED] Microsoft Access crash upon send to Zimbra

[Rich Graves]

ZCO 6.0.8 and 6.0.9.

Within a turnkey application that makes use of Microsoft Access 2007, the users go to Access's Office Menu and select "email" which then attempts to send an email through Outlook. The email is sent, but then Outlook crashes with the message as attached below.

Right-click and Send To... from the desktops in question works, so MAPI is happy.

Apparently, this was working fine all of 2009 and early 2010, then broke for one user in October 2010 and possibly another user in July 2010. The suspicion is that a recent ZCO broke Access integration. Unfortunately, we do not know what versions people were running when. Repairing/upgrading from ZCO 6.0.8 to 6.0.9 did not help.

Does this ring any bells for anyone? What should our next troubleshooting/data gathering step be?

Note that while the alert is about msaccess.exe, it is actually Outlook 2007 that crashes. Access 2007 keeps running. As far as I know, Office 2007 is fully patched.

[fsiegel]

Lots of action, support cases, etc. on this one. We don't know why this started happening, but the bottom line is, these 3rd party apps are crashing when trying to do a sync. But all they need to do is send mail; they shouldn't be doing syncs, so the easiest way for now is to use our registry key, SyncDisabledProcesses, to fix this.

There are a couple of bugs associated with this: 52442 and 53912. Note that we just fixed 52442 for 7.0, so that instead of relying on disabling processes, we will only enable certain processes to sync. Users shouldn't have to do anything.

But at this point, users will have to use the registry key except for a few processes. There are exact instructions in bug 53912, comment #2. In fact, this one even mentions MSACCESS.EXE. The way to tell what process name to put in the registry is to look at the ZCO logs for the process that had the issue. The name is in the second line of the file. You don't need the full path.

I'm sure in this case, just put MSACCESS.EXE. It is not case sensitive.

Doing this will resolve your issue. Any questions, let us know.

[Rich Graves]

Sounds promising, except that bugzilla says "You are not authorized to access bug #53912." I'll probably be able to see it if you add me to the Cc list.

[fsiegel]

I have added you to the cc list

[dave_kempe]

hey frank,
can you add me to that cc list as well?
dave at sol1 com au
got a client this may concern

[phoenix]

Originally Posted by dave_kempe

hey frank,
can you add me to that cc list as well?

You can add yourself to the cc list on any bug report.

[Rich Graves]

Originally Posted by phoenix

You can add yourself to the cc list on any bug report.

If that's true of private bugs, then that's a security hole... though not a highly critical one.

Extracting the gist that should be publishable:

HKEY_CURRENT_USER\Software\Zimbra or
HKEY_LOCAL_MACHINE\SOFTWARE\Zimbra (if 64bit machine,
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Zimbra).

The advantage of the first is that it's writeable by end users; the disadvantage is that it only applies to the specific user.

Assuming the former, and that the SyncDisabledProcesses value is not already
there:

HKEY_CURRENT_USER\Software\Zimbra
Right click on Zimbra
New String value
Name the value SyncDisabledProcesses
Double click on the value to edit the Value data
In the Value data box, put the name of your program in there.
If it's more than one program, enter them separated by semicolons, like MSACCESS.EXE;FOO.EXE

[shua]

Fsiegel,

i used these registry keys on older zco's and it seemed to fix the issue for a clinet sending invoices from their package by Sage called accpac.
Howver now afetr a program upgrade and zco upgrade but still with the registry keys in place, I am back to having issues.

Here are some log files. Can you take a look and see if you notice anything screwy.
The registry key to disable a process points to the executible on the 2nd or 3rd line of the log file A4wcontainerxp.exe

[fsiegel]

So I see two distinct runs of the program here, the first at 17:23 and then again at 17:27. The first one looks fine:

01-02-2011 17:23:08.388 [2628]: Zimbra::Util::IsSyncEnabledForThisProcess. Application is: C:\ACCPAC56\RUNTIME\A4WCONTAINERXP.EXE
01-02-2011 17:23:08.388 [2628]: Zimbra::Util::IsSyncEnabledForThisProcess. Sync is disabled for this application (a4wContainerXP.exe)
01-02-2011 17:23:08.388 [2628]: Zimbra::Store::StoreContextManager::Initialize. SYNC ENABLE - all syncing is disabled due to the process registry settings

The second one doesn't:

01-02-2011 17:27:54.389 [3620]: Zimbra::Util::IsSyncEnabledForThisProcess. Application is: C:\ACCPAC56\RUNTIME\A4WCONTAINERXP.EXE
01-02-2011 17:27:54.389 [3620]: Zimbra::Store::StoreContextManager::Initialize. Initializing Sync thread

Did anything change between 17:23 and 17:27? Could the registry have changed? We're picking up the app name the first time, and disabling the sync. The second time, we're not, so it is syncing, and that's where the problem is.

So the key question is: what happened in those 4 minutes?

[shua]

I think the change i made was specifying the whole path location of that executable, rather than just the executable itself.
Should that effect it?

I will double check that now. And now I know what to look for in the logs it may make things a bit easier.