Reset Windows 10/11 Password Using GRML

To reset Windows password using GRML, boot an authorized Windows 10 or Windows 11 VPS into a GRML live ISO and edit the local account database offline. You can usually regain console access in 10–15 minutes without reinstalling the server, then set a new password before reconnecting over RDP.

Prerequisites

• A Windows 10 or Windows 11 VPS with a local account whose password you are authorized to recover. This procedure does not recover a Microsoft account, domain account, PIN, or BitLocker-protected volume.
• Access to the VPSLake Windows RDP service, its client area, and the VPS control panel (Virtualizor) with permission to mount an ISO and open VNC.
• The GRML 64-bit ISO downloaded from the official GRML documentation or download page, plus its checksum verified before uploading it.
• At least 1 GB of free disk space for temporary hive backups and enough RAM for the live environment. Your Windows installation must be shut down, not hibernated or left in Fast Startup mode.
• A new, unique password ready to enter at the Windows console after the reset. Do not use a password copied into a shell command or support ticket.

This is an offline recovery operation. Only use it on a server you own or administer; changing another person’s account database without permission is unauthorized access.

Step 1: Attach GRML and open the VPS console

The live ISO must start before Windows so the Windows system files are not in use.

In the VPSLake client area, open Services → your Windows VPS → Open VPS control panel (Virtualizor) → ISO/Media → Attach or Mount ISO. Choose the GRML 64-bit ISO, save the media change, and set the next boot to the virtual CD/DVD device if Virtualizor presents a boot-order option.

Open Virtualizor → VNC and select Restart or Reboot. At the GRML boot menu, accept the default 64-bit entry and wait for a root shell. If the console opens a graphical desktop instead, open a terminal; the commands below must run as root.

Do not use the Windows Restart option before this step if you can still reach the desktop. Use Start → Power → Shut down, because a full shutdown avoids a locked NTFS volume.

Step 2: Identify the Windows partition

The device name is different on each VPS, so identify the NTFS volume instead of assuming it is /dev/vda2.

Run:

lsblk -f
fdisk -l

Look for the large ntfs partition that belongs to the Windows installation. Do not choose a small EFI, recovery, or reserved partition. A typical result may resemble this, but your device and sizes will differ:

NAME  FSTYPE LABEL  SIZE
vda                 80G
├─vda1 vfat          100M
├─vda2 ntfs         79.5G
└─vda3 ntfs         600M

Record the Windows partition as WINDOWS_PARTITION, such as vda2. If the disk uses a different name, use the complete device shown by lsblk, including a partition suffix such as nvme0n1p3.

Step 3: Mount the Windows system volume read-write

Mounting the system volume exposes the offline SAM database that stores local Windows account credentials.

Create a mount point and mount the partition, replacing WINDOWS_PARTITION with the value you identified:

mkdir -p /mnt/windows
mount -t ntfs-3g -o rw /dev/WINDOWS_PARTITION /mnt/windows
ls /mnt/windows/Windows/System32/config

Successful output includes the registry hives needed for this recovery:

DEFAULT  SAM  SECURITY  SOFTWARE  SYSTEM

If ntfs-3g is unavailable, check whether GRML has the driver installed before trying another mount method:

command -v ntfs-3g

If that command returns a path, retry the mount. If it returns nothing and the GRML session has network access, install the driver and retry:

apt-get update
apt-get install -y ntfs-3g

If the volume is reported as hibernated or unclean, stop and boot Windows normally once, then use Start → Power → Shut down. Forcing a write mount can damage the installation.

Step 4: Back up the registry hives

A local copy gives you a recovery point if you select the wrong account or the edit does not produce the expected sign-in.

From the configuration directory, copy the hives to the GRML environment:

cd /mnt/windows/Windows/System32/config
mkdir -p /root/windows-hives-backup
cp -a SAM SYSTEM SECURITY /root/windows-hives-backup/
ls -l /root/windows-hives-backup

The listing should show three files. The backup is stored in the live session’s memory-backed filesystem, so it disappears when GRML reboots; keep the Windows disk and VPS snapshot intact until you have verified access.

Step 5: Clear the forgotten local password

chntpw changes the offline local account record; it does not reveal the old password. Clearing it temporarily lets you sign in through the VPS console and immediately replace it with a strong one.

Check whether GRML already includes the utility:

command -v chntpw

If the command is not found and the GRML session has network access, install it before continuing:

apt-get update
apt-get install -y chntpw

List the local accounts and their relative identifiers (RIDs):

