Windows File Protection Fail.

Hello, all. I was trying to fix a userinit.exe file that I suspected was corrupted. I attempted to use Windows File Protection to fix the file. I renamed the userinit.exe file to userinit.old, and waited for the WFP to kick in. Well, nothing happened, except the computer started running very slowly. Then it froze. I suspected that it may be related to the file. I waited for the computer to respond so it didn't.

I rebooted and of course it did not work. I was eventually able to fix the problem, but what I want to know is does anyone have any idea why WFP did not work on that machine? I know now I should have used sfc.exe to check for a bad userinit.exe file now, but I did not think that WFP would fail and that the computer would stop working immediately.

Can any one give me any ideas as to what files WFP protects (because I was sure that userinit.exe was one of them). What is the scope of WFP? Why would it not work properly?

Thank you in advance for the help.

mrsone

<<...but I did not think that WFP would fail and that the computer would stop working immediately.>>

Well...I guess that I don't see where WFP "failed", in light of the fact that you renamed one of the key system files, thus removing it from proper system functioning.

WFP...as I understand it...doesn't replace key files, it prevents them from being accidentally removed by programs. It seems there is no protection against users who rename such files, thus removing them from where Windows might exprect to find them .

Windows File Protection.

As you state, the sfc /scannow command is one way of replacing system files. Using the Recovery Console is another technique. A repair install is yet another technique for accomplishing such replacement.

Louis

WFP looks after 3498 files in a list.

I just used explorer on my XP Pro SP3 system to browse to c:\windows\system32 and renamed userinit.exe to userinit.bak

When WFP replaces a file, it does so quickly and silently (and it did). The replacement will magically appear being copied in from the dllcache folder (usually), and put this in the Event Viewer System log:

Event Type: Information
Event Source: Windows File Protection
Event Category: None
Event ID: 64002
Date: 7/31/2010
Time: 2:10:52 PM
Description:
File replacement was attempted on the protected system file c:\windows\system32\userinit.exe. This file was restored to the original version to maintain system stability. The file version of the system file is 5.1.2600.5512.

See the date and time above - minutes ago.

That is what I expect to see when WFP is working. I demonstrate this to nonbelievers frequently.

It could be that your WFP is broken and if your userinit.exe mechanism is broken, usually that means you will not be logging in in any kind of mode until you fix it from Recovery Console or some other booting method (it is a popular malware target). Usually, an afflicted userinit mechanism results in the "I login and windows logs me right back out (even in Safe Mode)" problem.

If sfc /scannow finds anything to do, you probably have some other problem, and you can't run sfc /scannow in Safe Mode either. It is a good feeling though when sfc /scannow runs and finds nothing to do, so that is a good project to get working. It will complain a lot (and is hard to stop) if your installed SP does not match the SP on your installation CD. OEM/store bought systems can behave differently, but I find it a useless time consumer and have never seen it "fix" anyting, but you can make it work (and it should find nothing to do).

Why do you suspect your userinit.exe?

Try your WFP by renaming one of the other protected files like c:\windows\system32\taskmgr.exe (like I just did after my userinit.exe) and you should see this event:

Event Type: Information
Event Source: Windows File Protection
Event Category: None
Event ID: 64002
Date: 7/31/2010
Time: 2:18:28 PM
Description:
File replacement was attempted on the protected system file c:\windows\system32\taskmgr.exe. This file was restored to the original version to maintain system stability. The file version of the system file is 5.1.2600.5512.

If your WFP is broken of course it should be fixed!

Edited by joseibarra, 31 July 2010 - 03:19 PM.

<<...but I did not think that WFP would fail and that the computer would stop working immediately.>>

Well...I guess that I don't see where WFP "failed", in light of the fact that you renamed one of the key system files, thus removing it from proper system functioning.

WFP...as I understand it...doesn't replace key files, it prevents them from being accidentally removed by programs. It seems there is no protection against users who rename such files, thus removing them from where Windows might exprect to find them .

Windows File Protection.

As you state, the sfc /scannow command is one way of replacing system files. Using the Recovery Console is another technique. A repair install is yet another technique for accomplishing such replacement.

Louis

I see your point. I was actually told this was the way to get a clean copy of the userinit.exe file on a computer if you suspect the file has been infected with malware. It does make sense that if it is renamed deliberately by a user it may not work. I did an exercise on a VM where this was used on a "machine" infected with malware and it "fixed" the suspected corrupted file on the VM....

Needless to say I am very angry at the person who mis-informed me. I intend to ask them about it very soon.

WFP looks after 3498 files in a list.

I just used explorer on my XP Pro SP3 system to browse to c:\windows\system32 and renamed userinit.exe to userinit.bak

When WFP replaces a file, it does so quickly and silently (and it did). The replacement will magically appear being copied in from the dllcache folder (usually), and put this in the Event Viewer System log:

