Bob said:
[Running Windows 7 Home Edition and Outlook 2003 SP3 on a 1 year-old Dell
desktop]
A colleague is having problems with sending emails and we think we've
narrowed the problem down to the MAPI file. The original issue arose
because Quickbooks was unable to send PDF invoices through Outlook, as it
had been doing some time ago. Firing up Word and selecting File > Send as
attachment also failed.
So, we ran the fixmapi.exe tool and rebooted the computer, tried the Word
experiment again and it worked. Once. When we tried it again, we got the
same error, and this was the same when we ran Quickbooks. It seems that for
some reason the mapi32.dll program is becoming corrupted each time it's
triggered, so it'll only work once. We've tried renaming the MAPI file
before running fixmapi, and checking to make sure that it's not set to
read-only.
We've checked the computer for malware and viruses (Avast & MBAM) and had
the all-clear. Can anyone shed any light on what might be going on and how
it might be fixed?
Unlikely that mapi32.dll is getting "corrupted". Much more likely is
that you have a corrupted message store (the .pst file) or are using
security software (e.g., anti-virus) that is now interferring.
Disable your anti-virus program. That might eliminate the problem.
Some AV programs are still proxying the e-mail traffic when they are
disabled and if their proxy is screwed up then your e-mail traffic will
remain screwed up. I ran into this with Symantec's Norton AV many years
ago and had to figure out how to properly shutdown or kill their
processes and restart them rather than have to reboot the computer. If
e-mail traffic still goes through a screwed up proxy when e-mail
scanning is disabled in the AV product, you'll have to uninstall the AV
product to retest if e-mailing works thereafter. The same applies if
you have other product interrogating your e-mail traffic, like an
anti-spam program.
By the way, you gain no additional protection by having an AV product
scan your e-mails. If you end up having to uninstall, test e-mail, and
reinstall the AV product, do a custom install that does not include
e-mail scanning. If the product doesn't use a separately installed
component for e-mail scanning, disable it in the configuration of the AV
program. E-mail scanning affords no additional protection. The same
on-access scanner used to interrogate your e-mail traffic is the same
one used when you extract anything from your e-mails. All you change is
when some malware gets detected. E-mail scanning may detect the malware
as the e-mail arrives rather than later when you view it or extract from
it but it's the same engine doing the interrogation. Also, scanning
e-mail traffic will incur delays which can cause timeouts in the server
or client and these generate errors at either end. I use Avast and have
encountered delay/timing problems with it (but not very often). When I
install Avast, I do NOT include the e-mail scanner component. It's
superfluous.
I only have the free version of MBAM so I don't know if the payware
version which runs in the background has any options regarding e-mail or
[inter-application] messaging. I know some products will interfere with
messaging (between apps) to isolate them (e.g., GeSWall, Sandboxie,
etc). Even using SRPs (Software Restriction Policies), a feature built
into Windows (since, I believe XP and on), will cause behavior problems.
I use an SRP path rule to always run my web browsers under a limited
user account (LUA) token. This means they have their privileges reduced
to the same as if they were running when you log under a limited
account. It also means these instances of the web browsers run under a
LUA token even when called as a child process, like when you click on a
URL link in an e-mail in your e-mail client. Some functions in the web
browser may not be usable when the web browser runs under a LUA token.
I do have a copy of the web browser executables under a different path
with separate shortcuts to them so I can load them under my admin-level
account; for example, when I visit Windows Updates, Adobe (for Flash
update), or anytime admin privileges are needed by the web browser. The
point is that security software or measures can affect behavior or their
usability in applications. Even if it was all working before, a new
version of or updates to security software can alter its features or
functions which can, in turn, affect the behavior of your apps.
If getting the AV or other security programs out of the way by not
having it scan your e-mail traffic (and not have your e-mail traffic go
through their proxy) doesn't help then you might want to boot into a
less polluted environment. Load msconfig.exe and under the Startup tab
disable all items. Actually you can go to its General tab and select
"Diagnostic startup" mode. That disables all those programs you chose
to load on Windows startup or login. Could be one of those startup
programs is causing the problem, or an update to one of them now changed
behavior, has a bug in the new code, or now incurs a conflict with other
software that causes the problem - so get them out of the way to
eliminate any potential interference by them. Reboot into normal mode
but now with all the startup programs gone. You'll see a message saying
you using msconfig to modify your startup configuration. Ignore it.
Retest your e-mail setup. When you want to go back to your original
startup configuration, load msconfig again and either select the Normal
or Selective startup modes (Selective means some startup items are
disabled).
If that doesn't help, to try to create a new MAPI profile. Unload
Outlook. Use the MAPI applet in control panel to create a new mail
profile and make it the default one. When you next load Outlook, you'll
be using the new mail profile which means you have to recreate the
e-mail accounts saved within that mail profile. Then retest if e-mail
works okay or not.
