locked
Win10 1607 - "Force a specific default lock screen and logon image" is unreliable RRS feed

  • Question

  • When using "Force a specific default lock screen and logon image" to display a particular image prior to the user logging on, in some circumstances the image is not displayed and you get a solid colour instead.

    Tested using Enterprise 14393.693, which I think is current.

    The following registry keys are set (directly, not via GPO):

    • hklm\Software\Policies\Microsoft\Windows\Personalization - LockScreenImage = path\on\disk\to\image.jpg
    • hklm\Software\Policies\Microsoft\Windows\Personalization - LockScreenOverlaysDisabled = 1
    • hklm\Software\Policies\Microsoft\Windows\System - DisableLogonBackgroundImage = 0

    Having placed an appropriate image in the path specified, and set the keys, the image is displayed before login.

    If you then update the image on disk with a newer one and reboot or log out, you get a solid colour instead of that image.

    One of two things will then happen, seemingly at random. Either you get the solid colour (with date/time and network status indicator on top of it) for 10 seconds or so, and it then switches to the updated lock screen image, or you get the solid colour indefinitely.

    When the solid colour is displayed indefinitely, letting the machine power save or powering it off via the power button does not help - it will still be a solid colour after resuming or powering back on.

    However, if you press a key (or CTRL+ALT+DEL if you have that turned on) to get to the login screen proper (still a solid colour background at this point) and then let that time out and return to the lock screen, the image will then be displayed correctly. Actually logging on and off again, or logging on and restarting, doesn't fix it - only letting the login screen time out and revert to the lock screen does so.

    Once the bitmap is displayed correctly, it will work correctly thereafter, until the next time the file on disk changes.

    In our case, we update the file on disk occasionally for staff systems, but daily on student systems (we show the list of bookings for that room for that day, so that users can see this before they login). In all cases the image is generated at the native resolution.

    This is reproducible with both Current Branch for Business and Long Term Servicing Branch (Enterprise 14393.693 in both cases). So far, CBB seems more likely to do the solid-colour-indefinitely thing, but I've reproduced that behaviour on both branches.

    It looks like, after changing the file on disk, something in windows has to update in order for it to work properly. It's clearly noticing that the image has changed, as that's what causes the solid colour, but some other step is needed for it to use the new image, and that isn't happening automatically, or not reliably. Letting the login screen time out and revert to the lock screen seems to trigger whatever it is that's needed for it to start using the new image.

    This was working fine in 10240 and 10586.


    Friday, February 3, 2017 3:39 PM

Answers

  • A possible workaround:

    At startup when the pre-login lock screen is supposed to be displayed, it notices that the source image referenced by the policy has been updated, and the cached version plus thumbnails in ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P should be rebuilt.

    Something goes wrong with this, or has a chance of going wrong, the LockScreen_P folder is left empty, and a solid colour is displayed instead.

    This LockScreen_P folder is not accessible to an elevated account, only the local system account. However, we can run things as the local system account using a scheduled task.

    So, the workaround is to have a scheduled task (with a ONCE trigger set some point in the past so that it never runs unless triggered manually). This task clears out the LockScreen_P folder and populates it with the updated source jpg, as lockscreen.jpg. Experimentally it seems that this is the only one you need, and the system will populate the others as and when it needs them.

    This task can then be triggered manually whenever anything updates the source image for that machine. End result, it is now possible to replace the prelogin lock screen image on a regular and automated basis, and have it actually display properly and reliably on 14393.

    It shouldn't be necessary to have to resort to things like this to get basic functionality working, but at least we have a way forward. This was the last remaining show stopper for going ahead with 14393 in our environment, and moving to it this summer for our student machines.

    • Marked as answer by Mike Sandells Thursday, March 23, 2017 4:18 PM
    Thursday, March 23, 2017 4:13 PM

