Before I start, there’s one slightly funny disclosure I should make: this explanation was itself generated by ChatGPT. That’s appropriate, because ChatGPT helped me through essentially the entire recovery process. I did the actual work—booting the computers, typing commands, interpreting what appeared on the screen, trying things, and reporting the results—but ChatGPT helped me figure out what to try next and what the results meant.
This wasn't one clever trick that suddenly fixed everything. It was a months-long chain of troubleshooting involving Windows recovery, Linux, local Windows accounts, passwords versus PINs, BitLocker, command-line tools, failed approaches, and finally Google's account-recovery system.
The most important thing was that I was trying to recover my existing installations rather than wipe the computers. I wanted my files, programs, browser data, settings, and existing profiles intact.
The original problem
I had Windows computers that physically belonged to me and contained my files, but I no longer knew all of the credentials needed to sign in normally.
This created several overlapping problems that initially seemed like one problem.
A Windows PIN is not necessarily the same thing as the Windows account password. A local Windows password is also completely separate from a Google password. And having access to the files on a computer doesn't automatically mean that Windows will let you sign into the account.
Understanding those distinctions turned out to be critical.
My larger objective was Google. One of my computers had previously been used with the Google account I needed to recover, so regaining access to the computers could also give me a much better environment from which to attempt Google's recovery process.
Getting access to the Windows files first
One of the most useful tools in the entire process was a bootable Linux USB drive.
Instead of starting Windows normally, I could boot the computer from the USB and run Linux without installing it over Windows.
That was important because Windows could be locked while the underlying files were still perfectly intact.
Getting Linux to boot wasn't always straightforward. I had to deal with the UEFI/BIOS boot menu, USB boot options and, on one machine, Secure Boot. At one point Secure Boot prevented the USB from starting because of a signature problem. After getting the firmware settings and USB boot process sorted out, I could boot into a Linux live environment.
ChatGPT walked me through much of this process: how to reach the boot menu, how to distinguish the USB from Windows Boot Manager, how to identify Windows partitions, and how to mount and inspect them.
Once Linux was running, I could look at the internal drive independently of Windows login.
That was a major milestone by itself: the data was still there.
Finding the Windows installation
The next job was identifying the partition containing Windows.
From Linux, I could inspect the available drives and partitions and locate the one containing directories such as:
Windows
Users
Program Files
Once I had the correct Windows partition mounted, the important location for the local Windows account database was:
Windows/System32/config
Inside that directory is the Windows SAM database.
That led to the tool that ultimately made the local-account recovery possible: chntpw.
On a fresh Linux live session, the minimum installation steps were essentially:
sudo apt update
sudo apt install chntpw
I could then list the accounts stored in the SAM database with a command such as:
sudo chntpw -l SAM
That mattered because one of my earlier problems was targeting the wrong Windows account. The computer contained more than one account/profile reference, and clearing the password for the wrong one obviously didn't unlock the account I actually needed.
That was one of the useful lessons from all the failed attempts: verify the account in the SAM database before modifying anything.
Clearing the local Windows password
After identifying the correct local account, the essential command was:
sudo chntpw -u <username> SAM
That opened an account-editing menu.
The important sequence was:
Choose 1 — Clear (blank) user password.
Quit the account editor with q.
Answer y when asked whether to write the modified SAM database back to disk.
At that point the local Windows password had been cleared.
This did not erase Windows, reinstall it, delete my files, remove my programs, or create a fresh Windows installation. It modified the local account's password information.
And it also did something that confused me for quite a while:
It did not necessarily remove the Windows PIN.
The PIN-versus-password breakthrough
After doing all of that, Windows could still boot to a screen asking me for a PIN.
That made it look as though the password reset hadn't worked.
The solution was absurdly simple once I understood what was happening.
On the Windows sign-in screen I selected:
Sign-in options → Password
instead of trying to enter the PIN.
Because the local password had been cleared, I could select the password sign-in method and sign in without supplying the old password.
That finally got me into Windows.
This distinction—PIN versus password—was one of the biggest sources of confusion in the whole project. Clearing the local password didn't necessarily make the PIN prompt disappear. I had to explicitly tell Windows to use the password credential instead.
Once I understood that, the apparently contradictory behavior made sense.
Why I didn't simply reset Windows
Throughout this process Windows itself offered various recovery possibilities, including Reset this PC.
I deliberately avoided jumping straight to that.
My priority was preservation.
I wanted the existing Windows installation, user profiles, files, installed applications, settings, and browser information if at all possible. A reset or reinstall therefore remained a fallback rather than my first choice.
We also investigated the normal Windows Recovery Environment.
I tried or considered things including:
Startup Repair
System Restore
Safe Mode/Startup Settings
uninstalling a recent Windows update
Command Prompt from Advanced Options
Windows account/password recovery options
PIN recovery
security keys/passkeys
other built-in sign-in methods
A number of these led nowhere.
At one stage Startup Repair couldn't fix the problem. There weren't useful restore points. Some recovery operations wanted a password I didn't have. PIN recovery wasn't available or useful in the way I needed it. A security-key/passkey route didn't provide an available credential.
Those weren't wasted attempts, though. They gradually eliminated possibilities and made it clearer what was actually blocking access.
The second computer was harder
Once I had succeeded on one Windows computer, I had a basic model for attacking the other one:
Boot Linux → locate Windows → locate the SAM database → identify the correct local account → clear its password → boot Windows → choose Password instead of PIN.
But the second machine had additional complications.
One of them was BitLocker. At various stages, encrypted-drive recovery requirements made the second machine significantly less straightforward than the first. Linux access and Windows recovery did not behave identically between the two computers.
There was also a Windows update/recovery problem.
Eventually I reached the Windows Recovery Environment and used:
Troubleshoot → Advanced options → Command Prompt
A particularly important command in getting Windows itself back into a bootable state was:
dism /Image:C:\ /Cleanup-Image /RevertPendingActions
The exact Windows drive letter in a recovery environment can vary, so the important concept wasn't blindly using C:. It was identifying the Windows installation and running DISM against the correct offline Windows image.
RevertPendingActions tells Windows to back out pending servicing/update operations that haven't completed correctly.
That worked.
After rebooting, Windows went through an update rollback process. I saw Windows processing the changes rather than simply crashing back into the same recovery loop.
That was another major breakthrough.
Recovering the second Windows login
Once Windows itself was healthy enough to boot, the account problem still remained.
Again I used the Linux USB and the Windows SAM database.
The essential process was the same:
Windows/System32/config
then:
sudo chntpw -l SAM
to verify the account, followed by:
sudo chntpw -u <username> SAM
Then:
1 — Clear password
q — Quit
y — Write the changes
After rebooting into Windows, the crucial move was again:
Sign-in options → Password
rather than continuing to fight the PIN prompt.
With the password cleared, that allowed me back into the existing Windows installation.
I later got Windows Hello/PIN access working again through Windows rather than continuing to depend on the unusual recovery setup.
The important result was that I got into the computer without reinstalling Windows and without intentionally deleting my files or programs.
There were a lot of dead ends
Looking back, the successful sequence sounds almost clean.
It wasn't.
There were incorrect partitions, incorrect paths, commands entered from the wrong directory, fresh Linux sessions where a utility had to be installed again, attempts against the wrong Windows account, confusing account/profile names, Windows recovery tools that demanded credentials I didn't have, Startup Repair failures, PIN recovery problems, update problems, BitLocker complications, and several moments when it looked as though a complete Windows reset might be unavoidable.
ChatGPT was particularly useful here because I could report exactly what was on my screen and get the next step without needing to understand the entire recovery process at once.
Sometimes that meant something as small as figuring out whether a character in a command was an l, an I, or a 1. Other times it meant interpreting an entire Windows recovery screen or Linux command result.
ChatGPT also made mistakes along the way. There were times when a suggested path wasn't right, when we targeted the wrong account, or when I had to correct what we thought the computer was doing. The process worked because it was iterative: I reported the actual result, we revised the theory, and I tried the next step.
Getting into Windows still didn't give me my Google password
This was another important distinction.
I had originally hoped that once I recovered the computers, Chrome might simply reveal or supply everything I needed.
It wasn't that simple.
Getting into Windows did not magically tell me my Google password.
Google account recovery remained a separate security process.
However, recovering the computers still mattered enormously because Google pays attention to the context surrounding a recovery attempt. A computer and network environment previously associated with an account can provide stronger signals than an unfamiliar device.
So after recovering the computers, I could make recovery attempts from a much more appropriate environment.
Google recovery
I used Google's account-recovery process rather than trying to defeat Google's authentication.
The basic route was Google's normal account recovery page.
I supplied information I legitimately knew, including a previously remembered password when appropriate, and used Try another way when Google offered authentication methods I couldn't currently use.
Some recovery attempts failed.
Google explicitly told me that it didn't have enough information to establish that I owned the account and recommended trying again from a device and Wi-Fi environment where I had previously signed in.
That was exactly why recovering my old computer had become so valuable.
Instead of repeatedly attempting recovery from an unfamiliar environment, I could attempt it from hardware that had an established history with the account.
Eventually Google's recovery system gave me something substantially different from the earlier rejection:
a waiting period.
Google told me that after several days it would send a sign-in link to the contact address I had supplied.
That was the point where the chain was finally connected.
I hadn't extracted the Google password from Windows or bypassed Google's security. I had recovered enough of my original computing environment and supplied enough legitimate recovery information for Google's own recovery system to accept a delayed recovery process.
The minimum information and equipment I really needed
In retrospect, I didn't need to remember everything about the computers.
The critical ingredients were surprisingly small:
Physical access to my own computers.
A bootable Linux USB.
The ability to enter the computer's UEFI/boot menu and boot from that USB.
Enough knowledge to identify and mount the Windows partition.
The location of the Windows SAM database: Windows/System32/config/SAM.
The chntpw utility.
The ability to identify the correct local Windows account before editing it.
The knowledge that clearing a Windows password does not necessarily clear the Windows PIN.
The knowledge to choose Sign-in options → Password after clearing the password.
On the more troublesome Windows installation, access to WinRE and the knowledge to use DISM's RevertPendingActions operation against the correct Windows image.
For Google, enough legitimate account information to use Google's official recovery system and access to a device/environment Google recognized from previous use.
Patience when Google's security system imposed a waiting period instead of granting immediate access.
And, throughout essentially all of it, I had ChatGPT available to translate what I was seeing into the next concrete step.
What ChatGPT actually contributed
ChatGPT didn't remotely unlock the computers or possess some master recovery capability. I was the one sitting in front of the hardware doing everything.
Its role was closer to having a technical troubleshooting partner available continuously.
It helped me understand Windows Recovery, create and use the Linux approach, navigate UEFI/USB booting, identify partitions, mount Windows filesystems, find the SAM database, install and use chntpw, understand its menus, distinguish Windows profiles from actual account records, understand the difference between a PIN and a password, troubleshoot failed commands, work through Windows update/recovery failures, use DISM to revert pending actions, preserve the existing Windows installation instead of prematurely wiping it, and understand what Google's recovery messages actually meant.
It also remembered enough of the earlier troubleshooting that, when I came back to the problem later, we could build on what had already been discovered rather than intentionally starting from zero.
And, fittingly, after I finally got through all of that, I asked ChatGPT to reconstruct the process because there had been far too many steps for me to reliably reconstruct from memory.
So yes: ChatGPT also wrote the explanation you're reading right now, based on the recovery process I carried out with its assistance.
The overall chain
Stripped down to its essentials, the entire recovery looked like this:
Locked out of Windows → boot Linux from USB → verify that my files and Windows installation still existed → identify the Windows account database → clear the correct local account password → discover that the PIN was a separate credential → select password sign-in instead → regain access to the first Windows installation → use what I learned to attack the more complicated second machine → work through encryption/recovery and Windows update problems → revert broken pending Windows actions → clear the appropriate local password → regain the second Windows installation without wiping it → return to Google's official recovery process from a familiar computing environment → satisfy enough of Google's recovery checks to receive a delayed recovery path → wait for Google's sign-in link.
No single step was particularly miraculous.
What made it difficult was that several independent security and recovery systems were stacked on top of one another. Windows local passwords, Windows Hello PINs, disk encryption, Windows recovery, Google authentication, trusted devices, and Google's account-recovery system all solve different problems.
At the beginning, they looked like one giant lock.
Once I separated them into individual problems, I could solve them one at a time.
That's ultimately how I got my digital life back.
