Error Copying File or Folder; System File Checker; and SFC Scannow

This was a weird one. Virtually nobody seemed to be having this problem. The error message (in Windows XP) was:

Error Copying File or Folder. Cannot copy : It is being used by another person or program. Close any programs that might be using the file and try again.

Nobody was using the file. When I used Unlocker, it said the only program using the file in question was Windows, and Unlocker couldn't unlock it. This happened to a number of files, but not necessarily all. Somebody said it was caused by a virus. I ran a half-dozen virus and malware scans (Symantec Antivirus, Ad-Aware, Spyware Doctor, etc.) and was assured I had a clean system. I decided to try rebooting and running CHKDSK /R from the WinXP installation CD. That ran, and found errors, but evidently this was not one of them: the problem persisted. Another suggestion was to run Scannow System File Checker, so that Windows could verify that it was working with the original program files. Unfortunately, when I tried running SFC, and when it tried to consult the original CD to check my program files, it said, "Windows File Protection. The CD you provided is the wrong CD. Please insert the Windows XP Professional Service Pack 2 CD into your CD-ROM drive." It was definitely the right CD. The Scannow page I had been checking told me to rectify this problem by editing the registry to point to another location, where I would copy the CD files; but when I made the registry edit they suggested, it didn't solve the problem; the registry location they specified was as follows: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\ where HKLM is short for HKEY_LOCAL_MACHINE (which is one of the branches you will see when you take a look at the registry). The change in question, as I understood from the SFC site, was to make sure the SourcePath value was pointing toward the right folder. But I already had the proper location specified there. Another site recommended registry adjustments at that same location, but also at another one: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ The SFC site had told me about the first of those two registry locations, but not the second. But now that I was looking at the first one again, I realized that maybe I should have put the directory name in quotation marks, since it contained a space, like this: "D:\Big Installed Downloads\WinXP\" but that didn't do it. But the SFC people said I would need to restart the computer to make it work. Before doing that, I decided to take two additional steps. First, I used Regedit (i.e., the Windows Registry Editor, invoked by using Run to run REGEDIT from the Start Menu), by right-clicking on the Setup branch just mentioned, to Export a .REG registry edit file, so that if I needed to do this again in the future (if e.g., this Windows installation failed, or if I was doing another one), I could just double-click on the REG file and it would update the registry automatically. Using Notepad, I edited that REG file to remove all the extraneous lines (in case some other manual or automated registry edits would need to change them to some other values, for some unrelated purpose). So here is what the final REG file contained:

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup] "SourcePath"="\"D:\\Big Installed Downloads\\WinXP\\\""

Second, I went ahead and looked at the second of the two registry locations just mentioned. There, the SourcePath value was pointing at a nonexistent folder. So I changed that one too, and created a REG file for that change as just described. On second thought, since I observed that some other registry edits referred to folders whose names contained spaces without quotation marks, I decided not to use quotation marks here. So I corrected the registry edit file and used it, by double-clicking on it, to remove them from the first location, above. I was still watching the registry in REGEDIT in another window and was able to verify that this removed the quotation marks. When I created the second REG file, I didn't bother editing it as I had done with the first. I just named it X.REG; and after it was created, I raided it for just the address and SourcePath lines (because it contained tons of other stuff as well) and pasted that into the REG file that I had created previously. That way, I could make both registry edits at the same time, just by double-clicking on the one REG file. So the one, combined, properly named REG file read as follows:

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup] "SourcePath"="D:\\Big Installed Downloads\\WinXP" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion] "SourcePath"="D:\\Big Installed Downloads\\WinXP"

