Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

Windows 10 mandatory profiles are not deleted as expected at logoff


View products that this article applies to.

Symptoms

Consider the following scenario:
  • You have configured users to use a mandatory profile in a particular environment.
  • You have configured Group Policy to delete the local copy of the profile during logoff, as follows:
    Computer Configuration\Administrative Templates\System\User Profiles 
    "Delete cached copies of roaming profiles" 
  • A user logs on to a computer in the environment, and then logs off.
In this scenario, the local copy of the profile is not deleted as expected.

↑ Back to the top


Cause

This issue occurs because certain files inside the user's profile are in use during the logoff. This prevents the profile from being deleted. The files are held by a svchost.exe process in which the TileDatamodelsvc service runs. The specific files are:

C:\Users\name\AppData\Local\TileDataLayer\Database\EDBtmp.log

C:\Users\name\AppData\Local\TileDataLayer\Database\vedatamodel.edb

↑ Back to the top


More Information

If you collect the Process Monitor log during the failure, it shows a SHARING VIOLATION error that resembles the following during logoff:

process name PID TID Path
svchost.exe 1244 WriteFile 3024 C:\Users\TestUser1\AppData\Local\TileDataLayer\Database\vedatamodel.edb SUCCESS Offset: 319,488, Length: 4,096, I/O Flags: Write Through, Priority: Normal
svchost.exe 924 CreateFile 1696 C:\Users\TestUser1\AppData\Local\TileDataLayer\Database\vedatamodel.edb SHARING VIOLATION Desired Access: Read Attributes, Delete, Disposition: Open, Options: Non-Directory File, Open For Backup, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, Impersonating: NT AUTHORITY\SYSTEM
svchost.exe 924 CreateFile 1696 C:\Users\TestUser1\AppData\Local\TileDataLayer\Database\vedatamodel.edb SHARING VIOLATION Desired Access: Read Attributes, Delete, Disposition: Open, Options: Non-Directory File, Open For Backup, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, Impersonating: NT AUTHORITY\SYSTEM
svchost.exe 924 CreateFile 1696 C:\Users\TestUser1\AppData\Local\TileDataLayer\Database\vedatamodel.edb SHARING VIOLATION Desired Access: Read Attributes, Delete, Disposition: Open, Options: Non-Directory File, Open For Backup, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, Impersonating: NT AUTHORITY\SYSTEM
svchost.exe 924 CreateFile 1696 C:\Users\TestUser1\AppData\Local\TileDataLayer\Database\vedatamodel.edb SHARING VIOLATION Desired Access: Read Attributes, Delete, Disposition: Open, Options: Non-Directory File, Open For Backup, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, Impersonating: NT AUTHORITY\SYSTEM
svchost.exe 1244 QueryDirectory 1176 C:\Users\TestUser1\AppData\Local\TileDataLayer\Database\vedatamodel.edb SUCCESS Filter: vedatamodel.edb, 1: vedatamodel.edb

Note PID 1244 is TileDatamodelsvc, and PID 924 is profsvc. Here you can see that TileDatamodelsvc PID 1244 has a lock on the vedatamodel.edb file and is writing to it when profsvc tries and fails to delete the files. You can also see that svchost.exe 1244 is still writing the file after the profile unload
is finished. 

↑ Back to the top


Keywords: kbexpertiseadvanced, kbsurveynew, kbtshoot, kb

↑ Back to the top

Article Info
Article ID : 3141610
Revision : 1
Created on : 1/7/2017
Published on : 8/23/2016
Exists online : False
Views : 549