Outlook pre-SP2 update going wild every minute

[Patrick Philippot]

Hi,

I have recently installed the pre- Office SP2 Outlook update (see
http://support.microsoft.com/?kbid=968009 - I installed both packages).
The update has been installed on 3 systems: 2 XP Pro french systems
(monoprocessor mobo) and one XP Pro english system (dual core). The
problem I'm describing below cannot be observed on the dual core system.

Exactly *every minute*, Outlook is going wild and loading the CPU at
100%. Depending on the system, this can last up to 4-5 seconds. During
this period, everything is freezed. You can't even click on a button.
When observing the process activity with ProcMon, one can see that
Outlook is **massively** using the registry during this period (about
15-20 000 events - yes, twenty thousands!).

Of course, this generates some trouble because any activity is
interrupted during a few seconds every minute (typing, mouse clicks and
wheeling,...).

Anyone experiencing the same problem?

Thanks in advance.

 

[Patrick Philippot]

Exactly *every minute*, Outlook is going wild and loading the CPU at
100%. Depending on the system, this can last up to 4-5 seconds. During
this period, everything is freezed. You can't even click on a button.
When observing the process activity with ProcMon, one can see that
Outlook is **massively** using the registry during this period (about
15-20 000 events - yes, twenty thousands!).

Actually, it seems that Outlook is re-reading all settings from the
registry every minute, as if it was starting up again.

 

[Diane Poremsky [MVP]]

So the problem is only on the French systems? Have you rebooted? Tried
Detect and repair? A new profile? (Keep the old profile, we just want to see
if it is a problem with the profile or the installation.)

--
Diane Poremsky [MVP - Outlook]
Need Help with Common Tasks? http://www.outlook-tips.net/beginner/
Outlook 2007: http://www.slipstick.com/outlook/ol2007/



Exchange Messaging Outlook newsletter:
(e-mail address removed)




You can access this newsgroup by visiting
http://www.microsoft.com/office/community/en-us/default.mspx or point your
newsreader to msnews.microsoft.com.

 

[Patrick Philippot]

So the problem is only on the French systems? Have you rebooted? Tried
Detect and repair? A new profile? (Keep the old profile, we just want
to see if it is a problem with the profile or the installation.)

Hello Diane,

So the problem is only on the French systems?

Well, it happens that the english system is also the dual core system.
This is the most powerful system and the one having the most memory. I
can't draw any conclusion from this.

Detect and repair?

Didn't help

A new profile?

I created a new profile containing a single email account. I started
Oultlook with this profile. Problem gone. I re-started Outlook with the
original profile. Problem back.

What on earth in a profile can trigger such an event exactly every other
minute? Ooooops! Got it!

I have an old macro that uses a 1 minute timer. This code always used to
run very quickly. This is what has changed. Now, it seems to take much
more time to run. Code excerpt:

Set objNS = Application.GetNamespace("MAPI")
Set objDeletedItems =
objNS.GetDefaultFolder(olFolderDeletedItems).Items

.....

Public Sub TimerFunc() ' It's the timer callback
If Not bCanRun Then Exit Sub

Dim Item As Object

If Not objDeletedItems Is Nothing Then
For Each Item In objDeletedItems
Item.UnRead = False
Next
End If
End Sub

I can't understand why this code might take up to 4-5 seconds to
execute, even on a slower system. I just noticed that if I disable the
ESET NOD32 antivirus plugin for Outlook, the execution time is
significantly shorter, but still too long. Disabling ESET NOD32 (version
4) alltogether doesn't change anything.

Now that I know where the problem is, I will investigate this further
and let you know. I guess that I don't see the problem on the dual core
system because the macro code is probably executed on a different
thread.

Thanks.

 

[Patrick Philippot]

I have an old macro that uses a 1 minute timer. This code always used
to run very quickly. This is what has changed. Now, it seems to take
much more time to run. Code excerpt:

Set objNS = Application.GetNamespace("MAPI")
Set objDeletedItems =
objNS.GetDefaultFolder(olFolderDeletedItems).Items

....

Public Sub TimerFunc() ' It's the timer callback
If Not bCanRun Then Exit Sub

Dim Item As Object

If Not objDeletedItems Is Nothing Then
For Each Item In objDeletedItems
Item.UnRead = False
Next
End If
End Sub

I can't understand why this code might take up to 4-5 seconds to
execute, even on a slower system.

I must mention that most of the time, objDeletedItems is empty or
contains only a few items. So the timer callback should execute in a
snap.

 

[Patrick Philippot]

I must mention that most of the time, objDeletedItems is empty or
contains only a few items. So the timer callback should execute in a
snap.

OK. Problem spotted.

Before installation, the "Empty the Deleted Items folder upon exiting"
option was enabled on all systems. After installation of the pre-SP2
patch, this option has been disabled on the french systems, not on the
english system. So there were hundreds of invisible deleted messages in
this folder. Consequently, the above quoted loop in the macro code took
a lot of time to execute.

Sorry for the trouble but it's good to know this.

 

[Milly Staples [MVP - Outlook]]

Thanks for the info but next time you may want to also post to a programming
group - that is where the experts in coding tend to hang out.

--
Milly Staples [MVP - Outlook]

Post all replies to the group to keep the discussion intact.
ALWAYS post your Outlook version.
How to ask a question: http://support.microsoft.com/KB/555375


After furious head scratching, Patrick Philippot asked:

| Patrick Philippot wrote:
||| I can't understand why this code might take up to 4-5 seconds to
||| execute, even on a slower system.
||
|| I must mention that most of the time, objDeletedItems is empty or
|| contains only a few items. So the timer callback should execute in a
|| snap.
|
| OK. Problem spotted.
|
| Before installation, the "Empty the Deleted Items folder upon exiting"
| option was enabled on all systems. After installation of the pre-SP2
| patch, this option has been disabled on the french systems, not on the
| english system. So there were hundreds of invisible deleted messages
| in this folder. Consequently, the above quoted loop in the macro code
| took a lot of time to execute.
|
| Sorry for the trouble but it's good to know this.

 

[Patrick Philippot]

Thanks for the info but next time you may want to also post to a
programming
group - that is where the experts in coding tend to hang out.

Milly,

It you re-read this thread more cautiously, you'll see that it's actually
not a programming problem but an installation problem. The macro issue was
only a consequence of the installation problem. There's no programming
problem at all.

 

[Brian Tillman [MVP - Outlook]]

It you re-read this thread more cautiously, you'll see that it's actually
not a programming problem but an installation problem.

Then microsoft.public.outlook.installation should be more appropriate.

 

[Patrick Philippot]

Then microsoft.public.outlook.installation should be more appropriate.

OK. But this was not known when starting the thread. Should I repost all
messages to microsoft.public.outlook.installation ?

 

[Brian Tillman [MVP - Outlook]]

OK. But this was not known when starting the thread. Should I repost all
messages to microsoft.public.outlook.installation ?

No, but perhaps a summary and a new description of the problem given what
you've discovered would be appropriate.