Of course, if a person knew the proper locations in advance, it wouldn't even be necessary to manually edit the registry; you could just type up the foregoing material in Notepad and run that REG file instead of using REGEDIT. I was going to reboot, but then I saw that the guy to whom this change was recommended said that it did not work for him. Reading on, another source said that the problem would be hard to fix if (as was the case) I installed Service Pack 2 (as one of Microsoft Updates's downloads) after installing WinXP. But Microsoft said that using a slipstreamed CD (i.e., one that combined the original WinXP plus SP2) was only one of two options. The other, they said, was to correct the first of the two registry addresses named above. (Since the second one had referred to a nonexistent folder on my E drive, I figured that leaving it in its edited form, to point to an actual folder on D, was superior, so I didn't change it back.) The ExpertsExchange webpage did provide some links to advice on creating a slipstreamed SP2 WinXP installation disk, if I needed to do that. But here's what Microsoft recommended for the address to be used at the first address: "In the right pane, right-click ServicePackSourcePath, click Modify, type %windir%\ServicePackFiles, and then click OK." So now it seemed that my first registry edit (if the registry hadn't already been pointing to the Big Installed Downloads folder on my drive D) would have been a mistake, in which case I would have regretted not exporting a copy of the registry as it was before my changes, so that I could have created a REG file to change it back to its pre-change condition. Since that wasn't a problem this time around (plainly, I was rusty on the registry editing process), I just went ahead to create another REG file containing the %windir% information just quoted. I wasn't sure how that would look in a REG file, though, so I did it via manual registry edit and then exported it and added it to the slowly accumulating REG file shown above, which now read as follows:

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup] "SourcePath"="D:\\Big Installed Downloads\\WinXP" "ServicePackSourcePath"="%windir%\\ServicePackFiles" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion] "SourcePath"="D:\\Big Installed Downloads\\WinXP"

