johnhc

vinifera, since you are running on VM, you can do some normally dangerous things. So, do a cancel on the message you get and respond yes to ignore the error message. Then look in your System log and you should see an information message from Windows File Protection saying which file was not restored. Please post the file name here. Perhaps it is uxtheme.dll. Whatever it is, do a search on your System32 folder for it and let us know where you find it. If it is uxtheme, please check the hash and let us know if it is the nLite modified one or the original. Enjoy, John.

peterhb, I see nothing that concerns me in your Last Session. I see you have no Tweaks at all and hope you have not run nLite more that one against the same source. So, please answer Ponch's questions and we'll go from there. Enjoy, John.

vinifera, unless you are tired of this, there are some more things to try. I had to spend some time to get mine to work. Please post a screen shot of the dialog pop-up you are getting. What file is it complaining about? If it is complaining about sfc_os.dll, what file ends up in the System32 folder - nLite modified or original? Do a search on your Windows folder for sfc_os and post where any are found and what they are - modified or original. Want to continue? Enjoy, John.

mirri888, you are absolutely correct about KB817778. I failed to read the details. MS states clearly that the update applies only to SP1 and the changes are included in SP2. Sorry about that. This does give you a good hint as to where to look for the files you need to get it back - SP2. If you are knowledgeable, then take a look at SP2 and see if you can determine where IPv6 is in there. It may be easier to start afresh. Please let us know what you think. I am running XP x64 and can't seem to find a trace of IPv6 except for the listing in Local Area Connections. Enjoy, John.

vinifera, I don't understand what you mean by "regarding dialog problem" with my 2008 thread. I had no problem and have no problem now. What I was referring to was testing SFC after I have restored the function. Then, I get the dialog saving that a system file has been altered and it is replaced. I tested this by messing with shell32.dll. You should test it also. I have not shown my exact method and it is a little different. I suspect the difference does not matter, but since you are getting the dialog when you restore sfc_os.dll, I will explain in detail how I do it. I do run my .reg file and .bat under WPI, but I am not suggesting you use WPI. I was already using it and it was convenient to use for this function. It does run after Windows is on the Desktop after the last boot during Setup. This is a little later than when you are running. What I do: Place the original sfc_os.dll (with changed name) in a System32 folder inside the $$ folder inside the $OEM$ folder. This get copied into the System32 folder on my system disk during Setup. Run the .reg file I show above. run the .bat file I show below - renaming the modified sfc_os.dll and copying the original back into the System32 folder. Rename "%WinDir%\system32\sfc_os.dll" "Disable_SFC_sfc_os.dll" Copy "%WinDir%\system32\Enable_SFC_sfc_os.dll" "%WinDir%\system32\sfc_os.dll"I would not think it would matter, but you might give my method a try. Please let us know what happens. You did not say what the nature of the modified sfc_os.dll after running nLite. Is it indeed the same version, size but different hash as the original? Enjoy, John. Sp0iLedBrAt, I am not sure what you are showing us here. Are you showing that mousing over the sfc_os.dll file show one version and Properties shows another? Enjoy, John.

vinifera, just use the Version tab under Properties to see if they are same/different. Please do a search on your source folder after running nLite and your original CD folder for sfc_os (no extension) and look at the size, version and hash for all files found. You will need to extract the sfc_os.DL_ to see the information for the files. If you saw the 2008 thread I pointed to above, you will see that the nLite modified file is the same size, but different hash. Possibly an SP (have you added an SP?) or a hot fix has replaced the nLite modified file. I don't think what you are proposing will help, but it won't hurt to try - power of VM. Enjoy, John.

vinifera, if reversing the order of the commands does not stop the SFC message, then take a look at the sfc_os.dll in your source folder and see if it is the same as the one in your original CD. I check the hash codes for this (I use HashTab - free). Also look at the version number. If it is different, then perhaps a hot fix has updated the file. Remember I am running XP x64 and my experience does not reflect directly into yours. You can see why it was important to use a VM for these tests - I hacked around on this for some time. Enjoy, John. EDIT: Here is a thread that I started a year ago about this subject.

vinifera, I don't know why you are getting the message from SFC. I don't and I am changing the Registry before I do the rename and copy. Are you sure you have SFC disabled for your test run? Please attach (no paste) your Last Session.ini. Enjoy, John.

peterhb, based on the information supplied, I have no bright ideas! So, please attach (not paste) your Last Session.ini. Make sure to always start with a fresh copy of your CD files/folders, do all your work in one nLite session and integrate only one SP. Please report when you have a solution, so others can benefit. Enjoy, John.

vinifera, no, you need to drop your \, as: %source%$OEM$\SFC\sfc_os.dll %systemroot%\system32\sfc_os.dll /yEnjoy, John.

