Userenv errors in event viewer

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi

I have been having problems with roaming profiles in our
environment and hope that someone out there can help me.
We have one DC running Win2k and all the clients are
WinXP.

Here are the errors I am seeing in the event log on the
machines for several of the users:

1)Windows cannot update your roaming profile. Possible
causes of this error include network problems or
insufficient security rights.
If this problem persists, contact your network
administrator.

DETAIL - The process cannot access the file because it
is being used by another process.


2)Windows cannot copy file C:\Documents and
Settings\username\Local Settings\Application
Data\Microsoft\Windows\UsrClass.dat.LOG to
location \\servername\profiles\username\Local
Settings\Application
Data\Microsoft\Windows\UsrClass.dat.LOG. Possible causes
of this
error include network problems or insufficient security
rights. If this problem persists, contact your network
administrator.

DETAIL - The process cannot access the file because it
is being used by another process.


I read some documentation on Microsoft's site referencing
what the permissions should be set to for the profile
directory, share permissions, and permissions on each
individual's profile folder. Permission have been set
correctly. Any ideas?

I am also curious as to how the owner of the user's
profile folder affects the updating of the user's
profile. Any assistance you can provide will be greatly
appreciated. Thank you.

Candis
 
Candis,

The user *must* be the owner of the files in it's profile, in my experience.
Anything else will cause an error during profile replication. Other users
can have differing permissions to the user's profile, but the user must be
the owner.

Secondly, there are a few other things you can try:

The User Profile Hive Cleaner (UPHClean) is a Windows NT service that runs
on the local workstation, and will help make sure that registry handles are
closed before the profile is copied back to the server. This is supposed to
cut down on "file in use" error messages.

You can download UPHClean here:
http://www.microsoft.com/downloads/...6D-8912-4E18-B570-42470E2F3582&displaylang=en

You can also enable enhanced debugging on the UserEnv process to try and
track down more specific error conditions during logon/logoff. Details
about how to do this can be found here:
http://support.microsoft.com/default.aspx?scid=kb;en-us;221833
 
Mike

Thanks for the info. I have actually installed the user
UPHclean utility on the workstations in question and the
culprits seem to be the svchost.exe process and
rtvscan.exe process. So I have to figure out if there is
anything I can do now to get these processes to release
as the user logs off because right now its not happening.
Thanks for all help and I welcome any more assistance you
can provide.

Candis
 
No problem, Candis.

At this point, try going through the instructions to enable the Enhanced
UserENV Debugging, and set the value to 10002.

If you'd like, I'd be happy to take a look at the log file that setting
generates. Before you reboot the system after making that registry change,
please see if the log file already exists (Windows will log to that file in
the event of bigger errors). If it does, delete it, or rename it, then
reboot.

Once the system comes back up, logon with an account that exhibits the error
you're seeing, and then log out. That should collect sufficient info.

Since binary attachments aren't typically appreciated in this group, feel
free to e-mail me the log directly. Remove the obvious part from the e-mail
address I post with to get my correct address :)

Question about Svchost.exe - when the user logs out, are they presented with
an error message about Svchost.exe not responding? When they log in to the
system, does the SysVol folder on the Domain Controller open up, or are they
presented with another, amazingly cryptic error message? Is this only
happening to *some* users, or to *all* users?
 
Mike

Regarding the UserEnv Debugging, I have turned it on and
will email you a copy(or copies) of the log once I get
sufficient information.

Regarding svchost, the user's aren't getting any
indication that the svchost is not responding.
Periodically users may get an error stating that they are
being logged on with a temporary profile and that any
changes they make will not be saved.

I did notice in the event viewer that following the
error "windows cannot unload your classes registry file",
that there is an error referencing copying a
Userclass.dat file from the user's local profile on the
box to the roaming profile on the server. The folder
that the file is stored in, "local settings", is stated
to be a non-roaming profile by Microsoft. So I am
confused as to why the system is trying to copy a file to
the romaing profile if that folder is not supposed to
roam. Is this something to ignore? I'm not sure. In
addition, I have enabled the setting in AD Group Policy
that states that the local copy of the user's profile is
deleted when they log off. Not sure if this all ties in
together, but I'm thinking it does.

This doesn't seem to be happening to everybody, just some
users.

Your thoughts??

Thanks

Candis
 
This doesn't seem to be happening to everybody, just some
users.
Click to expand...

I'm still thinking about all the other information, but I'm curious about
the above statement.

If a user why isn't experiencing the problems logs onto a machine where some
user did, do they then have the problem? What about the inverse - if a user
who is having problems logs onto a machines where nobody has had problems
before, do they still have the problem?

I'm trying to sort out whether this is a user problem or a computer problem.

Thanks!
 
Mike

One other thing, regarding the svchost. I did some
research to further understand that svchost file and it
states that its a "application that works as a host
process for services that run from dynamic link libraries."
Now the events in the event viewer reference source
Userenv. The userenv.dll file is a "file that contains
application programming interface (API) functions to
create and manage user profiles."

So it seems that these two are correlated, I just don't
yet understand how to fix the problem.

Some additional info

The workstations that the users are logging into were
recently reimaged. Previously the users had local admin
rights on the box as a workaround to some other problems
we were having, so I reimaged the box and the users just
have the standard permissions now that are set with
Windows Professional. Not sure if this would have any
effect but I wanted to add this in just to give you some
background info.

I'll be emailing the logs to you shortly.

Thanks.
 
Back
Top