Posted 30 July 2010 - 11:18 PM
Posted 31 July 2010 - 07:52 AM
Posted 31 July 2010 - 01:25 PM
Edited by joseibarra, 31 July 2010 - 03:19 PM.
The mediocre teacher tells. The good teacher explains. The superior teacher demonstrates.
Posted 03 August 2010 - 12:31 AM
<<...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
Posted 03 August 2010 - 12:41 AM
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!
Posted 03 August 2010 - 10:04 AM
Edited by joseibarra, 03 August 2010 - 10:25 AM.
The mediocre teacher tells. The good teacher explains. The superior teacher demonstrates.
Posted 03 August 2010 - 11:04 AM
0 members, 0 guests, 0 anonymous users