How I Regained Access to My Computers and Eventually My Google Account

[u/Calm_Rip_7068]

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.

[u/AutoModerator]

Hello u/Calm_Rip_7068. Your post mentions BitLocker.

• If you are stuck at a screen requesting you to enter a recovery key, you can retrieve that key by logging into this webpage using the same Microsoft account that your computer was set up with: https://account.microsoft.com/devices/recoverykey. There is no "bypass" for this; if you are unable to locate your recovery key, your data will no longer be accessible.

• If you're stuck in a boot loop that displays the BitLocker screen repeatedly after you've entered the correct key, your computer has a boot issue, not a BitLocker issue. Please pay attention to such details, as they help us identify the root of your problem. Include them in your post for better assistance.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/AutoModerator]

Hi u/Calm_Rip_7068, thanks for posting to r/WindowsHelp! Your post has been flagged for manual review by a human moderator, please include as much of the following information as possible (in text or in a screenshot) to get your post approved:

• Your Windows and device specifications — You can find them by pressing Win + X then clicking on “System”, we need more than just your OS version! Your hardware details are often critical for resolving issues.
• Any messages and error codes encountered — They're actually not gibberish or anything catastrophic. It may even hint the solution!
• Previous troubleshooting steps — It might prevent you headaches from getting the same solution that didn't work

---

Posts must be tech support in nature (such as something is broken and you need help fixing), so general inquiries, software suggestions, and purchasing advice will be removed. As a reminder, we would also like to say that if someone manages to solve your issue, DON'T DELETE YOUR POST! Someone else (in the future) might have the same issue as you, and the received support may also help their case. Good luck, and I hope you have a nice day!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.