Skip to main content

Enable Automatic Login in Windows 10, Version 2004 and Later

Monday, May 2, 2022
Reading time 3 minutes

In Windows 10 versions 2004 (May 2020 update) or later, the method to enable automatic login has changed a bit, as now you must edit registry information mandatorily before being able to see the checkbox that allowed enabling automatic login (that is, for a specific user account to be the one that logs in to the computer, without requesting a password). Now, before being able to enable automatic login, you have to do the following.

Show the automatic login checkbox

  1. From the “run” menu, which is accessed by pressing the Windows+R combination, type “regedit” (without quotes) and press enter.
  2. Once done, the Windows registry editor will open. To find the information we need to change, you have to search for the following path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PasswordLess\Device To be able to do it more quickly, you can simply press the TAB key until you reach the field where you can type text, and there paste the path I’ve placed in the line above, then press enter.
  3. Again using the Tab key, locate the right panel of the window, where there will be a list of options. In that list the options for the registry key we’re interested in are shown. In this example, in addition to the “(default)” option shown as the first option, we’ll see another one called “DevicePasswordLessBuildVersion”. Once we’re in the list we can find it using the down arrow. We’re going to edit the value of “DevicePasswordLessBuildVersion” by pressing enter once the system focus is located on this option.
  4. When editing the option, a window with information about the registry value will appear. By default, the system focus will fall to an edit field where the option we previously selected is edited. If this option had never been edited, the value in the edit field will be 2. We have to change that to a 0 and press enter.
  5. Once this is done, you can now close the registry editor window.

At this point, some users advise restarting the computer, in order to allow the operating system to make the changes that have been saved in the registry. After restarting the system, you can continue with step 2 to finally enable automatic login.

Activating automatic login

  1. Again, press the Windows+R combination to open the run menu. Type “netplwiz” and press enter. This will open the system user accounts dialog.
  2. Once this dialog is open, using the Tab key, locate a checkbox called “Users must enter a user name and password to use this computer”. If the user currently requests a password, this checkbox will be checked. Press space to uncheck it, and then press OK.
  3. If everything went well, now a new dialog will appear, where you must enter, and then confirm, the password of the account that will be used to log in automatically. Once the password is written a couple of times, simply press Tab until you find the OK button, and then press Space or Enter. And it will be ready. From here on, the computer will log in with the user you’ve specified.

Source

Tutorials

Notes Technology Windows

Related posts

  • Creating a Windows 11 Virtual Machine on Libvirt –
    On this occasion, I feel compelled to document this to ensure it’s not forgotten. The reality is that creating a Windows 11 based virtual machine (VM) may not seem significantly more challenging than what’s been experienced with Windows 10. However, it does present its intricacies, especially as of late 2023. In this article, which I wish could be more concise, I will share the step-by-step instructions that have proven effective for me in successfully running the Windows 11 installation using the Narrator screen reader, facilitated through Spice. I won’t delve into Libvirt extensively this time, as I’ve already provided some relevant information in earlier articles about this tool and its use. Instead, I’ll focus on adding TPM devices, configuring secure boot, and initiating the boot process for Windows 11. My starting configuration involves a system with Debian 12 installed, Libvirt, and a bridged network, as detailed in the respective post.
  • Creating Virtual Machines with Libvirt: Linux and Windows –
    A couple of weeks ago, as part of an update to my DAS setup + the Mini PC with Intel Celeron J4125 I’ve previously talked about, I had the opportunity to get an AMD Ryzen 5 5600G, along with everything needed to build a system where I could integrate hard drives at a very reasonable price. One of the first things I envisioned for this processor, which has proven to handle everything thrown at it, was to delve into virtualization. I had a couple of projects in mind that required a Windows virtual machine, as I didn’t want to install Windows 10 or similar on the server but needed software running 24/7 that specifically works mostly under Windows environments.
  • Setting Up GitLab Runner on Windows –
    Increasingly, I resort to GitLab Runners to build my projects. Being able to automate practically the entire configuration (from generating a tag in Git), it’s perfectly possible to publish new software versions, generate documentation, run tests automatically and upload the results of all that to some site, for example Backblaze B2. The result is a “pipeline” that’s a pleasure to use, because it simply works. At the same time, the creation process of each project is documented in the .gitlab-ci.yml file, which is useful to see exactly the steps to follow to get to generate some version of the applications I write.
  • GitLab Runners on Windows for Continuous Integration and Delivery –
    For just over a couple of years, I’ve been using GitLab Runners to deploy and perform tests on some projects I develop. It all started as a test with simple projects, like Music DL and socializer. The idea of runners is to use them to complete the CI/CD Cycle (that is, continuous integration and delivery). In general terms, this makes it possible that whenever a specific condition is met within the source code repository (for example, creating a tag for each new version, sending a commit to a repository), a Runner takes charge of executing a series of commands or scripts to run the project’s test units, or can even compile, package and distribute versions ready for users directly. This is what we’ve been using in TWBlue for Snapshot updates for a couple of years, which in the end was an important factor when deciding to shorten the development cycle of the application versions. Personally, I also like that a runner executes all the tasks, as that helps us keep our personal or work computers out of TWBlue distribution. Since these are Python projects, sometimes the modules that help us generate distributable versions (such as cx_freeze) incorrectly include packages that aren’t used in the application. This can’t always be controlled appropriately and sometimes, a TWBlue version generated in the past included more or fewer extra and unnecessary modules depending on whose computer the distributable versions had been built on. With a runner creating each version of our software, we ensure we have a machine that only has the necessary tools installed for what will be built, and we also provide everyone who wants to review it, a list of reproducible steps that need to be executed to create an identical copy of our versions. Finally, the fact that all this happens completely automatically makes us have to worry less about preparing everything and executing each step manually on our machines: A developer only has to send a commit or create the appropriate tag, and the runner will test, build and upload the executables to our ftp site in a matter of minutes.