There was a possibility that, in a future reinstallation, I would not need all three of those lines. But most likely I would. I was making these edits to fix a fresh reinstallation from a drive image, and I was making notes that this and other update and edit information pertained specifically to that drive image. I also found another possible solution to the problem. This one advised the following steps: Start > Run > SECPOL.MSC . Then Local Policies > Security Options > Devices: Restrict CD-ROM access to locally logged-on user. Disable it if it's not already disabled by right-clicking on it, selecting Properties, then clicking in the radio button beside Disabled. Click on Apply then OK, then go to File > Exit. But mine was already disabled, so that wasn't the solution for me. So I decided to rest with the registry edits described above, and I rebooted. Unfortunately, rebooting and registry editing did not fix the file-moving problem, and it also did not solve the problem of SFC looking at the wrong folder. I wasn't certain, but it did seem, though, that some of the files that I had been unable to move before were now able to move. I tried the approach of adding the quotation marks to the registry location, as described above, in hopes that maybe that would work better on the next reboot. What seemed like the more important step, though, was to devise a slipstreamed WinXP installation CD. Following instructions from SimplyGuides, I tried to download Microsoft's WinXP Service Pack 2 and also tried to download AutoStreamer; but these efforts caused Firefox to freeze up, and suddenly WinXP would not download, on this WinXP machine. It began to seem that my system might be more screwed-up than I had realized. So I downloaded SP2 and AutoStreamer to another computer running Ubuntu (using Firefox for the Windows download too!) and copied them over via flash drive. As I understood it, the idea of slipstreaming was to integrate the later files of Service Pack 2 into the installation files of the original software, so that the resulting CD would allow a direct installation of the updated software (Wikipedia), without any need to go to the Windows Update site and download SP2. But when I installed AutoStreamer, it analyzed my WinXP CD (which I had gotten from a university program) and then informed me that the CD was already updated with the SP2 file I had designated, and it would not proceed to do any slipstreaming. I assumed this was because I was using a "student media" Microsoft CD which, once I obtained the original (see below), did say, on its label, that it was "Microsoft Windows XP Professional with Service Pack 2." So that approach turned out to be a blind alley. (Note: another site said that nLite was actually easier to use than AutoStreamer.) The next morning, on cold reboot (i.e., powered down for more than 30-60 seconds), again, some files that wouldn't move on the previous try were now movable; but SFC was still looking for a Windows XP installation CD other than the one I was giving it. This time, it seemed to be the reason for the system's essential ceasing to function: I could move the mouse, and I could kill programs with Windows Task Manager (Ctrl-Alt-Del), but I couldn't kill SFC. So I had to reboot again. According to Microsoft, "System File Checker (Sfc.exe) is a command-line tool that examines protected system files on your computer and restores the correct versions by using backups stored in the Dllcache folder or files copied from the operating system CD." Another site said that if SFC asks you to insert the WinXP CD, that means SFC has found bad files in your DLLCACHE folder. My dllcache was in C:\Windows\system32. I thought about manually replacing DLLs in that folder with DLLs found on the WinXP CD, but a search of the latter indicated that it contained 227 DLLs, and a glance at the former suggested that those DLLs might be scattered around in various subfolders in C:\Windows\system32 -- if, indeed, they were in that folder at all; the several I searched for were found, not on C, but rather in my Big Downloads folder on D (see above). This suggested another possibility. Maybe I should just correct some one or more of the registry entries that would look for drive Z (my CD-ROM drive, to which I had assigned that letter in Computer Management > Disk Management > right-click). In RegHance, I searched for Z: across the entire registry. That produced several dozen hits. It looked like I could narrow them down -- the paths for some of them referred to "Uninstall," for example, which didn't seem implicated in this case -- but it still seemed like something of a pot shot. Before trying that, I reflected on the fact that nobody else seemed to have their I386 folders located in a location like mine: D:\Big Installed Downloads\WinXP. I wondered if it would make a difference if I put them in C:\I386, like others seemed to have done. (I had had my I386 folder on D for some years, and it had not been a problem; but if it was a problem now, so be it.) So I copied that particular folder from D to that new location on C, and then modified and ran the non-quotation-marks version of the REG file above, so as to point the registry toward the new folder on C. The edited line now read, "SourcePath"="C:\\I386" This added 6,771 files (511MB), to C, that I had previously been stashing on D; but since I usually imaged D when I imaged C anyway, the extra volume on C seemed likely to make little difference in my backups and restores. I made a note to copy the I386 folder from the Windows XP CD to C, so as to remember this step if I had to do another installation. I did a search for Big Installed Downloads in RegHance. Before running the REG file just mentioned, it found six hits, including the two that were about to be changed. Those two were the only ones designated, in RegHance, as having SourcePath as their value. After running the REG file and then doing the search again, there were eight, and the two just changed did not appear. It seemed likely that the number of hits had increased because the paths of each included a reference to MRU -- which, I was fairly confident, meant "Most Recently Used." I had recently visited or changed something, and these entries were just tracking that. So it did not seem that I would need to make any further entries before entirely removing, from D, all of the files that I had copied there from the WinXP CD. I noticed, about this time, that I was no longer having the file-moving problems that had prompted this little expedition into SFC land. Since I wanted SFC to work properly for future diagnostic purposes, however, and since I could not be confident that it would not act up again at some undesirable time in the future, I continued the effort to make SFC work. It didn't work now, after these changes, so I rebooted. It had occurred to me that I was not literally using exactly the CD that I had used to install WinXP. I had made a copy of that CD for backup purposes, and had located the original offsite. Now, however, I retrieved that original (whose label, as noted above, described it as "Student Media" "with Service Pack 2"), and tried using it. But it did not make any difference; my trip to retrieve it was for naught. Just to be safe, while I had it, I recopied its I386 folder to C:\I386, over the top of what I had copied there from the backup CD. Meanwhile, I had noticed a new problem. As mentioned a moment ago, I was now having to reboot in order to get rid of the SFC dialogs. The first was just a notice which said, "Please wait while Windows verifies that all protected Windows files are intact and in their original versions." The second, which came up shortly after the first, said, "Files that are required for Windows to run properly must be copied to the DLL Cache. Insert your Windows XP Professional Service Pack 2 CD now." When I clicked on the More Information button on the latter, I got a third dialog: "Possible reasons for this problem: You have inserted the wrong CD. (i.e., a different Windows product CD than the version installed) [or] The CD-ROM in your system is not functioning." If, instead, I clicked on the Cancel button, I got a dialog that said, "If you cancel, Windows might require you to insert a CD later. Are you sure you want to skip this file?" All four dialogs carried the title, "Windows File Protection." If I said sure, go ahead, skip this file, the second dialog would come up again almost immediately. I tried hitting Cancel > Yes for ten times in a row, but the thing just kept coming up. There was no way to actually cancel out of SFC. In an article intended for Windows 98, Microsoft said you could use Alt-F4 instead of Ctrl-Alt-Del (which, in Win98, would not call up the Windows Task Manager but, if memory served, would just immediately terminate the program) to bail out of SFC. I tried that ... and immediately killed Firefox, in which I was writing this blog posting. Trying again -- and making sure that SFC, not Firefox, was in the foreground, I found that Alt-F4 worked to close down the first SFC dialog, but not the second or third. In another article, which confusingly seemed to indicate both that it did, and did not, apply exclusively to Windows XP Media Center Edition 2005, it was stated, "This problem occurs because the System File Checker utility cannot locate certain Windows installation files." So it seemed that the SFC problem might have arisen from the same problem as the Error Copying File or Folder problem, for which I had attempted to use SFC in the first place. In that article, Microsoft suggested the following:

