Technical Case · KT-000018

Windows User Profile Was Rebuilt from the Correct SID Mapping

The profile could not be trusted just because a folder still existed under C:\Users.The affected SID and path were proven first, then only that profile registration was removed so Windows could create a clean local profile.

Documented by Michael Miller Published September 8, 2026

Case ID

KT-000018

Windows User Profile Recovery

Status

Profile Rebuilt / Normal Sign-In Verified

Technologies

Windows 10/11 / Win32_UserProfile / Registry / ProfileList

Problem

What happened?

A Windows user profile was no longer loading normally. The local profile registration had to be rebuilt without deleting the wrong account or profile.

The critical task was not simply finding a suspicious display name. It was proving the relationship between the affected local profile directory, the user SID, and the matching ProfileImagePath under Windows ProfileList.

Investigation

How was the correct profile isolated safely?

The profile display name is not the source of truth. SID, LocalPath, and ProfileImagePath are.

Investigation path: Separate admin → Win32_UserProfile → SID + LocalPath → ProfileImagePath → Data protection → Remove affected registration → Clean sign-in → Verify new mapping

Step 1

Use a separate administrative account

The affected user was signed out so the profile was not loaded while its mapping was inspected and repaired.

Step 2

Map the profile directory to the SID

Win32_UserProfile was used to match the affected C:\Users path to its SID and confirm the profile was not loaded.

Step 3

Verify ProfileImagePath before deletion

The matching SID key under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList was opened and ProfileImagePath was confirmed to point to the exact affected profile directory.

Step 4

Protect local data before destructive work

If the old profile contained local data that had to be retained, that data had to be copied before deleting the registration or profile directory.

Step 5

Remove only the affected registration

Only the verified SID registration was removed. Other user, administrator, and system profile registrations were left untouched.

Step 6

Let Windows create a clean profile and verify it

The user signed in again, Windows created a new profile, the desktop loaded normally, and the new profile mapping was verified.

Finding

What was actually proven?

The broken local profile registration could be removed and rebuilt without reinstalling Windows

The source supports a controlled recovery path: identify the affected profile with Win32_UserProfile, match its SID and LocalPath, verify ProfileImagePath, remove only that registration, sign in again, and confirm Windows creates a clean profile successfully.

The source does not prove that every temporary profile or Account Unknown entry has the same cause or that every profile issue requires ProfileList deletion. It also does not support deleting a SID based only on its display name or deleting local profile data before deciding what must be preserved.

This case is proof of one controlled Windows profile recovery, not a generic registry tutorial.

Verification

Confirm the new C:\Users profile directory exists, the desktop loads normally, Windows is no longer using a temporary or orphaned profile, and the new profile maps correctly to the current SID.

Lessons Learned

Prove the profile mapping before touching ProfileList.

When a Windows profile appears broken, prove the SID-to-path mapping before deleting anything.

A profile repair becomes risky when an unresolved SID or display name is treated as enough evidence. Match the exact LocalPath, SID, and ProfileImagePath first, then change only the affected registration.

Related Resources

Use the smallest safe recovery path.

Workstation decision