Saturday, August 27, 2011

Using CHNTPW to fix weird bug in Windows 7

I just spent a good many hours trying to fix a Windows 7 machine with a ‘broken’ login.  The user hadn’t changed their password (nor had it expired) but suddenly the computer insisted their password was wrong.  My first thought was just to reset (hack) the password.

I had previously used the ‘chntpw’ tool to manually tweak the built-in SAM password database on Windows XP – but did it work on Windows 7, too? I carry a flash-drive on my key-chain which boots Ubuntu 10.10 so I started there.  ‘Chntpw’ is in the 10.10 repository (the ‘Universe’ alternate) and I successfully installed it, then ran it against the Win7 machine’s hard-drive and SAM file. It said it had 'successfully' blanked the user’s password but Windows still reported ‘invalid password’. I also tried resetting to a new password; same result.

I then tried one of the official Windows 7 repair techniques. I booted the install disc, then selected Repair > Recovery Console. Once I had the command-line open I tried the following command which was supposed to activate the built-in Administrator account,
> net user administrator /active:yes

Unfortunately, even though this was using a ‘legit’ Microsoft process it still didn’t work; there was no Administrator login option.

At this point, I thought maybe there was a newer version of ‘chntpw’ so I booted a newer Ubuntu 11.04 LiveCD. But there was no version of ‘chntpw’ in its Universe repository. Instead I had to download the .deb from Launchpad (just google “ubuntu 11.04 chntpw”). Unfortunately, attempts to both blank and also reset the user password still failed.

Finally, I tried unlocking the Administrator account with chntpw and it finally worked! I still couldn’t login as the regular user-account but I was able to click on Switch User > Other User > manually enter ‘administrator’ (sans password) and it logged me in.
____________

Now, here's the weird bug part:

From the administator login I was able to successfully reset the user's password and login as them.  I immediately saw a weird error message, something about "user profile directory c:\windows\system32\config\Desktop not found."  The user's Desktop folder is not supposed to be under C:\Windows?!  Also, the system loaded a generic desktop.  I switched back to the Administrator login and searched the C:\Users folder.  The user's original Desktop folder was right where it was supposed to be, and I noticed something unusual:  There was a copy of the files off a Norton Antivirus install CD filling the Desktop.  I also saw the AUTORUN.INF and, on a suspicion, I deleted it.  Voila!  The user's account now worked properly.

So, apparently there is an unpatched Microsoft bug wherein Windows will try to 'obey' an AUTORUN file in the user-profile directory.