To work around this problem, make sure that the Windows installation files are available when you run the sfc.exe /scannow command, and then click Cancel every time that you receive an error message. The System File Checker utility will successfully complete the scan operation. Note If no Windows installation files are available, you may have to cancel the error message many times. In this scenario, you may want to cancel the whole operation. To do this, follow these steps: 1. Drag the Windows File Protection dialog box to another location on the desktop. Note After you move the Windows File Protection dialog box, you will see a second Windows File Protection dialog box. This second Windows File Protection dialog box contains the following message: Please wait while Windows verifies that all protected Windows files are intact and in their original versions. 2. Click Cancel in the second Windows File Protection dialog box. 3. Click Cancel in the first Windows File Protection dialog box, and then click Yes.

To make sure the files were available, as recommended, I put the WinXP CD in the drive, in addition to having I386 on drive C. Using the copy rather than the original of the WinXP CD, I did as instructed, after rebooting to get a fresh start on the SFC process that I had now mucked up with a confused bunch of "Retry" and "Cancel" button clicks (where the method of bailing out, just advised by Microsoft, still did not work for me). This gave me a cycle of self-reboots, in which WinXP would get mostly reloaded, would flash a BSOD (blue screen of death), and would then reboot and try again. On the second or third go-round, I got back to this blog and resumed with Microsoft's suggestion to just click Cancel every time I received an error message. By my count, this required exactly 150 clicks, though I may have been off by one or two. Or, I should say, 300 clicks, since each "Cancel" was followed by an "Are you sure?" After the 150th click, I got ... nothing. SFC seemed to have vanished. It was no longer a running program in Task Manager. So ... did this little exercise help SFC to function correctly henceforth, so as to help me with the Error Copying File or Folder problem? I ran sfc /scannow again -- and got exactly the same error dialogs as before. This time, however, I retried the steps Microsoft suggested, above, to bail out of SFC -- except that I did them backwards. First, I canceled the first dialog listed above; then I killed the second dialog listed above; then I said Yes, I was sure. (I had to drag no. 2 out of the way to see no. 1 first.) And that worked. No need to reboot to kill SFC this time. Woohoo! So I tried again and clicked to cancel (i.e., skip) the first 20 individual files that SFC was supposedly checking. The progress meter on the SFC dialog did not advance very much. I concluded that the previous exercise, involving 150 cancel clicks, achieved nothing, except that there was a chance that it had made it possible for me to bail out of SFC in the way just described, without rebooting, whereas I was not sure I had that capability previously. Back at the drawing board, I had noticed that a Microsoft page cited above provided the following additional information about SFC:

You can use System File Checker to repopulate the Dllcache folder if the contents become damaged or unusable. To purge and repopulate the contents of the Dllcache folder, in the Run dialog box, type sfc /purgecache You can also specify the protected file cache size by using the following syntax: sfc /cachesize=x The value of x represents the number of megabytes (MB) of space to use in hexadecimal notation. For example, to specify 200 MB, type sfc /cachesize=C8 Note For network-based installations, the WFP service and the System File Checker tool search the network source file directory if the required backup file is not in the Dllcache folder. You must be a member of the Administrators group to purge or change the space allotted for cached protected files. For more information about the Windows File Protection service and System File Checker, click Tools in Help and Support Center.

