Can't change lock screen on windows 8.1

zachd,

I posted this elsewhere in this thread, but posting again in reply to you in hopes you see this, because I have a theory as to what is going on. Without know what the implementation is for the Windows 8.1 lock screen, I'm making a bunch of guesses. But here you go:

1. The problems appear to be caused by messed up permissions on the SystemData folder.
2. Deleting the SystemData folder entirely doesn't always solve the issue of not being able to change the lock screen.

My guess is that processed versions of lock screen images are being cached in the SystemData folder. You could confirm this. So perhaps I select a lock screen image that's too small for the current display, the processed version is saved in SystemData. Connect a new display to my machine, maybe plug an external monitor into my laptop, and the system will cache another processed version of the lock screen image(s).

Now if I delete the SystemData folder, the system should recreate those processed versions of the images as soon as it needs them. Except it appears that it does not. If I go into the control panel and try to select a lock screen image I've used before, it'll show the blank image for the lock screen on the control panel, and when I actually lock the screen, I'll get the default system image and not the one I tried to pick.

As Charles noted on this thread, if you use the control panel and select an image you've never used in the lock screen previously, it'll show up properly. After selecting five new images this way, suddenly 5 thumbnails of the images all appear on the control panel page under the currently selected image, and at this point you can select previously used images and they work too.

So it appears there is a cache of some sort that's not getting properly cleared when SystemData is deleted or corrupted. The lock screen code is looking at some list of images, thinks it's already processed them and stored the processed versions in SystemData, but when it goes to load them it gets an error. And because the control panel is checking this cache but not validating that the processed images are still avaiable in SystemData, choosing a previously-used image leaves this cache in a bad state.

The lock screen code and especially the control panel for choosing lock screen images should validate the cache entries, and if bad, flush them. This isn't happening, so users get confused when they try to fix it from the lock screen.

I don't know why the permissions on SystemData are getting messed up, but I do think you can make recovery much easier, and prevent more of these forum threads, if the control panel could properly clean up it's cache.

This is all assuming my guesses about the implementation are correct, which they might not be. But hopefully helpful in any case.

Jake

Hi Jake,

I appreciate the detailed technical report which you have presented with all the pros and cons about the issue and also gave a hint about the possible fix for the issue. You have guided people in the right direction as far as the issue was concerned.

If you need any further assistance with Windows Operating System, please post your query on Microsoft Community Forums and we’ll be glad to assist you with it.

It is possible that there is some sort of caching going on somewhere but deleting the SystemData folder does not get rid of it. I do not know the precise location at present but it could be cached in an individual user's AppData folder or somewhere related.  Even copying the pictures to another file using other names will allow the pictures to be selected again before it starts working again.  I did it that way and got the pictures to display.  I do know that there is caching of certain Start Screen items in the AppData folders as well.

Yes, I followed the steps to the letter and still no change. I also attempted to browse to my personal pictures folder and select images from there, and still no change. In running a system scan, it appears I have file unrecoverable file corruption, so it appears a complete system rebuild is in order. /sigh

Yes, the cache is probably just a list of full pathnames to the files - not a cache of the images themselves. There's a good chance it's stored in the registry, rather than a folder somewhere. This would explain why renaming a picture of moving it solves the problem. While the bad permissions on the SystemData folder appear to be a common cause of the failure, and we don't know why that would happen, Microsoft could make this much easier to recover from if they fixed the cache issue. The code fix is when selecting an image in the control panel, they need to not just check if it's already in the cache and assume the image will be present in SystemData, they need to also ensure they can open the file at that point, and if not, throw out the cache entry and recreate it. That way you wouldn't have to go and select five different pictures to get things working properly again.