Ok so I'm trying to achieve a scenario where my managed systems automatically login after any reboot and then lock the PC to secure them. I've achieved this in Windows 7 by using control userpasswords2 to set auto-login with the password and then created a scheduled task to trigger on user login to run a program rundll32.exe with arguments user32.dll,LockWorkStation.

This works completely fine in Windows 7 but not in Windows 10. WIth Windows 10, it appears to lock and shows "locking" however it doesnt prompt for the password when coming back in.

However if i manually lock the system with windowskey+L or run the command from commandline/runbox it locks properly and then requires password to get in.

I can't figure out why this is happening. On one test system, i kept the task but disabled auto login and when logging in manually with password, the system would NOT lock. Scheduled task history says it completed successfully.

  • So did some more testing and it just makes even less sense than before. SO instead of runniing rundll32, im running a batch file on the desktop that has the command in it. I added "pause" to the top so I could see if it was actually running and when I did this, i logged in, had to press any key to continue and then the system locked as expected. THen I removed the pause and in one instance it worked properly and in another, i was able to click the screen and get back in without a password. However without auto login, i noticed the screen flash, almost as if it locked while at the login screen – Richard Chase Jun 6 '19 at 20:24
  • Part of the issue with windows 10 is that it doesnt display "locked" like Windows 7 does so it's harder to verify if its working or not. – Richard Chase Jun 6 '19 at 20:25
  • I can confirm that the batch file or task scheduler actually executes before logging in so this appears to be a bug. I noticed when I add "pause" to the top when i reboot the PC and then login, the batch window is already open and displaying. Going to go more in depth and put in some sort of timer and counter to double check but it appears as though its executing before login not after. – Richard Chase Jun 6 '19 at 20:34
  • Double confirmed. Added a timeout /t 60 to the script and rebooted system. Waited about 20 seconds and then logged in and the timer was at 40 seconds left. So task scheduler seems to interpret "at login" as "at login screen" not when the user actually logs in. – Richard Chase Jun 6 '19 at 20:50
  • 1
    I'm seeing similar inconsistencies with the rundll32 method under Win10 1909. I don't have a solution, but I think it's worth pointing out (1) you can set whether the task requires the user to be logged in under the General tab of the task properties, and (2) you can edit the task's Trigger, to delay the task by e.g. 30 secs/1 min. Not sure if the latter makes any difference to the outcome...still testing. – Jimadine May 24 at 12:07

This is a tricky one to solve. Here are my thoughts, observations and a possible working solution, depending on the level of security you require:

There seem to be similar reports to yours, in the comments at the bottom of this winhelponline.com page. As you report, it seems the scheduled task either runs too early — so fails because locking a workstation before the desktop is loaded isn't possible — or runs too late; the user is then able to unlock the desktop without being prompted to enter their password, and potentially kill the lock workstation task/script before it runs.

Currently on my Win 10 1909 system, I'm testing with a scheduled task to run rundll32.exe user32.dll,LockWorkStation only when the user is logged in (according to the task parameters). After restarting my computer, the lock screen is shown and is unlockable without a password. However, after "unlocking", the desktop is briefly shown, and the scheduled task runs almost immediately to lock the computer, so the likelihood someone has the time to fire up task manager and kill off task scheduler or the task is small. Please feel free to try my scheduled task, which I have made available for you as XML. The behaviour isn't ideal, but it's better than nothing. I'd be interested to know whether this gives you more consistent behaviour than before.

The automatic logon itself was set up with the Sysinternals tool autologon.exe. I am doubtful autologon.exe makes any difference with the unlockable-when-should-be-locked issue compared with other methods of setting up autologon (registry, control userpasswords2) but it might be worth trying anyway. And maybe (or maybe not) it has a security advantage versus manually editing the registry in that it uses LSA Secrets (interestingly, Nirsoft's Regscanner reveals my password is stored in HKU\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\OOBE\Broker\LocalSystemAuthBuffer and HKU\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\OOBE\Broker\LocalSystemAuthBuffer data anyway, but I digress).

Alternatively, there are third-party solutions that may work for you:

  • For a long time, under Windows 7, I used Auto Login & Lock v1.0 by Kurian Abraham. I can vouch for this software as working well under Windows 7, but I haven't tried it under Windows 10. It might be worth trying in a Windows 10 VM if you have one available or can spin one up. ( MD5 of Lock.exe: ED4685849BA97E7A45CEBD3684B99709. MD5 of LockCMD.exe: C24DBDEBDE61C60F3DCF37BBDAD73A7B. )
  • Logon Expert is paid-for, but free for 10 days. It claims to be able to auto logon and lock, and the trial period would obviously give enough time to see if it works as advertised. Also, it claims to be more secure, using AES 256 encryption to store the password.


Just when I thought I had nailed the issue using the scheduled task as linked above, I booted my computer this morning and the unlockable-when-should-be-locked issue is back. I will experiment further, starting with adding a delay to the At log on trigger. Note that you do not need to stick to the presets in the Delay task for: dropdown list; choose e.g. 30 seconds and then manually edit it to e.g. 10 seconds.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.