I wasn't sure if SFC /PURGECACHE would screw up other things, so I did a backup using XP's System Restore program, and then I ran it. I wasn't sure what that accomplished: C:\I386 still contained the same number of files (6,771) and megabytes (511MB) as were in the I386 folder on the WinXP CD. For the record, as I learned by typing SFC /? at a command prompt, the options for SFC were /SCANNOW, /SCANONCE, /SCANBOOT, /REVERT, /PURGECACHE, and /CACHESIZE=x. It didn't appear that any of them would help me right now. Then again, I wondered what would happen if I ran SFC /SCANBOOT. Would it still pose yes/no questions, or would it cruise through in some way that would not work when WinXP was fully booted in Normal Mode? Or, actually, since I didn't want to run SFC at *every* boot, I saw that the better option was /SCANONCE. I issued that command in a dialog box and rebooted, to see the outcome. I had expected that it would run at the boot level, as a command-line program; but what it actually did was to run in the same old way, inside Windows, so I had to quit out of the same dialogs as described above. SFC was still, in a word, defunct. Following Microsoft's advice in the last sentence of the quotation, above, I went into Start > Help and Support and did a search for SFC. This gave me a listing of the parameters (e.g., /scannow) cited above. Elsewhere on the quoted page, they pointed me toward their article, "Registry settings for Windows File Protection," but it was for Win2000. I found an article listing other SFC options for XP, but none seemed relevant here. Another Microsoft page seemed to say that you could also use the /QUIET option, for the purpose of replacing all incorrect file versions without prompting the user, so I ran SFC /QUIET from Start > Run. This gave me a command box that flickered and vanished. Trying again, I ran it from within a manually created command prompt box. This just gave me a list of the working options for SFC, which list did not include /QUIET. So that appeared not to be an option. By this point, I had noticed that several people had commented that they run SFC frequently, to verify that things are OK. I decided to try using it that way myself. So I typed SFC /SCANBOOT at a command prompt, so that SFC would come up at every boot from now on. This assumed, of course, that I would manage to make the thing work, which at present was still an open issue. A page at Tech[dot]Blog raised a question that I had noticed but had then forgotten about. In the REG file lines shown above, why were we pointing ServicePackSourcePath to a "ServicePackFiles" directory? I didn't appear to have any such folder on my system. Maybe the webpage from which I had copied that line had instructed me to replace ServicePackSourcePath with whatever was the actual location for my I386 folder. If so, I had missed it. So now I changed that line of the REG file to be this: "ServicePackSourcePath"="C:\\I386" And then I ran the REG file to update my registry. Out of curiosity, I did a search for I386 folders again, and this time I noticed that, in addition to the 500MB collection at C:\I386, I had a 90MB stash at C:\Windows\Driver Cache. I wondered if those were duplicates, in which case maybe I could reduce the size of C: by 90MB. But no, at a glance those folders seemed very different. So I dropped that idea. I wasn't sure if it was actually necessary to reboot in order to get the registry to notice the new location for ServicePackSourcePath. I tried running SFC /PURGECACHE again, within a command box, to see what would happen now. It replied, "Windows File Protection successfully made the requested change." But C:\I386 still had the same number of files. So -- since I thought maybe the system had to reboot in order to be pointed at the correct ServicePackSourcePath, I rebooted and ran SFC /PURGECACHE again. Well, now I was in a world of hurt. The system started a seemingly neverending cycle of reboots and SFC runs and Active Desktop Recovery screens. The good news: SFC /SCANBOOT was indeed running every time. But it was still feeling the need to compel me to insert the WinXP CD. So what I had achieved was to add sequential crashes to the problem. The Active Desktop Recovery screen gave me the option to Restore My Active Desktop. If I clicked on that, I would get an Internet Explorer Script Error dialog; and if I said Yes, I wanted it to continue to run scripts on that page, then at first it seemed to be responsible for making the system reboot; but after a couple of rounds, it would just give me the script error dialog again. So I clicked No and instead followed the instructions, there on the Active Desktop Recovery screen, to kill my Active Desktop (which I don't think I'd had working in the first place). So at last I was back to equilibrium: I was in WinXP, and it wasn't crashing. I had thought that maybe SFC /SCANBOOT was still asking me for the location of Windows files because I had run PURGECACHE, but it didn't appear that I386 had changed. The same files still seemed to be there. But, of course, I had run PURGECACHE before rebooting, when maybe the registry was still looking at some nonexistent location for ServicePackSourcePath. So I ran SFC /PURGECACHE again. Again, it reported that it had successfully made the requested change. Again, I looked at C:\I386. Again, its Properties reported a total of 6,771 files. It seemed that the operation had *not* been a success, else (according to a TechRepublic article about Win2000) I probably would have seen the familiar two dialog boxes asking me for the WinXP CD. That article also said that ServicePackFiles was a separate folder containing, I guess, backups of backups, so it was a little troubling that I didn't seem to have that folder either. I decided that, since the advice about having a registry line referring to %windir%\ServicePackFiles had come from Microsoft, I had better restore that line to my REG file and, thereby, to the registry. Finally, the article referred to the possibility of an "in-place upgrade," which was coming to seem like the necessary alternative. A Microsoft article entitled "How to Remove Windows XP Service Pack 1 Folders" (article no. 329260) said this:

