Author Topic: Half way there... (SOLVED) (Read 43749 times)

cheongal · « **on:** July 10, 2014, 10:55:56 am »

Hi,

To whoever created and supporting the tool, I say thank you. After several days of tinkering and finally finding and using your tool, my nightmare is almost over. Almost !

My pc is running Windows 7 Home Premium. Issues were (1) Logging into Admin account , got black screen with cursor. Ctlr, Alt + Del and Run userinit.exe from task manager allows me into a normal session (2) Logging into standard account gets logoff right away. If convert to Admin account type, system allows that account in but with black screen and cursor. running userinit.exe will create a normal session. (3) ran chkdsk /f /r . got a bunch of 'Replacing invalid security id with default security id '. Also, I do have malwarebytes and there were a few malware which I quarantined.

Finally, yesterday, ran Windows Repair using my admin account. At the end of the repair, after a couple of restart... using my main admin account (the same I used to run Windows repair) , I was able to get a normal windows session (without having to run userinit.exe manually from task manager) . Yippee !

I said earlier, I am almost there... because I still have issue if I use a standard account, I would get logoff right away. If I use another different admin account, I would get the black screen with cursor (and running userinit.exe would create a normal session).
I have created a new user (after the repair) to perform some tests. New standard user has the same bad behaviour.

Note that I have checked the famous winlogon registries HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, (1) userinit (C:\WINDOWS\system32\userinit.exe, ) (2) shell (explorer.exe). They both have the standard default values.

Question : I used my main admin account to run Windows Repair (all default choices checked). Is that enough ? It seems that the repair only applied for that main account, whatever fix it was.

Any idea is most welcome.

Thanks
Alain

Shane · « **Reply #1 on:** July 10, 2014, 03:22:55 pm »

Each user account has their own registry file and that is the hkey_current_user

So when you ran the repairs on the admin account all permissions and such got fixed for that account, but the program cant do the other accounts.

Now here is the odd part though, when you created a new account i should have been fine but it wasnt. When a new account is created a default hkey_current_user and all the default files are taken from the default folder under C:\Users

I have a felling that something, a virus or a 3rd party program, might have messed with the permissions on the default hive. So one trick would be is to replace the files in the default folder with one from a good system, which will replace the "C:\Users\Default\NTUSER.DAT" which is the default hkey_current_user hive that is copied for a new user account.

If you like I can grab the default folder from my Windows 7 system in vmware and post it here for you and then you can replace the ones you have with it

Shane

cheongal · « **Reply #2 on:** July 10, 2014, 04:05:04 pm »

Sounds like a plan, Shane. Yes, please.

And I would replace only my DEFAULT one but not for all the standard accounts right ? I can see that the existing NTUSER.DAT have different file sizes ranging from 256KB to 6-7 MB.
So, I am stuck with the existing active ones, am I not ? if it is an issue with the NTUSER.DAT file.

Cheers,
Alain

Shane · « **Reply #3 on:** July 10, 2014, 04:11:20 pm »

Teh default is system wide, it is only used when a new user logs in for the first time, the files from the default folder get copied to their newly created profile folder and then thats it. The default folder isnt touched by that user account again. So the small ntuser.dat that you see it in is the bare min for the profile that is needed. Then once a user starts doing things it growns pretty quick.

And no do not replace any other accounts with this, ONLY the default folder. Once done create a new user and login to see if it helps

This file is only about 1.5 MB uncompressed. So do not delete anything out of the C:\Users\Default folder. Make a backup of it, copy it to another folder just in case. Then extract this 7-zip file to "C:\Users\"

Tell it yes to overwrite everything. You may get some permissions denied errors, that is ok, that is just the protected folders in there not letting it write to them.

See how it goes

Shane

cheongal · « **Reply #4 on:** July 10, 2014, 05:18:37 pm »

Hi Shane,

It did not go well, unfortunately. Actually, my pc is now back to yesterday's state, i.e before I ran Windows Repair !

So, here is what I did :

