Windows XP SP2 hangs while writing roaming profiles

[Michele Crudele]

Suddenly, after months of smooth operation, without any apparent
change in updates, SP, configurations, policies, etc, most of the
users of our AD domain (on Windows Server 2003 R2) had their Windows
XP SP2 PC blocked after a few minutes. In many cases they have to
switch off the PC: the CTRL-ALT-DEL does not work.
Monitoring the opened files on the server where the roaming profiles
are stored we discovered that some of the configuration files of many
applications (Office 2007, OpenOffice 2, Firefox, etc.) where listed
as No access ("nessun accesso" in Italian) insted of Reading or
Writing. The strange behaviour is that some files can write on the
APPDATA (Application Data) folders and some can not. For example, when
closing a Word 2007 file, it can't write the Normal.dotm even though
the temporary files are written by the same application on the
Templates folder: it seems it can't convert the temporary into plain
file.
When a user logs on locally on his/her PC, everything works fine:
therefore it seems that the problems is on the roaming profiles.
The event log says
Origin Microsoft Office 12
ID event 5000
Event type officelifeboathang, P1 winword.exe P2 12.0.6211.1000 P3
ntdll.dll P4 5.1.2600.2180 (the rest is NIL)

Unfortunately the word officelifeboathang gives no hint on
support.microsoft.com
The event 5000 refers to some problems with Exchange permissions, but
in our scenario the problem exists also with users not having an e-
mail account on our Exchange.
For the other applications the event log sais hungapp.
We changed the server where the roaming profiles are stored, placing
them on a fully opened share (Everyone, complete control), but the
behaviour does not change.

 

[Michele Crudele]

Re: Windows XP SP2 hangs while writing roaming profiles

On 27 Apr, 09:35, Michele Crudele <michele.crud...@gmail.com> wrote:
> Suddenly, after months of smooth operation, without any apparent
> change in updates, SP, configurations, policies, etc, most of the
> users of our AD domain (on Windows Server 2003 R2) had their Windows
> XP SP2 PC blocked after a few minutes. In many cases they have to
> switch off the PC: the CTRL-ALT-DEL does not work.
> Monitoring the opened files on the server where the roaming profiles
> are stored we discovered that some of the configuration files of many
> applications (Office 2007, OpenOffice 2, Firefox, etc.) where listed
> as No access ("nessun accesso" in Italian) insted of Reading or
> Writing. The strange behaviour is that some files can write on the
> APPDATA (Application Data) folders and some can not. For example, when
> closing a Word 2007 file, it can't write the Normal.dotm even though
> the temporary files are written by the same application on the
> Templates folder: it seems it can't convert the temporary into plain
> file.
> When a user logs on locally on his/her PC, everything works fine:
> therefore it seems that the problems is on the roaming profiles.
> The event log says
> Origin Microsoft Office 12
> ID event 5000
> Event type officelifeboathang, P1 winword.exe P2 12.0.6211.1000 P3
> ntdll.dll P4 5.1.2600.2180 (the rest is NIL)
>
> Unfortunately the word officelifeboathang gives no hint on
> support.microsoft.com
> The event 5000 refers to some problems with Exchange permissions, but
> in our scenario the problem exists also with users not having an e-
> mail account on our Exchange.
> For the other applications the event log sais hungapp.
> We changed the server where the roaming profiles are stored, placing
> them on a fully opened share (Everyone, complete control), but the
> behaviour does not change.

We discovered that the problem is Trend Micro Antivirus. Disabling it
on the clients, all the PC's go back to normal behaviour, while on the
servers it kept running. It seems that is was an automatic update of
the antivirus at the beginning of the week 2008-04-21 that caused the
failure. We informed the Trend Micro help desk through our reseller,
because they did not allow direct contact. We had to wait some days to
receive a patch which was supposed to solve the problem. We did not
test it, because in the meanwhile we had decided to abandon Trend
Micro and we have shifted to Kaspersky.