New Folders That Are Created When You Install Windows XP SP1 The following folders are created when you install Windows XP SP1:

•%systemroot%\Servicepackfiles •%systemroot%\$NtServicePackUninstall$ •folder name that contains 20 random characters, for example, 9470bb12e8a4f3447657236478e41c5 NOTE: The %systemroot% environment variable refers to your Windows folder. The %systemroot%\Servicepackfiles Folder IMPORTANT: Do not delete or move this folder. This folder contains files that are required when you add or remove optional Windows components. This folder is also used by Windows File Protection (WFP) to replace damaged or changed protected system files.

That sounded about right. I didn't recall ever deleting this ServicePackFiles folder, but it wasn't there, or anywhere else on my system. Nor did I have the folder whose name contained 20 random characters. As for the other one, I didn't seem to have a single folder named %systemroot%\$NtServicePackUninstall$, but the C:\Windows folder did contain a boatload of folders whose names began with "$NtServicePackUninstall." It was possible, of course, that SP2 rendered these particular SP1 folders unnecessary. Alternately, a Lithuanian website provoked me to suspect that Microsoft, in the process of designing my nifty Student Media CD containing Service Pack 2, found it necessary to dispense with one or two of these essential folders -- essential in the sense that it appeared SFC might not run properly without them. To address that possibility, I thought I might back up a step and design my own slipstreamed CD, working from a copy of WinXP Pro that was *not* Student Media. But, oops, that would require me to buy a second copy of WinXP Pro, which at that point was retailing for $115+. Instead, I called a tech support person available to me. That person was not familiar at all with these issues, but did suggest I take the obvious step of determining whether these folders were on the Student Media CD. That wasn't successful. I e-mailed Microsoft to ask about this. Next, just out of curiosity (with awareness of the dangers), I thought I might search my old WinXP Home CD. No luck there either. Then, reviewing the Microsoft webpage, I realized that of course those files should not be on the original installation CDs because, it said, they were created by SP1. A TechRepublic article confirmed that C:\Windows\ServicePackFiles\I386 should persist after the installation of SP2. (That article also usefully suggested using WinXP's compression feature to reduce the size of the hopefully seldom-used ServicePackFiles folder.) Just in case I was missing something, I searched again, across all partitions on my system, for a file or folder named ServicePackFiles, not case-sensitive. That was not successful. Meanwhile, I fired up PowerQuest's ImageExplorer, which I think I had gotten when I bought Drive Image 2002, and used it to examine the contents of an old drive image of my WinXP Home system, as formerly installed. Sure enough, ImageExplorer showed that my previous WinXP Home installation had indeed included a C:\Windows\ServicePackFiles folder, within which there was only an i386 subfolder. In that i386 subfolder, however, were a number of items. I restored that old XP Home ServicePackFiles folder to an alternate location and compared its contents against C:\I386, which I again emptied out and replaced with files from the Student Media WinXP CD. The first file in the old XP Home ServicePackFiles folder (referred to here as simply Old XP Home), as now restored to an alternate location, was called 1394bus.sys. This file also existed in C:\Windows\system32\drivers. The second file in Old XP Home was 4mmdat.sys. This did not appear to exist elsewhere on my system. Likewise for the third file in Old XP Home , which was called 61883.sys. The fourth, 6to4svc.dll, was in several locations, including one of the $NtUninstall$ folders and C:\Windows\system32. Within Old XP Home, in addition to 2,057 files at the ServicePackFiles\i386 level, there was also a subfolder called lang. In the lang subfolder was another 64 objects, including chajei.ime, chtmbx.dll, and chtskdic.dll (the first three on the list), none of which appeared to exist elsewhere on my system. I concluded that the XP Pro installation had probably taken files from the I386 folder on the XP Pro CD and had scattered them around to various folders (e.g., system32), but that the I386 folder probably contained files that would exist nowhere else. Since the TechRepublic article just mentioned suggested that the ServicePackFiles folder would be around 500MB before compression, and since that was also approximately the size of the I386 folder, I guessed that Microsoft had not actually left out an important ServicePackFiles folder, but was instead expecting the I386 folder to fulfill whatever functions the ServicePackFiles folder had fulfilled on my Old XP Home installation. So at first it seemed that it could make sense for my REG files, above, to direct all three lines toward the I386 folder after all. One problem with that reasoning is that, as just noted, things did not actually add up. The I386 folder did not begin with the several files just examined in the Old XP Home folder, nor did it contain the same subfolders. There was indeed an I386\LANG subfolder, but there were also seven other folders that did not appear in Old XP Home, and the file lists also did not remotely match up. For instance, the first three files in C:\I386 (as freshly drawn from the WinXP Pro Student Media CD) were _DEFAULT.PI_, 12520437.CP_, and 12520850.CP_. There were also not remotely the same numbers of files: there were only 2,121 (actually comprising only 410MB) in Old XP Home. Plainly, the ServicePackFiles folder on my old XP Home installation bore scant similarity to the present contents of my I386 folder. So it seemed likely that I needed to find some source, other than I386, for the ServicePackFiles folder. One possibility, of course, was just to use the ServicePackFiles folder from Old XP Home. What could it hurt? Well, a lot, I supposed, but not when considered in light of the more radical alternatives of reloading the whole operating system from scratch or doing what Microsoft called an in-place upgrade, also known as a repair installation or reinstallation. It would be interesting, at least, to know whether this would provide a fix for SFC. Of course, this was a counsel of desperation. As a precaution against that or whatever other steps I might soon be taking, I disconnected all drives except the one containing the C partition. This, I knew, would cause a pagefile to be created in the wrong place, so I made a note to myself to reset that once the dust settled. Then, before proceeding further with any radical steps, I went to a command line and typed SFC /REVERT, because I had decided it was overkill (and unnecessary delay) to run SFC at each boot. Instead, I added SFC /SCANNOW to the batch file that I was running once a week for purposes of this sort of intermittent operation. Then I found a PCUG website that offered another possible solution. They considered various scenarios in logical order. The one that interested me was this: After filling C:\I386 with the contents of the WinXP CD's I386 folder, if your system doesn't have a ServicePackFiles folder, but if you do have the registry keys shown in the REG file discussed above, change both of them to refer to C:\. In that case, which is what applied to me, the REG file to implement these changes automatically looks like this. Run it, exit the registry editor, and reboot: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup] "SourcePath"="C:\\" "ServicePackSourcePath"="C:\\" ; Keep for future reference: "ServicePackSourcePath"="%windir%\\ServicePackFiles" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion] "SourcePath"="C:\\" Note the use of the semicolon, which I should have looked up before (I had forgotten if it was a semicolon or a double colon :: ), to add a comment to a REG file. So I ran it, exited the registry editor, and (with some fear and trembling) rebooted. I tried going into Safe Mode first, but it wouldn't run SFC, so I went on into Normal Mode. Except for a little dialog saying, "Runtime error 216 at 51F29FF6" (probably caused by the unavailability of the designated location for Internet Explorer's temporary files folder, or some such thing) and a pagefile now located on D, my system was none the worse for the change, so far. I ran SFC /SCANNOW and got dialog box 1, "Please wait while Windows verifies that all protected Windows files are intact and in their original versions." But that's all I got. No dialog no. 2. It seemed I had solved the problem of SFC. It was in that last webpage, by PCUG, in the advice to change all locations in the REG file to simply C:\. The explanation, apparently, was that SFC was looking for an I386 folder, so you needed to point the registry, not to that folder per se, but rather to the folder that was one level above it. Now SFC ran without a hitch, so I had no further need of Marc Liron's SFC webpage or of the other fine materials I had encountered along the way. As mentioned earlier, the original problem of being unable to move files had seemed to fade out, somewhere in this process. I suspect it may have been a matter of a bad system file being overwritten or deleted at some random point in the process, although possibly reorienting some line in the registry at some point was the trick. I can't say.