Why doesn’t my lock screen image change after I replace the image file?


A customer was using the group policy "Force a specific default lock screen and logon image" to set the lock screen image to their company's logo, pointing it to a path on the local computer. The company recently redesigned their logo, and they updated the image file on the computer, but the lock screen continued to show the old image. The customer wanted to know how to get the image to update.

When the lock screen image is set, the system uses a low-privilege process to decode the image. That way, if someone passes an image that exploits a previously-unknown defect in the image processing library, only a low-privilege process is compromised. The result is then re-encoded and saved in a protected location.

It is this sanitized version of the image that is used on the lock screen and logon screen. This avoids the problems that could occur if an untrusted image were decoded by a high-privilege process.

When you select an image to use as your lock screen image, the system takes a snapshot of that image, and it is the snapshot that is used on the lock screen. Any changes to the original image are ignored. You could even delete the original.

If you want to update the image, you need to go through the process of setting it. You can't just smash the file that you specified as the lock screen image; the system doesn't care about that file once it has been captured.

In the case of group policy, there's another wrinkle: If you choose to deploy a new image and it has the same name as the old image, then the new file must have a timestamp newer than the timestamp of the old file, so that the code realizes that it needs to go sanitize the new image. Easier is to just give the new file a new name.

Comments (11)
  1. Useful information, thanks.

  2. Entegy says:

    Once again, your article is timed perfectly with something I’m about to deal with. Thanks!

  3. I found out some of the above by accident (not the low-privilege process part though; being prepared for future exploits there is pretty clever). I have a setup where most[1] of the profile of User A is stored on a special drive[2] and I must log in as User B to enable the drive before logging in as User A[3]. I had the clever idea of setting the login screen background to a picture on the special drive so it would fail to show up if the drive was unavailable. Pretty soon I found that the image is cached so my clever plan doesn’t work.

    [1] Windows provides a UI button in all the special profile folders’ properties boxes to let you move the normal folders that hold their content. I found that moving …/AppData/Local to another drive causes many programs like the start menu and Edge to be not-runnable after next login, so I’ve kept that on the normal drive. It’s a pity because the web cache within …/AppData/Local is just the sort of thing I’d want to move.

    [2] It’s a Truecrypt volume mounted at a drive letter. I’d encrypt the whole drive but for some reason me attempting to encrypt the whole volume causes Truecrypt to do its preliminary install, but after rebooting roll back the change, presumably because a check in the preliminary install indicated full encryption would make the machine unbootable.

    [3] Also I have to log out of User A and log in as User B to shut down the machine so at next startup Windows doesn’t try to (AFAICT) pre-fetch User A’s profile and end up caching the “missing” files. I’m kinda surprised that Windows doesn’t handle missing drives better in this situation because of situations like profiles being on network drives, though I guess in that case the drive is *defined* and inaccessible, as opposed to a non-mounted Truecrypt volume which is just not defined yet.

  4. I found out some of the above by accident (not the low-privilege process part though; being prepared for future exploits there is pretty clever). I have a setup where most[1] of the profile of User A is stored on a special drive[2] and I must log in as User B to enable the drive before logging in as User A[3]. I had the clever idea of setting the login screen background to a picture on the special drive so it would fail to show up if the drive was unavailable. Pretty soon I found that the image is cached so my clever plan doesn’t work.

    [1] Windows provides a UI button in all the special profile folders’ properties boxes to let you move the normal folders that hold their content. I found that moving …/AppData/Local to another drive causes many programs like the start menu and Edge to be not-runnable after next login, so I’ve kept that on the normal drive. It’s a pity because the web cache within …/AppData/Local is just the sort of thing I’d want to move.

    [2] It’s a Truecrypt volume mounted at a drive letter. I’d encrypt the whole drive but for some reason me attempting to encrypt the whole volume causes Truecrypt to do its preliminary install, but after rebooting roll back the change, presumably because a check in the preliminary install indicated full encryption would make the machine unbootable.

    [3] Also I have to log out of User A and log in as User B to shut down the machine so at next startup Windows doesn’t try to (AFAICT) pre-fetch User A’s profile and end up caching the “missing” files. I’m kinda surprised that Windows doesn’t handle missing drives better in this situation because of situations like profiles being on network drives, though I guess in that case the drive is *defined* and inaccessible, as opposed to a non-mounted Truecrypt volume which is just not defined yet.

  5. Harold H20 says:

    <> the system uses a low-privilege process to decode the image. . . . . The result is then re-encoded and saved in a protected location.<>
    How is a “low privilege” process able to save a file to a “protected location? Doesn’t that defeat the purpose of a low-privilege process and protected location?

    1. Use your imagination. One possibility: The low-privilege process hands the decoded pixels back to the high-privilege process. The high-privilege process re-encodes the pixels and saves them in a protected location.

  6. I figured this one out for myself when I tried to replace that drab beach-and-cave image of Windows 10 without users screaming at me for having lost Windows Spotlight.

    Of course, now that the Spotlight is permanently lost, I think I can use group policy without reverse-engineering Windows and committing copyright violation (even though the violation is de minimis).

    1. DWalker says:

      Spotlight hasn’t been “permanently lost”. It works for me and everyone I support.

      1. Microsoft servers have ceased serving contents in two dozens of countries in the world. Spotlight is host on those servers and I live in one of those countries.

  7. Drak says:

    So, is this also the reason that my perfectly beautiful BMP gets mangled into an JPG of questionable compression?

  8. Anonymous says:
    (The content was deleted per user request)

Comments are closed.

Skip to main content