As I understand it (and I could easily be confused), the DCOM patches,
"Distributed
Component Object model/modules", is built on top of RPCs (Remote
Procedure Calls). It
makes sense...If I access an "object" that has various "operator's" that
are called by
calling procedure calls defined with the "object" that operate on the
object, then in
a distributed model, you would use remote calls to another machine to
access the same
procedure calls on remote objects.
If it is any consolation, my Outlook 2002 stopped functioning correctly
(using an
IMAP server) when I installed the first DCOM patch in July. So far, no
subsequent patches
have fixed the problem and the online-email help with windowsupdpate
people were unable
to resolve the problem. However, they are also prevented (by MS policy)
escalating the
problem to any product engineers.
In my situation, examining the IMAP traffic between the client and the
server, I seem to
note the following problem:
1) IMAP uses a remote 'function', then 'execute' type structure.
Meaning the client
sens an IMAP command, and when it is done sending the command or
commands, it
sends a completion message (forget exact message, but it is something
like 'IDLE'). At
that point the server executes the commands it was sent and prepares to
return a result
to the client, but (this is based on observation, not reading the IMAP
spec), the server won't
process the commands unless it knows the client is "IDLE" and waiting
for a response.
I see maybe 1-2 commands come from clilent followed by their "IDLE" (end
of command)
messages, but the hang comes when my outlook client sends a command, but
then I never
see it send the matching 'IDLE' to tell the server to execute the
previous set. Outlook
then seems to go into a waiting state for an answer that never comes and
the server goes
into a wait state waiting for the client to become idle (or finiish it's
command). Neither happens.
Outlook becomes unresponsive and usually has to be killed with the
taskmanager.
2) This one is a bit 'lower' on the protocol chain, but I've noticed
that Outlook can _usually_
send messages, but sometimes, I see a 'send' return with some odd status
0x80000xxx (don't
remember exact number) -- but it claims it can't communicate with
"sendmail" process on
the outgoing email serverr. I've seen it come back with an error as
many as 4 times in a row
(with me pressing "send/receive" each time, currently configured only to
'send' (since I know
receive is broken and will hang outlook), but finally succeed on the 5th
try. More often
than not it will work the first time. But this inconsistancy seems
consistent with #1 where
I used to see varying amounts of progress in an IMAP session before
Outlook would
hang.
I'm guessing some TCP function that sends data over the connection is
returning
an error, randomly, which is likely why Outlook never sends the "IDLE"
in #1 above -- because
the previous TCP communication (sending the command) returned some error
code). I don't
see it in the protocol transmissions between my client and the server,
so my guess would
be that something is stepping on the return value -- which implies a
random memory overwrite
or corruption (like a buffer overflow) has been created by the new
patches. Note that
using a different email agent/client like "Mozilla" seems not to be
affected by this new
buffer overflow/memory corruption.
While there is no exploit for this corruption, that I know of, yet, it's
such random memory
corruption/buffer overflows that generally cause security problems, so
it may just be a matter
of waiting until someone finds an exploit for this and then MS will fix
it. Meanwhile, I'm
stuck unless I want to pay long distance charges to call in the
problem. I may eventually
do that, but considering wait times of 30-45 minutes, I've heard in some
cases, I haven't
been eager to try that route.
It's been suggested to me to try installing a new copy of the OS to a
different directory and
try booting from that as a next possible debug step. That's also
something that takes
time....and I have yet to work that into my schedule....
Good luck!
-linda