1. Rename my DEFAULT folder to DEFAULTX (I could not copy all of it, some folders are not accessible like 'application data' and 'start menu' folders.
2. Extracted your copy of DEFAULT into C:\Users\
3. Create a new standard user
4. Logon with new Standard user. Got the logoff right away
5. Change user to Admin user. Got a pale blue screen and cursor. ctl, alt + del let me run userinit or explorer.
6. rollback my changes 1 and 2.
7. Delete new user
8. Restart computer
9. Surprise ! Using my main admin account, I get black screen and cursor. Use ctrl, alt and del to run userinit and I get my desktop.
10. Decide to restore (I created a restore point for the C drive last night after the Windows Repair yesterday) which I did.
11. Computer is restarted. Logon with admin account. Black screen with cursor. Use ctrl, alt and del to run userinit and I get my desktop. Back to square one.

Plan is to rerun Windows Repair once again. Other Ideas ?

Alain

Shane · « **Reply #5 on:** July 11, 2014, 02:18:05 pm »

I didnt want you to rename or move the default folder, there is folders in there that I couldnt backup because they are locked to the system, thats why I wanted you to make a copy of the folder and then extract the files from the zip over it

Shane

cheongal · « **Reply #6 on:** July 11, 2014, 06:53:48 pm »

Shane,

Understood. I did not get it the first time.

So, I followed your instructions this time and answered Yes to overwrite etc. Created a new standard user. Unfortunately, no luck again. Same logoff behavior right away.

Before that, let me tell you that I activated the administrator account (net user administrator /active:yes) and logged right in without any issue. Here is what my current situation looks like :
1. built-in Administrator account : No issue to login
2. user account with admin rights : Black screen with cursor, run 'userinit.exe' to start a session thru Task manager.
3. user account with standard rights : logoff right after login.

It looks like a permission problem. Do you know if the built-in administrator account also calls the userinit key to create a session, just like the other account types ? If so, only that account is currently being able to run this all the way. I have also re-run Windows Repair under my regular user account with admin rights, once again. This time, it did not fix anything. Would it make a difference to run the tool using the built-in administrator account ? Safe enough ?

I am really stumped.

Alain.

Shane · « **Reply #7 on:** July 11, 2014, 08:14:32 pm »

The administrator account is handled differently in Windows, basically it is the true admin. So like on Windows 2008 server when you are logged into the server as administrator the UAC never asks for permission for anything as you are the true admin. So windows does treat it differently.

Question, is the UAC turned on? If it is try turning it off, reboot and see if the problem still happens.

It does sound like a permissions problem and so the first step is to turn the UAC off since we know that gets in the middle of it all.

Shane

cheongal · « **Reply #8 on:** July 13, 2014, 05:21:50 am »

Hi Shane,

Thanks for taking the time to try to resolve this.
Your last suggestion is moving things in the right direction but I don't have a clue as to why this is happening.
Turning UAC to off resolves the issue for any user with administrator privileges but not for standard user ! So, logging in with a user with admin rights gets me to the desktop with no issue.
The standard user continues to get logged off right after entering correct password.

Alain

Shane · « **Reply #9 on:** July 14, 2014, 12:46:04 pm »

No doubt that it is a permission problem then, just very odd that changing the permissions isnt fixing it, makes me wonder if it is a permission on the files and not in the registry.

I have my Windows repair restore the default permissions in Windows 8, I wonder if I should do the same for 7 and see if it does the trick.

Shane

cheongal · « **Reply #10 on:** July 16, 2014, 07:39:57 am »

Shane,

With UAC off, I thought it would be good to know that I am seeing this in the event viewer...when I try to connect as a standard user.
Please note that I already checked the userinit registry key and it does look like the default value.

eventid 4006

The Windows logon process has failed to spawn a user application. Application name: . Command line parameters: C:\Windows\System32\userinit.exe.

Alain

Shane · « **Reply #11 on:** July 16, 2014, 03:30:50 pm »

OK try this, if these work iw ill add these to the Windows repair

Open a cmd.exe as administrator and do these

Net localgroup Users Interactive /add
Net localgroup Users "Authenticated Users" /add

Shane

cheongal · « **Reply #12 on:** July 16, 2014, 04:56:07 pm »

Shane,

No luck unfortunately ! I got the following for both of them. They are indeed already part of the Users group.

The specified account name is already a member of the group.

Alain

Shane · « **Reply #13 on:** July 16, 2014, 05:05:21 pm »

Well, tittie sprinkles.

Ok so I am looking at this
http://support.microsoft.com/kb/929825

Says to check
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
And check the path for Userinit

I want to make sure that Userinit isnt set at HKEY_Current_User\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon for the accounts have trouble.

You will need to load the registry hive file from those user accounts to look at them since they wont log in. Do you know how to do that?

Shane

cheongal · « **Reply #14 on:** July 16, 2014, 05:19:34 pm »

Hi Shane,

One of the first things I checked was the HKLM Winlogon key and it does point to the default userinit.exe.
As for the HK_Current_User, no I did not.
Please note that admin accounts can log in no problem since I switched off UAC. If I change an account from admin type to standard, that account cannot log in and get logged off right away.
And no, I don't know how to load the registry hive. Please let me know and I will see where it takes us.

Thanks
Alain

Shane · « **Reply #15 on:** July 16, 2014, 05:33:41 pm »

Well before we do that lets go check the owner and permissions on the System32\userinit.exe

Since admins login fine and then change them to standard and they they dont login then we need to make sure the permissions on that file are good.

I have attached what the permissions are for a default install of 7, owner is trusted installer.

Shane

cheongal · « **Reply #16 on:** July 16, 2014, 05:41:12 pm »

Ok. here is mine. looks similar.

Alain

Shane · « **Reply #17 on:** July 16, 2014, 05:49:09 pm »

Ok that appears to match up.

Ok so to load another user reg hive, open regedit.

Click on hkey_local_machine

Now click on file and then load hive. Browse to C:\Users and open the user folder of the user we need to check (You may need to have the options set to view hidden files at this point)

Under the user folder you will see NTUSER.DAT that is the hkey_current_user for that user account. Click on it and load it. It will ask for a name at this point, name it anything as it is just for you to know while it is loaded, so in this case name it Test

Now under hkey_local_machine you will see a folder called test, look under there to find the regkey we need to check. When you are all done click on the main test folder at the start again and then go to file an unload hive when you are all done

almost 6 pm for me and time for dinner, I may not respond till morning, but I will try to before then if I can

Night!

Shane

cheongal · « **Reply #18 on:** July 16, 2014, 06:12:46 pm »

Loaded the hive for a standard user and nothing appears to be out of place.

I am attaching a screen shot.

Thanks for your time this evening.

Cheers and Bon appetit !
Alain

Shane · « **Reply #19 on:** July 16, 2014, 07:12:16 pm »

I cant find anything wrong lol

turning UAC off fixed it for admins, which when I researched that error was the fix for admin users. No one mentioned it for standard users. We reset reg permissions, we set file permissions. Yet something is still failing and from the amount of results I found on this it looks like it is a common problem

I think something is screwed up with the UAC, user and groups and some of the core permissions settings and not a simple registry or file permissions since we set everyone to have full rights and that still doesnt fix it.

I think a repair install would be a good next step, this way windows gets reinstalled (Normally, it is really just doing an upgrade to itself) so that way your programs and files will be kept.

First you need Windows 7 with SP1 already on it, if you dont have one you can grab an iso here
https://sites.google.com/site/linuxlablibrary/windows-iso

Then just follow this

http://www.sevenforums.com/tutorials/3413-repair-install.html

At least this way the core items will get replaced including permissions.

Shane

cheongal · « **Reply #20 on:** July 17, 2014, 03:53:50 am »

OK. I will try to find some free time and organize myself to do the repair install. Thanks.

Alain

Boggin · « **Reply #21 on:** July 17, 2014, 08:14:54 am »

Doing an offboot sfc /scannow after booting up with the SP1 bootable disk could save you some time on this.

After booting up with the install disk and selecting Repair your Computer, navigate to the Recovery Environment and select Command Prompt.

Enter bcdedit |find "os device" (that's a pipe symbol before find)

Using whichever letter it gives for partition enter, (assuming C: ) sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows

When done, enter exit to close the command window, remove the DVD and select Restart and see what you get after that.

You may like to post what the sfc reports.

Shane · « **Reply #22 on:** July 17, 2014, 09:06:45 am »

sfc only checks the system files, doesnt mess with permissions or anything like that. Never hurts to do sfc to make sure but I think he already did that

Shane

Boggin · « **Reply #23 on:** July 17, 2014, 09:57:55 am »

I haven't seen any sign of a sfc being done but I would have thought that an offboot sfc /scannow from a clean source would have put all Windows files back to the way they should be and is usually an alternative to a repair install.

I've certainly seen a MSMVP advise it on another forum.

cheongal · « **Reply #24 on:** July 17, 2014, 10:05:28 am »

Guys,

Thanks for sharing. But I did do an sfc (and a chkdsk), that was one of the first tasks to remediate. Not an offboot.

Alain