chntpw -l SAM

The output identifies account names and RIDs, for example:

RID: 01f4, Username: Administrator
RID: 03e8, Username: YOUR_USERNAME

Start the interactive editor:

chntpw -i SAM

At the prompts, choose the option to edit user data, select the intended account by its displayed RID, and choose Clear (blank) user password. Return to the user menu with q, return to the main menu with q, and answer y when chntpw asks whether to write the changes. The chntpw guide documents the same SAM menu flow.

Do not select an account only because its profile folder has a familiar name. Match the account name and RID from chntpw -l SAM, and leave domain or Microsoft-account entries alone.

Step 6: Unmount the disk and boot Windows

Windows must see the saved hive cleanly, and the live ISO must be detached before the normal disk boots.

Leave the configuration directory, flush pending writes, and unmount the mount point:

cd /
sync
umount /mnt/windows

In Virtualizor → ISO/Media, choose Unmount/Detach ISO, then open Virtualizor → Power Control → Reboot. Keep the VNC console open so you can observe the Windows boot and use the local console if RDP rejects a blank password.

Verify the recovered account

At the Windows sign-in screen in VNC, select the recovered local account and leave the password field empty. After Windows opens the desktop, immediately press Ctrl+Alt+Delete, choose Change a password, leave the old-password field blank, and enter a long, unique value twice. If the secure screen is unavailable, open Start → Settings → Accounts → Sign-in options → Password → Change.

The blank password is deliberately temporary. Windows commonly blocks blank local passwords over RDP, so do not treat a failed blank-password RDP attempt as proof that the reset failed. After setting the new password, disconnect the VNC session and start a fresh RDP connection using the local account format SERVER_NAME\YOUR_USERNAME.

A successful new RDP sign-in is the final check. If you can open an elevated PowerShell window after signing in, confirm the identity without exposing the password:

whoami

Expected output resembles:

SERVER_NAME\YOUR_USERNAME

Troubleshooting

mount: wrong fs type or the volume is read-only

You may have selected the EFI/recovery partition, the NTFS driver is missing, or Windows left the volume hibernated. Recheck lsblk -f, choose the large NTFS partition, and use mount -t ntfs-3g -o rw; if hibernation is reported, boot Windows normally and perform a full shutdown before trying again. Do not run filesystem repair commands merely to bypass a hibernation warning.

ls /mnt/windows/Windows/System32/config says the path does not exist

The wrong partition is mounted, or the Windows directory uses a different drive layout. Unmount it with umount /mnt/windows, inspect every NTFS partition with lsblk -f, and mount the one containing Windows, Users, and Program Files.

chntpw: command not found

The live image does not include the package in its current session. Connect the GRML environment to the network, run apt-get update, and install chntpw with apt-get install -y chntpw. If the live session cannot reach the network, use a GRML image that includes the package or an approved Windows recovery method instead of downloading an unknown binary.

Windows accepts the console sign-in but RDP still fails

Blank local passwords are often denied for network logons, and an RDP client may also have cached an old credential. Set the new password at the VNC console first, remove the saved server entry from Control Panel → Credential Manager → Windows Credentials on the connecting computer, and reconnect as SERVER_NAME\YOUR_USERNAME.

Hardening after recovery

• Store the new password in a password manager and remove temporary notes or copies from the console session.
• Detach the GRML ISO so the VPS cannot boot into the recovery environment on its next restart.
• Keep a current VPS snapshot or backup and record the approved console-recovery procedure before the next lockout.
• If the server uses BitLocker, enable and safely store the recovery key; GRML cannot edit a locked encrypted Windows volume.

FAQ

Can GRML reset a Windows PIN?

No. A PIN is a Windows Hello credential, not the local SAM password that chntpw edits. Sign in with an available password or use Microsoft’s approved account-recovery and Windows Hello recovery options instead.

Does this work for a Microsoft account or domain account?

This procedure is for local Windows accounts stored in the offline SAM hive. Microsoft accounts and domain accounts are managed by their online identity provider or domain controller, so reset them through the appropriate administrator or account-recovery process.

Why can I sign in at VNC but not over RDP?

The reset initially creates a blank password, and Windows normally blocks blank passwords for remote network logons. Set a real password at the VNC console, then reconnect with the correct local username prefix and remove cached credentials if necessary.

Will clearing the password delete the user’s files?

No. The operation changes the local account credential record, not the profile files. Still, back up the SAM, SYSTEM, and SECURITY hives and keep a VPS backup because any offline registry edit carries recovery risk.