profile error

[rwiedower]

Several of my users occasionally have received the following error messages
when they attempt to login to their workstations. After the message is
displayed, the profile fails to load which causes numerous problems. The
only way to unlock the file in question is to reboot the entire machine. Any
idea what might be causing this?

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1509
Date: 10/9/2003
Time: 9:41:02 AM
User: WINDOMAIN\xxxxxx
Computer: ICEBOX
Description:
Windows cannot copy file \\fileserver\profiles\xxxxxx\Cookies\index.dat to
location C:\Documents and Settings\xxxxxx\Cookies\index.dat. 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.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

What process would lock out the cookie file if a user wasn't logged in?

end of line,

Reed Wiedower

 

[BT]

It might be a server side process.

 

[Eric Shen [MSFT]]

Hi Reed,

Thank you for your post.

This issue is probably caused because the Cookie information is uploaded to
the profile server and unexpectedly locked. To know which process is
accessing this file, we can try to use a third-party utility as
SysInternals handle. Please refer to the following page regarding this
utility:

http://www.sysinternals.com/ntw2k/freeware/handle.shtml

With this utility, you will see all the opened file handles on the
computer.

An alternative way to avoid this issue is to exclude the Cookies folder
from roaming profile so it will not try to upload this folder. You can try
to exclude this folder by using the following article:

188692 How to Prevent Certain Folders from Uploading to Central Profile
http://support.microsoft.com/?id=188692

- This will cause the cookie information on the computers are not
synchronized but will not affect your main functionality.

Please check the above information and then let me know how it works. I
look forward to hearing from you.

Regards,

Eric Shen
Product Support Services
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.

Get Secure! - www.microsoft.com/security

 

[Carrie Garth \(MVP\)]

Hi Reed,

I have not verified this myself, and I am unable to find any supporting Microsoft
documentation, however according to Jerker Skånberg the "Automatic Updates" Service
can hold open a handle to ...\Cookies\Index.dat. If the Service is Started, you may
want to Stop it to see if that is the culprit.

To read the entire newsgroup post on the subject and for some details on how to
determine what process has the open handle, see the following newsgroup exchange:

Google Groups URL to archived newsgroup thread:
http://www.google.com/groups?&[email protected]

----- Begin Original Message Header -----
From: jerker.skanberg AT spray DOT se (Jerre Essberg)
Newsgroups: microsoft.public.win2000.general
Subject: Re: Cannot copy a Domain User's Profile to Default User Profile
Date: 24 Sep 2003 05:35:13 -0700
Message-ID: <[email protected]>
----- End Original Message Header -----

And for information about turning off the Windows Automatic Updates Feature see:

KB824595 - Windows Automatic Updates Feature May Be Turned Back On
When You Install Windows
http://support.microsoft.com/?scid=824595

And if it does turn out to be a Windows Update problem and you have additional
questions on the subject, I suggest that you post in a WU newsgroup such as:
microsoft.public.windowsupdate or microsoft.public.win2000.windows_update

 

[rwiedower]

Unfortunately, I haven't been able to replicate the problem through Windows
Update. I have been able to verify, through the "handle" utility recommended
above that several processes grab the "cookies\index.dat" file during normal
usage.

Unfortunately for the Windows Update idea to work, a user would have to be
logged in while WU was updating, which would happen quite rarely. as WU is
set to run at 2:00 AM each day. Theoretically, though, a user could've left
themselves logged in over night. However, I'm going to bunker down, wait for
the next occurrence to arrive, and check on the process and file locks when
that happens.

Thanks for the help, everyone. I'll update this thread as soon as I get more
info about what's causing it.

end of line,

Reed

 

[Eric Shen [MSFT]]

Hi Reed,

I am just writing as a follow-up on this issue to see if there is anything
further I can do for you. I am looking forward to your reply.

Regards,

Eric Shen
Product Support Services
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.

Get Secure! - www.microsoft.com/security

 

[Reed Wiedower]

As this problem has not reoccurred, I'm going to stop worrying about it. If
it crops up again I'll try some of the methods we discussed.

 

[Reed Wiedower]

Okay, the problem just occurred again. Here's what I did:

1) I ran the "handle.exe" program to determine what was locking the file.