All replies

  • Hi,

    Firstly, the group policy object "Force a specific default lock screen and logon image" only would add the registry entry below.

    There are no other two entries like yours. Why didn't you use the GPO directly?

    I only use above one entry, and it works fine after changing the image.

    Please delete another two entries for test.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, February 6, 2017 6:08 AM
  • Hi,

    Firstly, the group policy object "Force a specific default lock screen and logon image" only would add the registry entry below.

    There are no other two entries like yours. Why didn't you use the GPO directly?

    I only use above one entry, and it works fine after changing the image.

    As mentioned, this is not always reproducible. In some cases the correct image will be displayed after a few seconds. In other cases, it doesn't appear no matter how long you wait. I've been trying on a couple of test systems (one CBB, one LTSB) and I'm able to reproduce it most of the time (hence "unreliable", not "doesn't work").

    Those extra keys are related to other settings we were making that relate to the pre-login image and I included them for completeness. Removing them makes no difference - I'm still able to reproduce the problem easily.

    We're doing these keys directly rather than by GPO because we need them in place prior to domain join, such that a machine with our image on it displays something informative if it's booted off our network or is otherwise unable to auto-login and proceed automatically. Once domain joined, all we ever do is update the image on disk so we've never needed to put the setting in a GPO. I'll test that and see if it makes a difference.

    Other things tested in the meantime, which also don't help - once in the state where a solid colour is being displayed instead of the correct image, issuing a gpupdate /force does not change anything. Likewise copying the file on disk to a new name and changing the lock screen registry key to point to the new file also does not fix it.

    Once in the state where a solid colour is displayed, the only known fix so far is bringing up the login dialog then allowing it to time out and revert to the lock screen.

    The fact that it's not reproducible every time may mean there is some timing issue, even though everything is already locally set. Both my test machines have SSDs, and so boot very quickly. I'll test on slower hardware to see if that is more likely to fail or succeed.

    Monday, February 6, 2017 10:13 AM
  • Just to follow up on the reproducibility of this, having done more testing on various PCs. This is with just the LockScreenImage registry key set.

    • Problem happens around 50% of the time, slightly less than my original impression, but still easily reproducible. Randomness means that it may work correctly several times in a row (and conversely, may fail several times in a row).
    • Problem is reproducible when changing the image file on disk and rebooting and when changing the image and signing out.
    • The problem is equally reproducible on older hardware with a traditional HD and on current hardware with an SSD.
    • Adding a short delay between changing the image on disk and signing out or rebooting seems to have no effect on the issue.

    I'll try forcing the setting with a GPO, but I would expect this to be just another way of getting that registry key set.


    Monday, February 6, 2017 2:41 PM
  • Problem is reproducible when the setting is coming from a GPO.

    Any suggestions for what to try next?

    Monday, February 6, 2017 4:07 PM
  • For want of a better idea, I tried using Process Monitor boot logging to see what was going on at boot when the problem is in place (i.e. solid colour instead of lock screen image), and to log what happens when the problem is fixed by allowing the login dialog to time out and revert to the lock screen.

    This shed some light on what's going on, but not on why.

    In normal circumstances there is the jpg we specify, and in our case that happens to be local to the device (and generated for that device and so unique to every device). Once the policy is set to use that as the lock screen, versions of that jpg are generated in C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P. These include:

    • lockscreen.jpg
    • lockscreen___0108_0108.jpg
    • lockscreen___0151_0151.jpg
    • lockscreen___0194_0194.jpg
    • lockscreen___1920_1080_notdimmed.jpg

    The last one seems to be named based on the screen resolution. The other names are consistent.

    These are not copies of the original image - the size varies slightly from the original image we supplied, even for those that are the same resolution. Our original is 200KB, lockscreen.jpg is 193KB, the version with the screen resolution in it is 192KB, the others are small thumbnails.

    When things are working normally, the above set of files exist in that folder, generated from our image, and with later timestamps than our image.

    When the problem is occurring, and we're getting a solid colour on boot or sign-out, the C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P folder is empty. The modification time on that folder is shortly after the timestamp of our updated image on disk, indicating that it was emptied just after our image was updated, but not populated with new images for some reason.

    This state then persists as described in earlier posts - unaffected by logins, reboots, gpupdate /force, etc. So far it is only affected by allowing the login screen to time out and revert to the lock screen. At which point, the LockScreen_P folder is populated with a set of files based on our image, with timestamps that match the time that the login reverted to the lock screen. Once these files are in place, things are fine until the next time our image is updated.

    The C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P folder is locked down to the point where it's difficult to access from within that copy of windows, so it's tricky to observe this directly. Rather than try to forcibly reset the rights on it (which might change things that I'm trying to test), I'm seeing what's in it by rebooting into a WinPE boot and looking at the C: drive from there. This works, but means it's difficult to see what's going on there during the windows session.

    This looks like a bug.

    Tuesday, February 7, 2017 11:58 AM
  • I think I now know why there were problems reproducing this. Another policy setting is involved.

    I started from scratch with a bare metal installation of 14393 Enterprise, and allowed it to update itself. I then set just the lock screen policy and tried to reproduce the problem with no success. I then started looking at what else might be interacting with this from our production environment and have narrowed that down to another policy setting - "Interactive Logon: Do not display last user name".

    With just "Force a specific default lock screen and logon image" set to a jpg on the local disk, and "Interactive Logon: Do not display last user name" enabled, I can reproduce this on a completely vanilla system, not joined to our domain or subject to any of our other policies.

    The intermittent nature of the problem is unchanged when using a vanilla install. I've tried three times and reproduced the problem twice, so it's easily reproducible, but a couple of failed attempts at reproducing the problem doesn't mean much.

    For reference, I'm using a script which uses copies a new jpg into place, sleeps 10 seconds, then triggers a sign-out via shutdown /r. Varying the length of the delay or rebooting instead of signing out made no difference in my original tests.

    As before, when the solid colour is being displayed in place of the correct lock screen image, the C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P folder is empty, and that folder has a slight later modification timestamp than the configured lock screen image. Something emptied it, but didn't populate it again.

    Tuesday, February 7, 2017 4:15 PM
  • Hi Mike,

    So what if you disable or not configure the "Interactive Logon: Do not display last user name" policy?

    In addition, the latest build is OS Build 14393.729. Please make your computer to up to date to see if the issue gone.

    https://support.microsoft.com/en-us/help/4000825/windows-10-and-windows-server-2016-update-history


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Thursday, February 9, 2017 9:02 AM
  • I'm still able to reproduce the problem on 14393.729.

    As before, roughly 50% of the time I get a solid colour instead of the logon image after updating the file on disk. Once in that state no amount of logons or reboots fixes it, only allowing the login screen to time out back to the lock screen.

    So far, I've not been able to reproduce the problem with "Interactive Logon: Do not display last user name" disabled or not configured. It looks like the problem is an interaction between this policy setting and the force logon image policy. However, turning the interactive logon policy off would not be an option in our production environment, so while it's interesting for diagnostic purposes, it's not a workaround.

    When the interactive logon policy is not set, it looks like the lockscreen images are created in a different location - instead of being in a S-1-5-18 folder under ProgramData\Microsoft\Windows\SystemData, there are in a folder with a full real SID as the name (presumably this is the SID of the last user to use the PC).

    Friday, February 10, 2017 1:59 PM
  • Hi Mike,

    According to your detailed information, I finally reproduce the same situation as yours.

    Please submit this feedback via the built-in Feedback app.

    And I would also submit it via our own channel. Hope it would be fixed soon.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, February 14, 2017 9:30 AM
  • Thanks for this and sorry for the delay in replying - I was out of the office last week.

    I've now submitted feedback via the feedback app, including some screenshots gathered via a hardware VNC device, which seemed the easiest way of capturing what's happening at the login dialog:

    1. Initial logon screen, solid colour
    2. Logon dialog, having pressed a key
    3. Fixed logon screen, having allowed the logon to time out.

    As part of doing this, I've also found another temporary fix for being in the state where you get the solid colour - changing the screen resolution. Neither of these are useful as workarounds though, and the problem can recur the next time the image on disk changes.

    Meanwhile, as mentioned on another thread, I can't get "force a specific default lock screen and logon image" to work at all on the latest insider preview ISO (15025). I've submitted feedback about that as well.

    Tuesday, February 21, 2017 3:46 PM
  • Mike,

    Ok. That's fine.

    Let's hope it will be fixed soon.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, February 22, 2017 6:37 AM
  • Still reproducible in 14393.953

    Any idea when we'll see a fix for this?

    Monday, March 20, 2017 4:11 PM
  • A possible workaround:

    At startup when the pre-login lock screen is supposed to be displayed, it notices that the source image referenced by the policy has been updated, and the cached version plus thumbnails in ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P should be rebuilt.

    Something goes wrong with this, or has a chance of going wrong, the LockScreen_P folder is left empty, and a solid colour is displayed instead.

    This LockScreen_P folder is not accessible to an elevated account, only the local system account. However, we can run things as the local system account using a scheduled task.

    So, the workaround is to have a scheduled task (with a ONCE trigger set some point in the past so that it never runs unless triggered manually). This task clears out the LockScreen_P folder and populates it with the updated source jpg, as lockscreen.jpg. Experimentally it seems that this is the only one you need, and the system will populate the others as and when it needs them.

    This task can then be triggered manually whenever anything updates the source image for that machine. End result, it is now possible to replace the prelogin lock screen image on a regular and automated basis, and have it actually display properly and reliably on 14393.

    It shouldn't be necessary to have to resort to things like this to get basic functionality working, but at least we have a way forward. This was the last remaining show stopper for going ahead with 14393 in our environment, and moving to it this summer for our student machines.

    • Marked as answer by Mike Sandells Thursday, March 23, 2017 4:18 PM
    Thursday, March 23, 2017 4:13 PM
  • The lock screen GPO was working fine on an earlier 1511 build of Win 10, after 1607 upgrade this GPO and a few others apply only to an Enterprise or Educational version of Windows

    https://technet.microsoft.com/en-us/itpro/windows/manage/group-policies-for-enterprise-and-education-editions



    • Edited by net_tech Monday, April 17, 2017 1:14 AM
    Monday, April 17, 2017 1:12 AM
  • "Force a specific default lock screen and logon image" is not working for me in what "winver" calls Version 1703 of Windows 10."  

    According to the PolicyfileEditor Powershell module, these are the changes to the machine registry.pol:

    import-module .\PolicyFileEditor
    $MachineDir = "$env:windir\system32\GroupPolicy\Machine\registry.pol"
    Get-PolicyFileEntry -Path $MachineDir -All 


    ValueName Key Data Type --------- --- ---- ---- **del.LockScreenOverlaysDisabled Software\Policies\Microsoft\Windows\Personalization String LockScreenImage Software\Policies\Microsoft\Windows\Personalization c:\windows\web\screen\img102.jpg String

    So it looks like it wants the LockScreenOverlaysDisabled setting to be deleted. 

    By the way, I can't find DisableLogonBackgroundImage anywhere in the admx files:

    ls -r -force C:\windows\PolicyDefinitions | select-string DisableLogonBackgroundImage


    • Edited by JS2010 Wednesday, June 21, 2017 6:05 PM
    Wednesday, June 21, 2017 6:03 PM
  • I just ran windows update and everything worked.  Coincidence?

    Thursday, July 13, 2017 2:54 PM
  • I just ran windows update and everything worked.  Coincidence?

    Maybe - depending on other settings this can be an intermittent problem, and is very timing sensitive as to what happens on startup after the LockScreenImage is set. If you can do this on a fair number of machines without seeing the problem, and have machines reliably pick up changes to the image, then that would be significant.
    Thursday, July 13, 2017 3:15 PM
  • It might be better with the build version that ends in .540:  https://support.microsoft.com/en-us/help/4034674/windows-10-update-kb4034674


    • Edited by JS2010 Tuesday, September 12, 2017 4:31 PM
    Tuesday, September 12, 2017 4:30 PM
  • If you just blow away this folder at the end of the 1703 upgrade, will the system recreate it?

    If not, can we backup the contents prior to the upgrade and restore after?

    Tuesday, October 3, 2017 8:33 PM
  • sorry, I was supposed to reply to the next quote that mentions the lockscreen folder:

    c:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P

    Tuesday, October 3, 2017 8:34 PM
  • I was having a similar issue with Windows 10 Pro x64 (1709, build 16299.19). Similar because I do have a customised lock screen and I did have changed the default log in image, but the effects where slightly different: after upgrading to the current version (Creators Fall Update) the lock screen was showing the actual image chosen by me (and not a solid colour) but there was no clock or any info – like calendar, skype, weather – and no slideshow of images I originally set up for my lock screen. Basically I had the image I chose and nothing else.

    Your trick worked fine: from the lock screen I pressed a button (I don't have a CTRL-ALT-DEL combination set up in my system) then I waited for some seconds and magically the "Enter your password" box disappeared as it should and all the information suddenly reappeared – clock included – and a bunch of seconds later the slideshow of my images began. Perfect.

    Thank you sir.

    EDIT:

    I just found out that the workaround is not an actual solution for me: each time I lock the screen I HAVE to press a button and then wait until the info and the slideshow appears, it did not solve the issue for good. I also noticed that if from the lockscreen i choose "Change user" the clock appears (but not the slideshow because that is a user configuration).

    Any ideas?

    Thank you


    • Edited by vitriolvm Thursday, October 19, 2017 2:36 PM typo
    Thursday, October 19, 2017 2:14 PM
  • This just bit me in the rear.  We have 1511 (LTSB) org wide but I'm experimenting with a specific GPU that surprise surprise isn't supported on 1511.  Had to update me to 1607 only to be greeted with a plain blue lock screen.  After messing with it for days on end I finally came to the conclusion that if I leave "Prevent changing lock screen...." as Not configured then all my problems go away.  1511 remains on the "Forced lock screen" while I'm free to change my own.  I guess it doesn't matter if they try to change it as it wont work anyway.  Just kind of breaks that function because no amount of them messing with it will do anything.

    What a dumb bug.

    So why does that GP (Prevent changing lock screen) break 1607?  Do I need to update the GP adm files with 1607 adm files?  If so then nope, I'm not breaking the whole org with that move.

    Tuesday, July 10, 2018 11:40 PM
  • Hi there, late to this thread, I really need help with my windows 10 pro 1803 build lock screen. We run bginfo and it only works on the desktop background and not on the lock screen. Can you let me know how you configured lock screen image??? I have forced a default lock screen on the domain but it will not work as it says only for enterprise version. Any work around and help would be appreciated
    Friday, September 7, 2018 1:09 AM