RFE: Add "SFCDisable"=dword:00000004 (disable WFP pop-ups)

[ceztko]

Taking a look at the news archive page, I saw that many complained in the past about Windows File Protection Pop-ups after nlite processing. It was recently my case, using the just released nlite 1.4.7: I integrated ie7, wmp11, a patched sfc-os.dll and now every time some stupid installer touch system files I got 3-4 WFP pop-ups... But it's just because I know of stupid installers that I want to keep WFP enabled, as most people should do. Understanting that they are just warnings, not errors, I remembered of this little tweak:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"SFCDisable"=dword:00000004

Where SFCDisable=4 is "enabled, with popups disabled". It works perfectly (seems that even M$ devs like their systems tweaked, after all ): WFP works and no stupid pop-ups that you, nuhi, can't fix for every possibile situation (or at least we can't ask you to do so...). Why don't you integrate this tweak in nlite?

P.S.: A small clarification: I am using this patched sfc-os.dll that fully respects values of SFCDisable. Not sure if the original sfc-os.dll respects SFCDisable=4.

Edited July 2, 2008 by ceztko

[GrofLuigi]

Good idea, but what will happen if driver signing policy is set to or reverts to warn (or God forbid, block)? I've seen it happen many times, with or without nLite. Won't it result with mixed files after installation of non-signed drivers?

OK, this is pure speculation, but IMO it's always better to see what is going on.

GL

[ceztko]

Good idea, but what will happen if driver signing policy is set to or reverts to warn (or God forbid, block)? I've seen it happen many times, with or without nLite. Won't it result with mixed files after installation of non-signed drivers?

I don't think WFP applies to driver signing policy (and viceversa). A driver simply shouldn't touch system files, that are in a diferent set, so the user is always allowed to load unsigned drivers, unless the policy is set to block. This is true even in a unpatched system.

but IMO it's always better to see what is going on.

You are right, but the problem is that the WFP pop-ups windows arising in a nlited system:

- are absolutely non-informative: if you are able to consult windows logs (I am not and I don't care; I take a look only at my /var/log/messages ), they can probably help you more;

- they aren't really informing you that someone is trying to ovewrite a files in the system and what files. They are just reminders that you have patched/modified files on your system (and after nlite processing they can be IE7, WMP11 files or sfc-os.dll, uxtheme.dll, etc...). They appears only once on a running system and they come back again the next time you reboot. The reason why they are appearing in particular moment? Because you are overwriting (or some other tools for you) a WFP protected file, yes... but if the file overwritten is correctly present in the dllcache, it will be anyway replaced after you answer yes/no to the pop-ups. The next time you'll overwrite any other WFP protect file in the current session, you won't get any other reminder, and the file will be silently replaced. Try yourself.

Edited July 2, 2008 by ceztko

[ceztko]

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"SFCDisable"=dword:00000004

To quote myself, it seems that setting this key during the install doesn't surive the first boot Something is setting it again to dword:00000000 just before the installer reboot the system. This is not so good as the setting requires a reboot to apply. If someone knows how to make it surviving the first boot, it would help much.

EDIT: "Almost" confirmed. Citing this site, speaking about SFCDisable=dword:ffffff9d value in W2K:

... Jeremy rebooted a few more times and verified that it is the one value (other than 4=popus disabled) that is not reset to 0 after the first boot.

Well, seems that M$ added another "feature" and now 4 is another value resetted to 0 after the first boot. If someone knows how to circunvent this, but I have some suspects it is hardcoded...

Edited July 2, 2008 by ceztko

[GrofLuigi]

There are several methods for patching SFC, but they are mostly aimed at disabling it.

From my experience with nLite, although Nuhi invested tremendeous efforts in fixing the popups (around the time of the news article you pointed to in your first post), SFC enabled still doesn't work quite right. Maybe it was fixed in the very latest version (and you say it isn't ), but since that time I gave up and just use SFC disabled.

I believe this is the site of "janedoe of Neowin" you were talking with. And yes, it is about disabling SFC, but it might give you some clues (IF you haven't seen it before, which I doubt).

FFFFFF9D doesn't work on Win2000 SP2 (I think it was 2) and later OS's. I think I read about a patch that uses that value to make SFC switchable in the registry, but for the life of me can't remember where I read it. Maybe here somewhere or at RyanVM's board. *EDIT* Or was it XPLite?

GL

Edited July 3, 2008 by GrofLuigi

[ceztko]

FFFFFF9D doesn't work on Win2000 SP2 (I think it was 2) and later OS's. I think I read about a patch that uses that value to make SFC switchable in the registry, but for the life of me can't remember where I read it. Maybe here somewhere or at RyanVM's board. *EDIT* Or was it XPLite?

Yes, it's XPLite. If you see the site linked in my first post P.S., it's described how to patch sfc-os.dll to make WFP switchable like xp-lite does. It's this patched version I'm using now. janedoe's patch does work, but it does disable WFP definitively without registry modifications, like nlite does.

From my experience with nLite, although Nuhi invested tremendeous efforts in fixing the popups (around the time of the news article you pointed to in your first post), SFC enabled still doesn't work quite right. Maybe it was fixed in the very latest version (and you say it isn't ), but since that time I gave up and just use SFC disabled.

The registry modify in this post does work with stopping useless pop-ups . Again: at least with my sfc-os.dll, dunno with an unpatched one. The only problem I have with it is that I can't have it available at the first boot, as winlogon.exe is resetting it to 0. Only once: if I set it after first boot, it remains on the next ones.

Edited July 3, 2008 by ceztko