Event Type: Information
Event Source: Windows File Protection
Event Category: None
Event ID: 64002
Date: 7/31/2010
Time: 2:10:52 PM
Description:
File replacement was attempted on the protected system file c:\windows\system32\userinit.exe. This file was restored to the original version to maintain system stability. The file version of the system file is 5.1.2600.5512.

See the date and time above - minutes ago.

That is what I expect to see when WFP is working. I demonstrate this to nonbelievers frequently.

It could be that your WFP is broken and if your userinit.exe mechanism is broken, usually that means you will not be logging in in any kind of mode until you fix it from Recovery Console or some other booting method (it is a popular malware target). Usually, an afflicted userinit mechanism results in the "I login and windows logs me right back out (even in Safe Mode)" problem.

If sfc /scannow finds anything to do, you probably have some other problem, and you can't run sfc /scannow in Safe Mode either. It is a good feeling though when sfc /scannow runs and finds nothing to do, so that is a good project to get working. It will complain a lot (and is hard to stop) if your installed SP does not match the SP on your installation CD. OEM/store bought systems can behave differently, but I find it a useless time consumer and have never seen it "fix" anyting, but you can make it work (and it should find nothing to do).

Why do you suspect your userinit.exe?

Try your WFP by renaming one of the other protected files like c:\windows\system32\taskmgr.exe (like I just did after my userinit.exe) and you should see this event:

Event Type: Information
Event Source: Windows File Protection
Event Category: None
Event ID: 64002
Date: 7/31/2010
Time: 2:18:28 PM
Description:
File replacement was attempted on the protected system file c:\windows\system32\taskmgr.exe. This file was restored to the original version to maintain system stability. The file version of the system file is 5.1.2600.5512.

If your WFP is broken of course it should be fixed!

As I mentioned in my reply to Louis, I did encounter a time (although it was on a VM) where the WPF worked flawlessly. I know it does work. I was mystified as to why this time it didn't. At any rate, I'll be a lot more careful when dealing with files like that from now on. I was told that anytime you suspect a necessary system file is infected, if you use WFP on it, it should be okay.

Specifically, I was told about this in combination with using AutoRuns. I was told that if you select "Hide Microsoft and Windows Entries" and any Microsoft files or entries still show up, this is a sign of malware infection of said file showing up. I had my doubts about this, though, because when I saw userinit.exe in AutoRuns, it was still operating out of the correct location.

I took the "professional's" advice over mine and ended up bricking this computer until I could get it fixed. Does it matter what extension you name it as? I named it .old, does .bak work better?

If you are suspicious of a file, you can rename/delete it and if WFP is working, it will try to replace it, if it is in the list of 3498 files.

You can also take a protected file like taskmgr.exe and copy some other file over the top of it - like the command prompt:

copy c:\windows\system32\cmd.exe c:\windows\system32\taskmgr.exe

Then if try to open TM you will get a command prompt window instead. That makes sense.

WFP will not detect the fact that the new taskmgr.exe is not the "right" file and WFP does nothing about it. It only seems to
check/care if the file is totally missing, not if it is the "right" file.

Malicious software could just replace your good file with some other file of the exact same name and WFP will not do anything about
it.

Then if you delete the "bad" taskmgr.exe (which is really the command prompt), WFP will replace it - with the cmd.exe and not the
correct taskmgr.exe like you would hope! Things look reasonable in the Event Log, but WFP did not replace the missing file with the
correct taskmgr.exe - it replaced it with cmd.exe. I am sure things are working as designed, but not as expected.

The time waster "sfc /scannow" will not correct the problem either.

Turns out WFP is not really too smart about the files it is supposed to be protecting and can be easily outsmarted. It is just "okay"...

I don't think the rename extension (.bak or .old) makes any difference, I just used a common example that hopefully relates to the
majority of the people. You just need to make one of the protected files missing from where it is supposed to be and WFP will do the
best it can.

I would not say that if it shows up in Autoruns not belonging to Windows it is indicative of a problem. I would like to read that story.

If you try the simple test case using the example and it goes unnoticed by WFP, then I would try to figure it out. WFP could really be broken
and there may be some clues in Event Log. I can make mine not work but it is always something I did to myself.

P.S. Can somebody help me get my taskmgr.exe back? Just kidding...

Edited by joseibarra, 03 August 2010 - 10:25 AM.

Reading material only:

How to restore the userinit.exe file - http://www.bleepingcomputer.com/forums/t/229227/how-to-restore-the-userinitexe-file/

New Userinit File - http://www.bleepingcomputer.com/forums/t/240289/windows-keeps-restarting-by-itself/

Replace Userinit File In XP - http://www.bleepingcomputer.com/forums/t/277227/cant-stay-logged-in/

Louis