2) I attempted to stop the "Windows Update" service to see if that was the
problem. It wasn't.

Using the handle executable, I was able to determine that the svchost.exe
process was locking the cookies\index.dat file which was preventing the
copying of the profile. Given the sheer number of services that use
svchost.exe to run, it wasn't possible for me to stop each one and see if
the file was unlocked. I did save a copy of the handle output in case that's
helpful for troubleshooting/

Any idea what avenues I can attempt to try next?

end of line,

Reed Wiedower

As this problem has not reoccurred, I'm going to stop worrying about it. If
it crops up again I'll try some of the methods we discussed.

Hi Reed,

I am just writing as a follow-up on this issue to see if there is anything
further I can do for you. I am looking forward to your reply.

Regards,

Eric Shen
Product Support Services
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.

Get Secure! - www.microsoft.com/security

 

[Eric Shen [MSFT]]

Hi Reed,

Svchost.exe is a generic process, which acts as a host for other processes
running from DLLs; therefore, don't be surprised to see more than one entry
for this process. To see what processes are using Svchost.exe, use
Tlist.exe from the Windows 2000 CD-ROM; the syntax is tlist -s at the
command prompt.

With the information about the services running with Svchost.exe, we can
check if this is normal. Also, some virus or Trojan may use this name to
confuse the users. If you see multiple Svchost.exe, please get the handle
of the process that locks the index.dat and then use tlist -s to see which
process it is.

For more information on Svchost.exe and tlist.exe, please refer to the
following articles:

250320 Description of Svchost.exe in Windows 2000
http://support.microsoft.com/?id=250320

246926 Folder Listing of the Support Tools Included in Windows 2000
http://support.microsoft.com/?id=246926

With the information about which process is locking the file, we can stop
this service for a test.

Please try these steps and then let me know the results. I look forward to
hearing from you.

Regards,

Eric Shen
Product Support Services
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.

Get Secure! - www.microsoft.com/security

 

[Reed Wiedower]

Unfortunately, the svchost in question is also the one running the most
services. So far I've got it using:

1004 svchost.exe Svcs:
AudioSrv,BITS,Browser,CryptSvc,Dhcp,dmserver,ERSvc,EventSystem,helpsvc,lanma
nserver,lanmanwo
rkstation,Messenger,Netman,Nla,Schedule,seclogon,SENS,ShellHWDetection,srser
vice,TermService,Themes,TrkWks,uploadmgr,W32
Time,winmgmt,wuauserv,WZCSVC

That's 26 different services...is there any chance I can use the information
contained within the handle dump to eliminate some of these services before
I try them all out? Here's the handle dump info right above the locked file
info:

d64: Thread svchost.exe(1000): 1916
d68: Thread svchost.exe(1000): 1408
d6c: Event
d70: File C:\Documents and Settings\mmohib\Cookies\index.dat

For instance...does this mean that I can trace the instance by the thread
number? (I would assume that thread 1408 in the 1000 process is causing the
error.) If I know the thread number that's causing the error, how can I move
from that to the service name?

end of line,

Reed Wiedower

 

[Eric Shen [MSFT]]

Hi Reed,

Actually, we should run handle at the same time so we can find which
service is accessing this file. Generally, the step would be:

1. Run Handle to find which process ID is locking the index.dat.

2. Run Tlist to find which service is hosted in this process ID.

I suggest you run handle followed by > C:\handle.txt so the information can
be saved into C:\handle.txt. Also, run tlist followed by > C:\tlist.txt.
Then send the two files to me and I will be able to check with process and
which service (possible) is locking this file.

Also, you can use the GUI handle utility from System Internals (Process
Explorer) downloaded at
http://www.sysinternals.com/ntw2k/freeware/procexp.shtml to see which
process is accessing this file.

With the output of process explorer, you will see the PID of the process
which locks the index.dat (to find index.dat, you can use "Find"->"Find
Handle"). With this PID and the Tlist -s output, you will be able to see
which process is locking the file. Check the services held by this process,
we can eliminate the other services and focus on these for troubleshooting.

Also, as different operating system will have different service list so
please let me know the detailed information regarding your operating
system.

I look forward to hearing from you.

Regards,

Eric Shen
Product Support Services
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.

Get Secure! - www.microsoft.com/security