Can't change lock screen on windows 8.1

Regarding the ACLs, right, and that is what I also suggested.  However, for the particular poster I addressed, s/he has worse issues afoot than the ACL problem.  (Another user here also could not get the Browse button to work, if I recall correctly, which also is a system issue).  The user I addressed with the post to which you recently responded, however, could not change ACLs/permissions and attempting it did not work.  Issues affecting one's ability to modify ACLs, however, do actually apply to the system (as you already know).  System corruption often can be fixed by chkdsk, sfc, and dism.

My most recent suggestions regarding chkdsk, sfc, and dism, were aimed at attempting to fix potential system corruption/missing system files issues, not the ACL problem.  Can't fix the ACL problem if the system is corrupted.  The poster suggesting that s/he couldn't run either sfc or dism points to far more serious problems afoot than the ACL problem involving the lock screen in Windows 8.1.

That, specifically, is what I was addressing with my 'objectionable' comment to that poster.  As you rightly point out, the ACL problem is a whole 'nother ballgame.  But, then, I was trying to help that poster get her/his system to a point where s/he could attempt to address the ACL issue.  You seem to have taken what I posted in another direction.  I just want the person who posted to get her/his system issues fixed before the ACL issue can be addressed.  Since s/he posted that here in this thread, I tried to help the poster here in this thread.

So, files containing the APIs used by the Lock Screen control panel aren't actually either system files or catalogued files? I have to say that this is news to me.

And, DISM doesn't actually clean up or repair the system image and configuration and replace it with the one put onto the hard drive by the installation process?

A: ? I don't believe I said that.  The issue isn't with the APIs used, it's with data storage and retrieval of that data.  Comparatively: you're low on gas, checking the seatbelts isn't going to do anything useful.

B: No matter what you get DISM to do, it's not going to know about the internal data storage/retrieval used by the Lock Screen.

Also, it should be recalled that I first mentioned several pages of posts back (in this very thread) a solution that worked for me (and which helped others), that didn't involve chkdsk, sfc, or dism (but I did mention that I ran those to cover potential bases and that they found and/or changed nothing for me).

It is just that if the person who posted that he could even get sfc and dism to run, he has more serious problems that need addressing, and that it could be related to potential missing or corrupted system files and/or configuration in addition to the usual potential causes to this thread's issue.

For me, it definitely was an issue with ACLs/permissions.  An update for some reason (never did figure out which update did it) removed the System user from the folders in question and allowed only TrustedInstaller access to those folders.  Adding that System user back made it all work again after creating a new list of lock screen pictures (and renaming copies of pictures already used and using the renamed pictures to rebuild the list).  But, I recall that I had to act fast before the system reverted back to the change before I could rename the SystemData folder.

Sure, and my comments back in those pages as regards ACLs/permissions stand. :)

I'm simply certain that people running SFC/DISM/chkdsk/etc. aren't going to make any progress whatsoever as regards this particular issue.  They might be running into *other* unrelated issues that those tools might cover, but -- those tools do not intersect with this problem area in any meaningful way.

It is not possible for corrupted "known" system files (such as SFC would know about) to produce this behavior.  The client behavior in that type of instance would be markedly different.  The "spinning failure" issue here is just not caused by corrupt system files or that kind of thing. :)

So, files containing the APIs used by the Lock Screen control panel aren't actually either system files or catalogued files? I have to say that this is news to me.

And, DISM doesn't actually clean up or repair the system image and configuration and replace it with the one put onto the hard drive by the installation process?

Also, it should be recalled that I first mentioned several pages of posts back (in this very thread) a solution that worked for me (and which helped others), that didn't involve chkdsk, sfc, or dism (but I did mention that I ran those to cover potential bases and that they found and/or changed nothing for me).

It is just that if the person who posted that he could even get sfc and dism to run, he has more serious problems that need addressing, and that it could be related to potential missing or corrupted system files and/or configuration in addition to the usual potential causes to this thread's issue.

For me, it definitely was an issue with ACLs/permissions.  An update for some reason (never did figure out which update did it) removed the System user from the folders in question and allowed only TrustedInstaller access to those folders.  Adding that System user back made it all work again after creating a new list of lock screen pictures (and renaming copies of pictures already used and using the renamed pictures to rebuild the list).  But, I recall that I had to act fast before the system reverted back to the change before I could rename the SystemData folder.

It's not an issue with cross-linked files, so chkdsk isn't going to help: we've tried that.

It's not relevant to SFC, as SFC only deals with catalogued files, and nothing in the afflicted set is directly part of a component.  It's all secondary aspects of a component which aren't encapsulated in CMI.

DISM also doesn't help in that it's not a servicing issue.

So yeah, we can throw those well-intentioned ideas out here:: they're probably not going to get anywhere useful.  :)  It's strongly believed to be a disconnect between the Lock Screen's private registry and the private file repository used by the Lock Screen.  Exactly what remains to be determined since I haven't seen a live instance of this, just online reports without machine access, but -- that's about where you want to focus people's time.  Either ignore it, set up a new account, or ... deal with the murky act of something like resetting the Lock Screen registry history here.

If the issue is with a corrupted or cross-linked file or files, it definitely can be touched by chkdsk.  Running chkdsk rules out file system corruption if it finds nothing.  Sfc replaces damaged or corrupted files with undamaged copies, as you well know.  If that is the source of the problem, that can and may be fixed by both sfc and dism.

If it is only a problem with an ACL or registry corruption (but then I seem to remember the poster above tried to change permissions, and so forth, as suggested earlier in the thread, and it did nothing), then it may or may not fix the problem, as you say.  But, why not rule out the other possibilities? It wouldn't hurt and would be no worse than preventative maintenance anyway if not.

In my experience, more than 50% of all service calls involving issues similar to this and related conditions that I have ever had to answer was fixed by running chkdsk.  For many situations it was my first choice to rule out a lot of what I have seen on people's computers over the years.  But, your mileage may vary.