vinifera, your full path command will not work because the %Source% has a trailing \, so now you will have two. If the copy command is failing because of path, the .reg is also for the same reason - the enableSFC.reg file cannot be found. I am still looking and will get back later if I see anything else. Enjoy, John.

vinifera, I am not sure how you are running the commands, but it looks like to me that the two commands that are failing are failing because they do not have full paths on the .reg and .dll files. I don't know what directory is active when your .cmd file is being executed, but I bet it is not the correct one. Please include full paths here regedit /s enableSFC.reg copy sfc_os.dll %systemroot%\system32\sfc_os.dll /y and let us know how it works. If the .reg continues to fail, please post it also. More error information is always better. Enjoy, John.

mirri888, please take a look at KB817778 AND respond, letting us know if any of this helps. Enjoy, John.

mirri888, you might try looking here. Good luck, John.

vinifera, you are very welcome. Please let us know how you make out. Enjoy, John.

vinifera, I hope you are using a virtual system, because it took me a number of trial runs to get this to work for me. I used the $OEM$ folder to place the original sfc_os.dll into the System32 folder under a new name. I then used WPI (Windows Post Install, see forum below) to rename the modified sfc_os.dll and copy the original into the System32 folder as sfc_os.dll. I then ran a .reg file to change the Registry. I assume you could do this out of the Unattended RunOnce exit, but I did not try it. I was using WPI for many installs and it is well suited for these types of things. Enjoy, John.

vinifera, I found a way to enable SFC after install. NLite modifies the sfc_os.dll to disable SFC, so I restore the original (copied from my source CD) and then set the appropriate Registry keys as follows: Windows Registry Editor Version 5.00 ;Re-enable WFP [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] "SFCDisable"=dword:00000000 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Winlogon] "SfcDisable"=dword:00000000The reason this may look funny is because I am running XP x64. If you are running XP (32 bit), then you will need to find the correct key(s). I offer no guarantees, but this works for me and I have been using it for some time. Enjoy, John.

stormbrush, you cannot place it on your created user account DeskTop, because at the time the $OEM$ folder is processed, your user account is not created. Another idea is to place the folder into your installed folder and use a DOS copy command placed in the RunOnce exit in the Unattended section to move it to your user account DeskTop. Enjoy, John.

vinifera, it may make a running Windows system run a little faster. But, with SFC turned off, if some bad software wants to replace some important Windows files, nothing will stop it. If you are doing it just to reduce install time, I would suggest you not disable SFC. How many installs do you do? If you are doing it so you can install modified Windows files, then I recommend you enable it again after installation. Enjoy, John.

I found a work around for the ImgBurn upper case name problem. I simply ignore the error message produced when I use ASCII in place of DOS for the character set. See here. Enjoy, John.

I switched to ImgBurn but discovered that it converted all the file and folder names to all upper case. There seems to be no work around for this. I went back to nLite and the Create ISO still messes up my ISO (see my first post) using the Default ISO Engine, so I tried the Mkisofs and it seems to work. The ISO auto starts on my VM, all the files appear to be there and the file/folder names are mixed case as original. I have yet to do an install, but will soon. Thanks for all the suggestions and help. Enjoy, John.

rmanal, welcome to the forum. The driver is in a folder, in a folder called NLDRV which is in your AMD64 (XP x64) or I386 (XP). The individual drivers are in folders named 001, 002, etc. Locate the one containing the driver you want to delete and delete the folder. I have not tried this and am not sure it will work. The safest way is, of course, is to start over with a fresh copy of your source and don't include the driver. You can use the same Preset as before and just delete the driver from nLite's list in the Driver Task. Please let us know what you learn. Enjoy, John.

bargy, sorry we did not nail it. I did not expect the Tweak to correct your problem, just needs to be removed so you don't bump into that problem later. The error message gets a number of hits on Google and MS Support. I did not find any that sounded directly related, but you might do some searches and see if your Services - Logon tab are correct and that the Registry keys talked about are set properly. Enjoy, John.

bargy, you need to remove this tweak if you rebuild - "Explorer-Launch folder windows in a separate process". It exposes a Windows bug, but I doubt it has anything to do with your problem. It is easily undone in your system by going to "Folders Options", View tab and unchecking the option. If you will search on the tweak name, you can find more detail on the symptoms. I failed to ask, did you start the Task Scheduler service after you installed it? - assume you did. I am running out of ideas and will need to do some research. As I said up front - these are tough and in general one should not count on recovering a removed component. I don't know how much you have invested in this system, but it may be ultimately less work to start anew even if we eventually fix your problem. Please let me know if the Task Scheduler service is running and I will look around some more in the meantime. Enjoy, John.

bargy, not really. Did you delete or disable any services? Perhaps you have killed a needed service. Please attach (not paste) your Last Session.ini and we'll take a look. Enjoy, John. EDIT: The Task Scheduler needs RPC (Remote Procedure Call).