Sunday, July 29, 2007

Review: Canon CanoScan 8400F Film/Negative Scanner

Review I bought the CanoScan 8400F from Newegg for $123 in June 2006, and decided to sell it in July 2007. Newegg no longer sells it. It is an old scanner, in the sense that newer models have inevitably come along; but I expect this particular scanner, and many others like it, will be circulating for years to come. Also, at this time I am preparing the eBay ad through which I will sell it. So I am taking some time to write up what I have learned from my year's usage of this machine. I did find the Newegg ad from which I purchased in the Waybackmachine website. According to that ad, as of spring 2006, the scanner had an average five-egg rating (out of five max) from 175 voters. I am inclined to be somewhat more critical. I would give it four eggs rather than five. Here are my criticisms: 1. The design is very nice. My scanner still looks good. But they designed the black plastic part of the lid from plastic that is too soft. I was pretty careful with my scanner; yet things do happen, over the course of a year. Despite my best efforts, mine has picked up some small scratches. Some might not mind such thingsn at all. I do, a bit. I wish the designers had not seemingly done their best to make those scratches visible. 2. The buttons on the front did not work for me. There are four buttons, labeled E-mail, PDF, Scan, and Copy (which, incidentally, are not exactly the four uses for which I would want buttons). I think I may have had them working at one point. As I recall, the trick was to have the CanoScan Toolbox open before trying to use the buttons. I am not sure whether I used that trick on this machine, or on the other Canon scanners I have had, or both. Point is, it's not working for me right now. I am sure I could figure it out. Canon's tech support has been responsive for me. But that's not good enough. The whole reason for buttons on the front is to keep it simple. Buttons on front are for people who just want to step up and press (you guessed it) a button and make their scan. 3. The quality of the scans is good to very good. It has not been fantastic, however, and I expected fantastic when (a) I had fantastic scans from my older CanoScan LiDE 30 (I mean, ordinary documents scanned on that machine looked as if someone had taken a picture of them, literally) and (b) I was spending twice as much as some scanners cost. I am sure there may have been some settings I could have tinkered with to make things better. But I'm not a photographer. I didn't plan to invest the time (and did not, in fact, invest the time) to learn how to work magic with a photo. 4. The controls were painful to use. I could not tell what some of the options in the ScanGear software were for. Obviously, I could (and I did) tinker, to some extent; I actually have gotten reasonably good at adjusting gamma and contrast especially. But I still would not say I have mastered the other available controls, and I am sure a lot of other people are much the same. It is good that the controls are there. But the companion problem is that this scanner did not retain settings. Someone said that this is due to Windows XP, and indeed I have had the same experience with other scanners. I'm just wondering whether it was impossible for Canon to do anything about it. At my level of expertise, it seemed that each photo's settings had to be adjusted again from scratch. I just didn't have time or patience for that. I had too many photos and frames to scan. 5. The holder for the 35mm negatives, in particular, was not very accommodating. Old negatives curl. They may just not be very cooperative; and that holder expected them to. I was able to work with it nonetheless, but it was a hassle sometimes. I suggest an approach that would latch firmly onto one edge of the negative, and then impose lateral pressure to bring the other side down to an appropriate place. Again, though, I don't know if any other scanners in this price range are better in this regard; this is the only negative scanner I have used. In the end, with few exceptions, I was able to make it work. 6. Software installation was good, the first time around, and a hassle, the second time. This may have been my fault. It is possible that, the second time, I connected the scanner before I installed the software. I am pretty sure that was not the case, but it is possible. I do appreciate Canon's earnest efforts to help me through it. Their tech support, via e-mail, was very responsive. But again, I really want to avoid that kind of time-consuming, relatively unproductive hassle. With those caveats, I would definitely recommend this scanner. I was able to use it to work through a good number of negatives. It scanned to a pretty fine resolution. It has been a solid, reliable performer. I haven't seen another scanner that I would have bought in its place, though I haven't been looking either. I also found that Canon's tech support was readily available. Out of three or four e-mails that I sent them, all but one got an actual human response within just a few hours. They did not respond to one of my e-mails, but I think that is probably because I had baffled them and they did not know the solution to my problem. That problem ultimately appeared to derive from an issue with my Windows installation, not with Canon software or hardware. Usage Tips Some may not understand, as I did not understand, how the negative scanning feature of this machine works. Basically, the scanner contains two scanning light bulbs. The second one is in the lid. You remove the white cushion that you would ordinarily leave in the lid (if you were scanning documents, for example), and you plug in a cord that runs from the lid to the body of the scanner; and when you tell the scanning software that you're scanning from negatives, it uses the lap in the lid to shine light through the negatives, so that the scanning lamp in the base can see what's on the negatives. To hold your negatives in place, the scanner comes with three plastic frames. The scanner can sense when these are in place; I think it won't turn on the lid light unless you're using one of these. The frame that will be most commonly used will probably be the one designed to hold 35mm film negatives. Note: you can also use these frames to accommodate other sizes of negatives. For example, I used the largest frame to scan negatives from a 1970s-era disc camera, where the negatives were arrayed in circular fashion -- but I was only able to scan one frame at a time! I also used the 35mm one to scan 110 film negatives, but there I had to cut the 110 negatives into sets of two and let the pair straddle the boundary between the 35mm frames. I got my best results, when scanning negatives, by clicking on Preview every time I loaded a new batch. I thought it wasn't necessary, because after all I was scanning exactly the same parts of the screen. But in ways that I did not fully understand, the system seemed to be making automatic adjustments to each new batch, and if I did not preview, I would not see them. Note that the automatic adjustment feature works differently if you select one negative frame, in particular, and crop within it. Other frames in the same batch may suddenly look better or worse. In some situations, where I was loading negatives from diverse sources, I found that I had to take several passes. On the first scan, I might have settings that would work for negatives 1, 3, and 8; on the second pass, I might have to use very different settings for negatives 2 and 6; and so forth. Be sure to look at your results. Using the highest setting for dust and scratches may remove crispness. But using the lowest setting may give you poor results. On balance, I definitely got my money's worth from this product. I wish it had been easier to use, and the quality was not of the very highest level. But I have a lot of pictures available to me, now, that had been locked up in negatives, and I'm grateful for that. It really did the job for me. I have emphasized negative scanning here, because that's this scanner's specialty, but with the foregoing criticisms, it also did a good job creating PDFs and JPGs from documents.

Saturday, July 28, 2007

System Crash Woes

I assembled a new computer, and it kept crashing -- sometimes on bootup, and sometimes in the middle of nothing, out of the blue, as I was working away on something. It wasn't actually a new computer, per se. I just replaced key components. I kept the old case, hard drives, floppy drive, CD/DVD drive, and peripherals (monitor, keyboard, etc.). What I replaced was the motherboard, video card, processor (CPU), and RAM. I had already done overnight tests on the RAM, using a separate bootable CD and diagnostic program supplied for the purpose, and was confident that the RAM was OK. The motherboard, in detail, was an MSI (Micro-Star International) P6N SLI Platinum LGA 775 NVIDIA nForce 650i SLI ATX. (The links, there and below, go to the respective Newegg pages. Newegg was a highly rated computer component merchant. The links show that these items received high marks from a relatively large number of purchasers.) The product information page itself no longer seemed to have the model number, but the manual for that product provided an MSI model number of MS-7350, and on an older version of the product page I had seen a reference to "MSI Part No: MS-7350-020." (I noticed, when using Crucial's Memory Advisor Tool, that for some reason the MSI P6N SLI-FI motherboard also apparently had the same MS-7350 part number.) The video card I was using was an EVGA 256-P2-N624-AR GeForce 7900GS 256MB GDDR3 PCI Express x16 KO. The CPU was an Intel Core 2 Duo E4300 Allendale 1.8GHz LGA 775, model BX80557E4300. All were retail purchases (i.e., not refurbished, OEM, or open-box). Finally, the RAM (the only item not purchased from Newegg) consisted of four 1GB sticks of Crucial Ballistix 240-Pin SDRAM DDR2 800 (PC2 6400) Dual Channel, model BL2KIT12864AA804 (CAS latency 4). I bought this equipment with an eye toward the future. I had a bit of time to devote to an upgrade (though certainly not as much time as the process wound up taking!), and I expected to use this upgrade for several years. I had bought a new motherboard just the previous year, but the system before that had lasted since 2003. I hesitated to replace the one-year-old motherboard; I did so primarily because I anticipated increased system load as I moved toward running Windows XP Professional inside VMware on a Linux system. (I have already posted some remarks on my recent efforts with VMware.) I had also noticed some slowdowns while doing research, when I might have a number of webpages and PDF files open. For both such reasons, RAM had come to seem like a particular bottleneck; hence, I had also explored the possibility of adding non-system RAM for purposes of creating a RAM drive. But I was experiencing crashes with this new hardware. Lots of crashes. Some of them, I had figured out, were related to the effects of installing Ubuntu Linux in a dual-boot arrangement. But it seemed that I had sorted out those issues, and yet the crashes persisted. So this appeared to be yet another aspect of the upgrade process that would require detailed and determined attention if I hoped to resolve it. The time had come to do so: I was nearing the end of the 30-day return period for these items. If one of them was defective, I needed to figure that out. I had already replaced the motherboard once. Newegg had accepted the first one for refund and had sold me another one. Both the first one and its replacement had displayed what appeared to be a CMOS problem on bootup (especially after extended power-down), not remediable by mere battery replacement. It was a problem that some other users had also mentioned. The BIOS would forget its settings and I would have to go back into setup. This was not anything that I had experienced with other working mobos. It did not seem, to me, that this problem would explain why, sometimes, the system would barely boot, and at other times I could work all day without a problem. I honestly did not know, at this point, whether zero, one, or both of these MSI motherboards were defective from MSI's perspective. In the VMware/Ubuntu struggles just mentioned, I had discovered that installing Linux would screw up the system's master boot record (MBR), so that Windows would crash shortly after booting. I had learned how to use FIXMBR, booting from the Windows XP installation CD, as described in more detail in that other posting, to counteract this Linux problem, and had also essentially ceased dual booting except with the aid of a Super Grub Disk. For practical purposes, this was now a Windows machine that happened to have some unused Linux partitions on one of its four hard drives of varying sizes (two of which were primarily intended -- once I got the system organized -- for offline or infrequent storage). I used the WinXP install CD, not only to run FIXMBR, but also to run CHKDSK /R from the Recovery Console. It seemed that CHKDSK found and fixed errors almost every time I ran it. This, too, seemed unusual. Since three of the drives were large, it could take quite a while to run CHKDSK /R; and the need to do it frequently meant that, as at the time of this writing, I had to work on the laptop while waiting for the desktop to go through its maintenance paces. For troubleshooting purposes, I disconnected all of the (physical) drives except the boot drive. This one contained four partitions or logical (i.e., not physical) drives. The first, which Windows saw as drive C, was the PROGRAMS drive, so called because (of course) this was where I installed Windows and other program software. The second, drive D, was called STATIC because its contents were relatively unchanging. They consisted primarily of (a) software that I had to have somewhere on the system in order to do upgrade installations and (b) the original installation materials that I had used to install programs on C. In category (a), an example was that, at one point, I had been using an older version of Microsoft Frontpage, but then I had bought an upgrade. To avoid having to insert the old CD each time I wanted to make a modification to Frontpage (or, indeed, even the first time, when I was doing the upgrade), I copied the necessary program files from the old CD to a folder on D, and pointed the upgrade installer to that location. Until just recently, I had been doing this with the WinXP \I386 folder, and probably could have continued to do so. In category (b), I found that it was helpful to keep separate folders to store the programs that I installed on C. So let's suppose I used PowerQuest's Drive Image 2002 (no longer available; absorbed by Norton Ghost, which, I had decided, was an inferior product; probably best replaced at this point by Acronis True Image Workstation) to make an image of my disk on July 1. Then I installed a bunch of new programs. I would always try to install those programs from downloads or CDs, not on-the-fly from a webpage. That way, if something went wrong in the installation of some other program, I could quickly retrieve and retry the rest of the things I had installed. I would put all of the programs installed since July 1 (or, in the case of a CD, I would put a text file directing me to the CD), along with text files containing other information (e.g., pointing me to a website that would not let me download the software I was going to install, or providing configuration instructions for whatever I was installing), into a folder labeled "Installed Since July 1." So drive D contained a series of "Installed Since" folders full of software and notes. Drive E was a DATA work area, which I kept backed-up, and drive F was a big work area (for e.g., AVI files) that were too big to back up onto DVD/RW and were therefore not often backed up, but that could generally be restored (from e.g., the videotape from which I would have created the AVI). Since I did not burn all of my Drive Image PQI files (i.e., disk images) to DVD, drive F -- which I called the BACKROOM drive -- also contained large drive image files that were not backed up. (That is, I might have burned a backup once a month, but I might have made drive images of drives C and D several times a month.) At the point at which I began this particular post, as I say, I had disconnected the other drives, leaving only partitions C, D, E, and F (on a 500GB Maxtor SATA drive) visible to Windows. I had run Recovery Console from the WinXP installation disk, and in Recovery Console I had run FIXMBR (twice, for good measure) and had also run CHKDSK /R repeatedly on each partition until it no longer came up with errors (twice for two partitions, once for the other two). I then attempted to reboot the system into Windows XP (Normal Mode, as distinct from Safe Mode, which was typically available by hitting the F8 key (repeatedly, because it was easy to miss the window of opportunity) shortly after reboot). (Note that you would get a different, shorter set of options if you weren't using F8 -- if the machine was automatically taking you to a menu because the preceding boot failed). This, then, was the actual starting point for the effort chronicled in this particular posting. The attempt to reboot into Windows XP Normal Mode failed. I did not see exactly where it died, so I tried again. I had noticed, in recent weeks, that in some instances the system would progress to a different point on reboots, so I let it run a couple of times. This time around, it was not like that. I saw, in each instance, that it would show the mostly black screen with the big Windows XP logo; I saw that the progress bar at the bottom (consisting of three dots that would move from left to right, over and over again) would be moving normally, at first, but then would freeze; and then the system would reboot. Next time around, it would offer to reboot in Safe Mode, and when there were no takers it would go on to make its bid for Normal Mode again. After three or four tries at that, I saw that it was making no progress, but was instead rebooting at the same place each time. So then I selected Safe Mode, and it succeeded there. I dimly recalled that Windows maintained a boot log, or at least that you could set it to do so, so I started with the Microsoft page on that. They said, sure enough, that the NTBTLOG.TXT file was located in the %windir% directory -- which, as I translated it, meant C:\Windows. I did find that file there, and opened it in Notepad. It was a voluminous file. It seemed to contain the cumulative records of all programs (or at least drivers) that had been loaded, or not, in each bootup for some weeks into the past. I noticed, at the top of the file, that the first bootup's record began with the words "Service Pack 2," followed by the date and time. So I went to the bottom and worked my way up to the first occurrence of those same words. From there to the end of the file, I noticed, were a lot of instances when drivers were not loaded, which was what I would have expected from the record of the current Safe Mode bootup. Right before that, as it seemed from the starting time, would be the record of the next-to-last boot effort, which had involved a failed attempt to boot into Normal Mode, as described above. But on closer examination, it looked like there were a bunch of drivers installed in a row, one after the next, ending with MUP.SYS (used to be AGP440.SYS, but I no longer have an AGP video card), followed by a few others later on. MUP.SYS was suspicious because that was the last of the drivers that my system would report that it was loading, when it booted into Safe Mode. So I was not confident that I was reading this thing right -- that I was really looking at the log of attempts to boot into Normal Mode as well as Safe Mode. A PC Answers webpage told me that the NTBTLOG.TXT file was not very human-readable, and that I should use a boot log analyzer program instead. They pointed me toward, first, the evaluation version of RegRun 3 from Greatis Software and, second, the free A1 Bootlog Analyzer. A report of a Microsoft presentation made me think that I had been mistaken in going to Recovery Console first. Recovery Console, they said, was for situations where you could not get into Safe Mode. If you could get into Safe Mode, that was where you were supposed to begin your troubleshooting efforts. So, OK. Now I knew. The guy giving the presentation also reminded me that you could set these boot options by running MSCONFIG, inside Windows, from the command line or from Start > Run. The first idea I got, from starting to read through that long Microsoft presentation, was that I had a lot of old, extraneous stuff in NTBTLOG.TXT that I didn't want to analyze, either by myself or with the aid of a program. So I decided to rename it to NTBTLOG.OLD, and then I rebooted. I figured I'd have one go-round with Normal Mode, and then I'd come back into Safe Mode and see what my new, streamlined NTBTLOG.TXT might say. The guy in the Microsoft presentation, George Vordenbaum, said that NTBTLOG.TXT should capture that sort of information. Sure enough, back in Safe Mode, there was my new NTBTLOG.TXT file. But it looked like it had only the record of my reboot into Safe Mode, not of the immediately preceding effort to get into Normal Mode. Before fooling around with some analyzer program, I wanted to make sure of what we were analyzing. Looking again at the Microsoft presentation, although I don't think they said it in so many words, the idea seemed to be that the system would always log Safe Mode boots, but you had to choose the Enable Boot Logging option from the F8 menu, shortly after rebooting, and then make your way back toward Normal Mode, and finally wind up back in Safe Mode after crashing, where you could then analyze the appropriate parts of NTBTLOG.TXT. I had assumed that boot logging was already enabled, and that this was why I already had a NTBTLOG.TXT file. So now I renamed my NTBTLOG files, thus far, to be NTBTLOG.OLD1 and .OLD2, and rebooted, proceeding with F8 etc. as just described. Well, it seemed I still did not have the concept. NTBTLOG.TXT and NTBTLOG.OLD2, which I had created just before I rebooted and said Enable Boot Logging, were identical to one another. It looked like I was still logging nothing other than the re-entry into Safe Mode. It seemed like I did understand what the Microsoft guy was saying; but it wasn't turning out as he said -- unless, of course, we were indeed logging Normal Mode, and only Normal Mode, all along. To determine whether that might be the case, while I was in Safe Mode I deleted NTBTLOG.TXT and then synchronized my wristwatch and the computer's system time; and then I rebooted and made note of when the thing tried to enter Normal Mode and when it returned to Safe Mode; and then I compared those times against the time shown at the top of my new NTBTLOG.TXT. The system began to boot Normal Mode at about 1:58:01 PM, and returned to Safe Mode at about 1:58:45 PM. The time shown at the top of the new NTBTLOG.TXT (and the only time shown in that file), back in Safe Mode, was 1:58:44 PM, and Windows Explorer reported the file creation time, for NTBTLOG.TXT, as being 1:59 PM. From this, I concluded that I was seeing only Safe Mode information, and was not yet successfully logging Normal Mode boot efforts. That Microsoft presentation also said I could look at Device Manager (Start > Settings > Control Panel > System > Hardware > Device Manager), while I was in Safe Mode, and see if it gave any hints as to possible problems. It showed a yellow circle with an exclamation next to my APC battery backup. I figured this was just because Safe Mode was not able to communicate properly with the battery backup; but just in case, I unplugged the USB cable leading to the battery backup. That eliminated the yellow exclamation circle from Device Manager. Then I resumed my search for a way to log the details of the system's attempt to boot into normal mode. Something I hadn't realized, that emerged as I continued reading that Microsoft presentation, was that you could install Recovery Console on your hard drive, so that it wouldn't be necessary to boot from the CD. To do that, it sounded like you would boot into Windows, open a command window, navigate to the I386 folder on the WinXP CD, and run WINNT32.EXE /CMDCONS. I didn't experiment with this now, however. There were more details -- about how doing this would change your bootup, for example -- that I didn't want to get into. Another Microsoft page informed me about Event Logs. These, however, seemed to be available only within Normal Mode, and weren't really on point. Another Microsoft webpage made it sound like the boot log option was available only for boots into Safe Mode, though that didn't explain why the system automatically headed for Normal Mode as soon as I selected the boot log option. Yet another Microsoft page stated unequivocally that boot logging definitely recorded both Normal and Safe Mode attempts. So I tried again, selecting the Enable Boot Logging option. Again, this gave me a NTBTLOG.TXT that definitely appeared to contain only a record of the Safe Mode boot. Without deleting that NTBTLOG.TXT, I rebooted again, hit F8, did not select the Enable Boot Logging option, and went straight into Safe Mode. I looked again at NTBTLOG.TXT. Now it was a longer file, consisting of the records of two bootup attempts, and both looked pretty much the same. I concluded that the Enable Boot Logging option was not enabling boot logging of my attempt to boot into Normal Mode, and that Safe Mode was logged automatically. There was another way. You could enable boot logging so that it would always happen. Microsoft said so. To find out how, I went into Start > Help and Support Center and did a search for "boot log." But I didn't initially find what I was looking for. Instead, I found something there that seemed likely to be useful for troubleshooting purposes on an ongoing basis. It said you can set Windows to log what happens if the system stops unexpectedly -- not only at bootup, but anytime, apparently. They said you can save the relevant information in three memory dump formats: small, kernel, or complete. It seemed that, if I wanted this available on an ongoing basis, I would need to maintain a paging file on drive C, which normally I didn't do because I'd heard you get better performance by putting your paging file on a drive other than the program drive. The sizes of the required paging files varied quite a bit. For a small memory dump, they would need a paging file of as little as 2MB. For a kernel memory dump, the size was supposedly going to be somewhere between 50 and 800 MB. And for a complete memory dump, I would need a paging file at least slightly larger than the total of all physical RAM, which would mean between 2.7GB (if they were talking about the maximum that 32-bit WinXP could recognize) and 4GB (if they meant all installed RAM). I figured that a tiny, 3MB paging file would not harm system performance much -- I assumed that a drive that small would fill quickly, and therefore much of the contents of RAM would continue to be paged off to some other drive. Also, small was better: if I was going to have to analyze this myself, I didn't want to be dealing with gigabytes of system data. So I went into Control Panel > System > Advanced > Performance > Advanced > Virtual Memory and selected drive C. I specified a Custom Size with 3 (MB) as both the initial and maximum size, and then made sure to click on Set before okaying out of there. I didn't elect to restart the system yet. Instead, back in XP's built-in Help and Support Center, I saw that I had to do something else to enable this logging process. In Control Panel > System > Advanced > Startup and Recovery, I had to select the desired options. I was pleased to observe that the options I was most concerned about were already set: Write an event to the system log, and make it a small memory dump. I decided to shut off the option to Automatically Restart, since I had found it irritating to think that my system might be rebooting itself fifty times while I was temporarily distracted. The system was also already set to write the small memory dump; it would be going to a place called %SystemRoot%\Minidump, where I assumed %SystemRoot% meant C:\. I wasn't finding that any Minidump place presently existed, which made sense, considering that I hadn't had my pagefile on C for the dump. While I was there in that Startup and Recovery dialog, I clicked on the option to "edit the startup options file manually," and, lo and behold, here we had the boot.ini file. So if I could just figure out what to add to it, it seemed that my next reboot might have information about the Normal Mode crash in two separate locations: in Minidump, and also in NTBTLOG.TXT. For guidance on boot.ini, I turned to Microsoft again, for an indication that I could add the /bootlog parameter to the WinXP line in boot.ini. My guess, then, was that the thing should look like this (allowing one line from boot.ini to break into two, here, for purposes of readability):

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP Home Edition" /fastdetect /bootlog
I noticed that my boot.ini also used a parameter that read /noexecute=optin. This, it seemed, was a security item that didn't relate to the present issue. I clicked OK and I got a dialog box telling me that I couldn't get administrative alerts unless I had the Alerts service running. I decided I didn't care about an Alerts service, I just wanted to be able to check Minidump or NTBTLOG.TXT in the event of a crash. So I unchecked the box for administrative alerts and was able, this time, to okay out. I deleted the cluttered old NTBTLOG.TXT file, rebooted, and waited for the result. To my disappointment, the system did reboot after freezing, on its way to Normal Mode. But the idea of it not rebooting had posed another approach. Instead of letting it try to reboot into either Safe Mode or Normal Mode, I inserted a Knoppix live CD and booted into that flavor of Linux. I used Knoppix (I could just as well have used an Ubuntu or other Linux live CD) to see if I could locate Minidump or NTBTLOG.TXT. Then I remembered that I had disconnected my other hard drives, so I didn't have a FAT32 partition available to copy them to, even if I did find them, though I could have used my floppy drive if they were small enough. As it turned out, there was no NTBTLOG.TXT file in C:\Windows. So I was still not getting a log of what was happening at boot. It seemed that both methods of creating an NTBTLOG.TXT file, to record the process of booting into Normal Mode, were failing -- or else the system was not even really getting far enough along to commence that process. There was, however, a Minidump folder, containing two Mini*.dmp files. In place of the asterisk, the names contained the date of creation. The dates in question (as confirmed by the file details shown, there, in the Knoppix file browser) were more than two weeks old. So apparently that part of the process was not working for me now, either. (I had no idea why there would have been two files, created on one date two weeks ago, while all the other crashes of recent weeks would have been ignored.) One site said that no NTBTLOG.TXT was created, in their case, because the system was hanging before it could get far enough into Safe Mode to write the file. I had already determined that the system, trying to boot into Normal Mode, would not even add lines to an already existing NTBTLOG.TXT. The solution, in their case, was to flash the BIOS, so as to correct a problem with something called the ESCD, stored in the BIOS, that would allocate system resources. I had already flashed the BIOS on this motherboard with the latest update; but I had still noticed a weird CMOS error if I left the machine powered down. So a bad motherboard was one possibility. It seemed really unlikely, though, because this was the second of these motherboards I was having this problem with, and as noted above, other users were overwhelmingly happy with it. Besides, unlike that other situation, I *was* able to boot into Safe Mode. Another webpage suggested that, in Recovery Console, I should have used, not only FIXMBR, but also FIXBOOT and BOOTCFG /REBUILD, in that order. Apparently I was then going to be asked whether I wanted to add this revised installation to the boot list and, if so, what I wanted to call it. It looked like I might also be overwriting some of the boot.ini changes I had just made. I decided to give it a whirl. Fortunately, the BOOTLOG /REBUILD part told me what had been there before (e.g., that my "OS Load Options" had included /bootlog, as described above), so I just had to retype what was already there. But I guess if your previous installation had been really trashed, you might have to have a brain at this point. I guess it would have helped me, too, because somehow I wound up with two options instead of one, when I rebooted, and both were called Microsoft Windows XP Professional. I chose the second one, reasoning that it was probably the second one added to the list, and I indicated that I wanted to proceed to boot Windows normally. But that didn't work: the system crashed as usual and rebooted. So I tried the first one. Same thing. So now I had two nonworking WinXP options, instead of just one. (On closer examination, I realized they were not the same after all. In a flashback, I had called the new one "Microsoft Windows 98," not XP. So now I was able to see that the new one had been added as the first in the list, not the second.) I went back into Recovery Console -- but then that seemed unhelpful because, according to a Microsoft webpage, the command I wanted (BOOTCFG /DELETE) was not even available in the Recovery Console. Sure enough, back in Safe Mode, I opened a command window and typed BOOTCFG /? and got a whole list of possibilities, including /DELETE. The proper syntax in my case, as I saw from the Microsoft webpage, was bootcfg /delete /id 1. I entered that, did another BOOTCFG /QUERY to make sure, and exited from the command window. I found somebody else who seemed like they had the same problem I had been having. In that case, it sounded like Windows automatic updates had caused some problems. One approach tried there was to disable various "services" in WinXP and see if that solved the problem. It sounded pretty time-consuming -- the list of services provided by BlackViper was pretty long -- but it was either that, or return all the hardware and return to my previous system (I hadn't yet sold my motherboard or other components), because at this point I really was not too sure where the problem might be. When I hit Start > Run > services.msc, I found (by quick count of pages) 114 services on the machine. Fortunately, in what BlackViper called a "bare bones" system, the vast majority would be set to "disabled." (There was no telling what to do about third-party services, other than to assume that Windows, in barebones format, could get by without them, i.e., that they could be disabled too.) I followed BlackViper's advice on how to create a hardware profile, so that my present services settings would be preserved, in case I wanted to come back to my starting point. But BlackViper also warned that disabling a service in the General tab, within Services (right-click on a service and choose Properties), would permanently disable it for all profiles -- that, instead, you should use the Log On tab. So I did that, disabling all of the services that BlackViper designated as "Disable" in the bare-bones list. I noticed that the Startup Type information did not change, on the main Services screen, as a result of my efforts; I assumed that those changes would be implemented only after rebooting. It occurred to me, as I was doing this, that the next step (assuming a successful barebones boot) would probably involve coming back down this list and re-enabling some of these services and trying another boot, and so forth, until I had narrowed down the culprit(s). I decided to save a different profile for each screenful of services that I disabled. After doing the first screen, I saved a profile called Bare Bones 1, and so forth. So then I would start by booting the extreme barebone profile, which would be Bare Bones 5; and if that worked, I would just reboot and try Bare Bones 4, and so forth, working back toward Bare Bones 1, in which I would have disabled only the first screenful of services. This took maybe 20 to30 minutes, and then I rebooted. On reboot, after the BIOS loaded, I got a Hardware Profile/Configuration Recovery Menu. I chose Bare Bones 5 and hit Enter. And guess what? The system choked and rebooted, same as before. Even with the maximum number of services disabled, I still had a problem. On reboot, I chose Original profile and then chose Safe Mode. I wasn't sure if I would need those Bare Bones profiles anymore, so I didn't delete them right away. At this point, I found a helpful article on They laid out a nice series of troubleshooting steps. Doing an "in-place upgrade reinstallation" was step no. 7 on their list. I thought that this process might at least help me determine whether I had a hardware problem and, more specifically, which piece of hardware might be implicated. Certainly it made sense that I could test more things if I had a working Windows installation than if I didn't. Yet it was not clear, to me, exactly how I would proceed to test the hardware, even if I did have a working system. As mentioned above, I had previously found and used Microsoft's Windows Memory Diagnostic (WINDIAG) to test the RAM. But in my software and hardware installations, and my visits to the manufacturers' websites, I had not found any comparable diagnostic program to test the CPU, motherboard, and/or video card, and I now revisited some of those sources to make sure. It seemed that my options, at this point, were (1) to do the reinstallation and (2) if I still had crashes that I could not pin down, to return the CPU, motherboard, and video card to Newegg, perhaps after buying replacements that I could cross-test. This made me think that surely some third-party supplier must have developed diagnostics that would verify that a system was able to run Windows XP properly. Microsoft was a good first place to look, especially since I had seen that they had devised a memory tester. I found that they offered an Offline Crash Diagnostic (in their document KB923800). I found several other diagnostic tools as well. First, however, Andrew K's Diagnose XP website stated that viruses are the No. 1 cause of system problems and can be responsible for any sort of symptom. This was interesting because now I did recall that I had been running Ad-Aware 2007 and another malware checker, while working on something else, and both of them had frozen before finishing. So now, in Safe Mode, I ran what security programs I could, including smart (i.e., not full) scans in Symantec Antivirus, Spybot Search & Destroy, and Ad-Aware. Also, I downloaded and ran, from the link on Andrew K's site, the CCleaner program. This appeared to be a dangerously powerful program, capable of uninstalling many of your programs with one click. The options I used were: Run Cleaner with default settings in the Windows tab of the Cleaner section; Scan for Issues in the Issues section, and then Fix Selected Issues (all, by default), and repeat until all were gone. Andrew K also pointed me toward the Trend Micro Online Virus Scanner, which I could not use in Safe Mode because I was not able to go online, and the Trend Micro Sysclean Package, including its accompanying pattern file, which I did run. Sysclean found drive errors, to which (of course) access was denied (but which I planned to address on reboot), but it found no viruses. I noticed that Sysclean was not listed on TrendMicro's list of free products, which included HouseCall online virus scanner, HijackThis (which I had often seen cited as a system analysis tool on various webpages), TrendProtect (which I planned to install, in both Internet Explorer and Firefox versions, but could not do so while in Safe Mode). It seemed that Trend Micro had several other interesting paid programs, such as Damage Cleanup, but I did not pursue those now (but then I noticed, in the log file created by Trend Micro Sysclean after it had completed its run, that it had included the "Damage CleanupEngine"). I didn't use the free Transaction Guard, which seemed designed for security on public computers. I noted, but did not pursue, the ICSA Certification link that Andrew K provided; I would have been more interested in that if I had been using an antivirus program that did not have Symantec's antivirus reputation -- though I was a bit concerned about the indication that an antivirus program is certified if it will "Detect 90% of the ICSA Labs Virus Collection." I realized that might be all that one could feasibly expect; it just alerted me to the apparent fact that the antivirus programs don't necessarily try to do it all. I also didn't explore Trend Micro's several free-trial programs. Continuing with other antivirus and antispyware programs cited by Andrew K, I also ran (in addition to Spybot and others mentioned above, already present on my machine) CWShredder, to counteract a specific web browser problem, but it found no errors. I was not able to run its "Test Your System for Other Errors" option because I could not go online in Safe Mode. Microsoft Windows Defender found no errors. I ran the Microsoft Java Virtual Machine v1.1.4 Removal Tool and accompanying registry fix. I couldn't install the Sun Java Virtual Machine or run its test page because it tested the machine on which I was trying to download, and found itself to be present there already; but that was OK, because I was pretty sure I had already installed it on the problem machine anyway. Another Andrew K website that I planned to explore when I could get back online was Driver XP, for the latest drivers for my hardware. I will say, in passing, that dealing with all this security software made me feel that Windows was ridiculous. I did wonder whether I shouldn't take another serious try at making Ubuntu work. But for now, I thought that at least I ought to be able to get a basic Windows XP installation up and running. I was sure there would be times when I would need it, whether in its own right or as the source for a virtual machine that I would run in VMware. Andrew K recommended using PC Wizard to identify your specific hardware, so that you could be sure of getting the right drivers. I downloaded and ran PC Wizard because it was also supposed to test your hardware. But I got "Error initialising peripherical driver. Err : 1084." I was not able to figure out what that meant, though it did make me think that there was some kind of driver or hardware issue even at the Safe Mode level -- which wouldn't have been surprising, considering that my system, with the motherboard that I had returned to Newegg, had crashed in Safe Mode and even in Ubuntu. Andrew K included a rare reference to a commercial program, Steve Gibson's SpinRite ($89), with a description that made it sound like a very useful thing to have. In Andrew K's writeup, SpinRite could recover data from failed hard drives of all types (even from a TiVo), and could also create a bootable CD or jumpdrive. Since it was available for immediate download, I decided the important thing was to remember where to find it, if I did need it. Another data recovery program that Andrew K recommended was CDCheck, which I thought I had probably better try to use in the future when burning CDs and DVDs (also apparently useful on hard, floppy, and flash drives), so as to verify that they were *really* created properly before deleting the source data that I *thought* I had put onto them (having encountered a couple of defective CDs and DVDs along the way). The Microsoft Offline Crash Diagnostic mentioned above was another option at this point; but when I tried to install it, it said that installing in Safe Mode was not recommended unless you couldn't start your system in Normal Mode. That was applicable here, but I was concerned that this meant that installing in Safe Mode might create new problems. I decided to defer using this diagnostic program until I had used up my other options, with a note to myself to make sure to install it, in any case, if I could ever get back to Normal Mode on my troubled computer. I had not run the Maxtor hard drive diagnostic on the one drive that remained connected to my machine. I had run CHKDSK and other Windows programs often, however, so I didn't really think the problem was with the drive. Nonetheless, I was going to download the Maxtor diagnostic, from the several helpful hard drive diagnostic links that Andrew K provided, but it turned out that Seagate had acquired Maxtor. So now the diagnostic program they were recommending was SeaTools. I already had a recent copy of that on a bootable CD, so I rebooted and ran its Short Test and also its Long Test. Both passed. For RAM testing, Andrew K recommended Memtest86+. I considered it possible that I might have had a memory problem that had escaped WINDIAG, so I downloaded the ISO, burned the CD, and rebooted. It automatically went right into its default test, so I let it go for a while. But since I hadn't done any tests at all on the CPU, I was not as interested in running another memory diagnostic. What I really wanted to run was Prime95, which Andrew K described as "a good stress test for the CPU, memory, L1 and L2 caches, CPU cooling, and case cooling. The torture test runs continuously, comparing your computer's results to results that are known to be correct. Any mismatch and you've got a problem! ... [S]elect 'Torture Test', then 'Ok', let it run for a minimum of one hour, preferably overnight for a thorough test. On a working stable system this test should never fail. Any errors or failures indicate a hardware problem. The exact cause of a hardware problem can be very hard to find. If both the Harddrive and Memory Diagnostic passed then the most likely causes are Overheating, a faulty Mainboard, a faulty CPU or a faulty Power Supply." I ran Prime95's Torture Test overnight and beyond, using the small FFT setting, which looked most likely to test the CPU and other components rather than RAM. Final report: "Torture Test ran 21 hours, 16 minutes - 0 errors, 0 warnings." The Microsoft Offline Crash Diagnostic, above, seemed like my last option before doing a reinstall. First, though, I wanted to be sure of the situation, and if possible I wanted to install that diagnostic in Normal Mode. So, once again, I went through the whole process of FIXMBR followed by CHKDSK /R for each of the four partitions on the one drive that I now had connected. Then I rebooted, to see if it would go into Normal Mode. This had worked in the early days of my problems with this new hardware and/or software (i.e., the install-from-scratch that I had done with WinXP Pro a few weeks earlier), but then it seemed like it had stopped working, and at this point I did not precisely know where the matter lay. I had had crashes sometimes in Safe Mode and even in Ubuntu, so it seemed like there had to be a hardware problem. But I wasn't actually finding one. So when CHKDSK was done, I tried rebooting into Normal Mode. No dice! A freeze and reboot, early on. Trying something different, I hit F8 after the BIOS loaded and chose the Debugging Mode option. Same thing. So in Safe Mode, I tried installing the Microsoft Offline Crash Diagnostic. It seemed like it installed -- it said it was successful -- but I didn't see any icons in my Start > Program menu. The download instructions said I might have to reboot, so I did. Still nothing. About this time, some things began to change in my handling of this problem. One change was that I eliminated some distractions that may have kept me from seeing this problem clearly. Another, which was probably related to the first, was that I think I got past the point of assuming that I could just click on some button, or run some program, and that would solve my problems. Maybe it was because I had pretty much exhausted the software repair options, other than reinstalling. It had been a while since I had done hardware troubleshooting, and it felt like only now that I began to take some steps that more experienced or warmed-up people might have gone to right away. So it was only now that I started working with tech support for each of the components in question. I felt a little foolish about this. I think, in part, that my experiences with tech support had taught me that it was in my interest to be totally on top of the problem before calling. I'd had enough experiences of having technicians tell me to uninstall or change something that didn't help at all, but then took me hours to get back to working condition. If nothing else, at least I could take some comfort in seeing that apparently a number of other people were approaching the problem in roughly the same way as I had done. For whatever reason, however, I now turned that corner. I called Intel's tech support at the number shown on the Newegg website (916-377-7000). My call was at 1:38 PM. I wanted to know if they had any diagnostics that I could run. There didn't seem to be any information along those lines on their website. I got a human almost immediately. He took down my name, e-mail address, and phone number, and gave me a case number. At 1:42 PM, he forwarded me to "the next available agent," i.e., a technician. Two minutes later, I was speaking with Paul, the technician. Paul had a hellacious accent, but whatever. By 1:51 PM, he had checked the MSI website (not finding my motherboard on Intel's approved list) and had confirmed that, according to MSI, the E4300 processor was supposed to be compatible with that mobo. Therefore, he said (given that I told him I had done extensive memory diagnostics and had a good power supply), it pretty much had to be a defective processor. He wanted me to give him some "markings" from the CPU (presumably, whatever letters and numbers were on it). I said I couldn't now, I'd have to take the fan off it first. He said fine, just call back. When I asked if there was an e-mail alternative, for purposes of my scheduling convenience, he said I could e-mail the info to They tried to have a 24-hour maximum turnaround on e-mails, he said, but they would probably be much faster than that. He had told me there wasn't really a diagnostic program, just their Processor Identification Utility. Otherwise, I found very limited troubleshooting guidance on Intel's support webpage for this processor. Anyway, after CHKDSK was finished, I took the fan off the processor, and here is what I ultimately gave to Intel:
As you requested, the information from the top of the defective CPU is as follows: INTEL (M) (C) '05 INTEL (R) CORE(TM)2 DUO 4300 SL9TB MALAY 1.80GHZ/2M/800/06 Q703A370 (04)
I realized that I should have been contacting MSI tech support likewise. From them, I got a Troubleshooting Guide whose section on stability problems instructed me to verify that my system's temperature was not exceeding the recommended level. In my American Megatrends Inc. (AMI) BIOS, the current CPU temperature was shown under "H/W Monitor" (i.e., hardware monitor). It showed a CPU temperature of 53 degrees Celsius. I wasn't successful in finding out, at the Intel website, whether that was an appropriate temperature for this CPU. In several discussions at Tom's Hardware, however, it sounded like 65 degrees C would be the maximum. A temperature of 53 with no load seemed too high. I saw where someone else had a temperature of only 40 while the CPU was idling. I wondered whether the CPU might actually get less cooling (e.g., less directed airflow) when, as now, I had the case open to facilitate looking inside. MSI had posted an FAQ that seemed to say that Windows would report a lower temperature than I was getting in this reading in the CMOS setup utility, because Windows would put the CPU into a low-power status (keeping it cooler), while the setup utility would not. I made a note to check the temp, if I could figure out how, when I got back into Safe Mode or Normal Mode, and see how it looked then. But temperature did not appear to have anything to do with my initial difficulties in booting stably. Later, I realized that one other possible (likely!) source of excess heat was that I had not been able to secure the stock cooling fan, supplied with the E4300 CPU. The connectors that were supposed to attach the cooler to the motherboard were ridiculous. They were designed poorly and they just did not work. The advice was to install it before putting the mobo in the case, because apparently a fair amount of pressure was required to do it right. A number of people seemed to advise getting rid of the stock cooler and buying a third-party product instead: it would be cooler, quieter, and better secured. But it looked like the most highly recommended one, an Arctic Freezer 7 Pro, would cost $40. (Intel had some others on a list.) At that rate, there was some opinion to the effect that I could have gotten a faster E6300 or E6400 CPU and could have used its stock cooler, as long as I wasn't overclocking -- or could have bought the E4300 OEM (original equipment manufacturer, i.e., not in a retail box) and added my own fan. It wasn't clear to me whether the E6300 or E6400 used the same flimsy way of attaching the fan and heat sink, though I feared they might. A discussion at Tom's Hardware indicated that the E4300 was perfectly respectable, especially if a person wanted to overclock it -- in which case a third-party cooler was highly recommended by multiple sources. Then again, one tester found that the Arctic cooler didn't make much difference. (Upon reviewing his photo and the many praises of the Arctic cooler, I decided that the problem must have been in his test setup.) For reasons of noise and to have a secure attachment (any cooler, attached well, was better than having essentially no cooler because of an unreliable attachment!), I decided to go ahead and get the Arctic cooler. At about the same time, I noticed something interesting on the MSI webpage pertaining to my motherboard: "Due to the High Performance Memory design, motherboards or system configurations may or may not operate smoothly at the JEDEC (Joint Electron Device Engineering Council) standard settings (BIOS Default on the motherboard) such as DDR2 voltage, memory speeds and memory timing. Please confirm and adjust your memory setting in the BIOS accordingly for better system stability." In my BIOS, those settings were under Cell Menu > Advance DRAM Configuration > Memory Timings. MSI recommended using the automatic setting, which was the default and was what I had been using; but they said that, if that didn't work, you should consult the specification on the sticker on the actual RAM DIMM module or in the RAM manufacturer's literature. According to the webpage for my Crucial RAM, the settings were "DDR2 PC2-6400 • 4-4-4-12 • Unbuffered • NON-ECC • DDR2-800 • 2.2V • SLI-Ready • 128Meg x 64." Crucial had said that this memory was guaranteed to work in my system; also, I think I must have been assuming that only overclockers would be wanting to change the settings. Now, however, as I looked at the BIOS, I saw the following items listed, when I selected the Manual memory timings options; and according to a Techware Labs webpage, these items had the following meanings: tCL: CAS Latency tRCD: Row Address to Column Address Delay tRP: Row Precharge Time tRAS: Row Active Time tRRD: Row Active to Row Active Delay tRC: Row Cycle Time tWR: Write Recovery Time tWTR: Internal Write to Read Command Delay tREF: Refresh Rate CMD: Command Per Clock I didn't see information for all of these settings in the Crucial specifications just cited. One clue came from the Techware Labs webpage, which said that all but the first three (i.e., tCL, tRCD, tRP) plus CMD were under the Advanced memory tab of the system they were discussing. But that seemed to be not quite right. A Tech PowerUp forum posting explained, more clearly, that the first four in the preceding list are the ones you would see in memory ratings, in the order of CAS-tRCD-tRP-tRAS. The example they gave was 2.5-3-3-8. Posts in Legit Reviews Forums confirmed that the order was CAS-tRCD-tRP-tRAS (e.g., 2 - 2 - 2 - 5), and that all the other settings should be left on Auto. Another post there said, however, that you should run Memtest86 afterwards to make sure that your manual settings would fly. Since I had already run Memtest briefly, and WINDIAG extensively, I suspected that maybe the automatic settings had been fine after all. I had noticed, in passing, that one person had even seemed to say that the automatic feature might back off to a more conservative setting that would match what the RAM in question could actually do, as distinct from its apparently overoptimistic rating. But I went ahead and changed those four values to the 4-4-4-12 values specified in the Crucial settings. My other concern was that these changes didn't account for the voltage setting, which seemed, to me, to be the one other Crucial memory specification that might call for adjustment in the BIOS. I found the Memory Voltage setting, all right, but it was greyed out with an [AUTO] setting. I looked for a way to remove the greying, so that I could change memory voltage to 2.2V, as Crucial had specified, there in that screen within the AMI CMOS Setup Utility (ver. 2.61). Eventually, I found an AnandTech post that explained how the utility worked. It didn't work for the Memory Voltage setting -- not yet, anyway -- but at least for the CPU Voltage setting, I found that I could raise it up or down, not by typing a value or hitting Enter to open a list of options, but rather by using the plus (+) or minus (-) keys on the numeric keypad (i.e., not the row of keys, from 0 to 9, running across the top of the keyboard). Now the question was how to ungrey the Memory Voltage option so that I could do the same thing there. I tried changing the settings as shown on a PCStats page, but Memory Voltage was still greyed out -- for me, but not for them! Likewise on a Neoseeker webpage -- where both such webpages were talking about this specific motherboard. For some reason, apparently, I was not allowed to change the Memory Voltage, whereas other systems could do so. I posted an inquiry in a forum in Tom's Hardware and hoped for a reply. Later, I did get a reply in an Anandtech forum telling me to just ignore the grey and use PgUp or PgDn or the plus or minus key, and that worked. I set it to 2.2V and I was happy with that. Because of various crashes and whatnot, by this time my Windows installation had reached a point of being so confused that it wouldn't even talk to itself -- that it, it couldn't even boot into Safe Mode. It was trying -- the hard disk light was running almost constantly -- but it seemed to be stuck in a loop after loading MUP.SYS. So I restored the most recent disk image, from about a week earlier, and rebooted into Safe Mode. MSI's Troubleshooting Guide also suggested testing each RAM module separately, and testing each RAM slot on the motherboard. I had already done that with one module, and yet had still had random system crashes, but my previous test had not been with Memtest. So I installed a few items and shut the system down. I removed all but one memory module and rebooted into the Memtest CD. I ran that on one module in memory slot 1 for five hours, with no errors. I noticed, about this time, that Newegg had put a motherboard on sale in their "Open Box" category, which I think means that they got it back from a customer, tested it, and concluded there was nothing wrong with it; but it had been opened and used, so they could not resell it as new. The motherboard in question happened to be an MSI P6N SLI Platinum, just like mine. In fact, I suspected that it *had* been mine -- that I had returned a good board. I felt bad about the extra cost or loss for them or MSI, if that was indeed the situation. This did not guarantee that the board I now had was good; it just seemed to indicate that the CMOS error message that I would get on reboot, after shutting off system power, was a built-in bug (or "feature") that did not prevent the boards from working well for a large majority of other Newegg purchasers. (As it later turned out, Newegg did not receive the board I returned until some days later. I knew because they, in their estimable way, sent me an e-mail to let me know that the thing had just arrived at their place. So it was somebody else's mobo that was on sale that day.) MSI had almost no other FAQs about this motherboard. While I was revisiting their webpage, I confirmed again that this CPU was supported on this board. On their Compatibility Test Items page, I confirmed again that this Crucial RAM had not yet been tested, but I double-checked that Crucial said this RAM was guaranteed compatible with this mobo. Likewise, MSI had tested very few video cards, and their list did not include this one; but EVGA confirmed that they supported this Crucial RAM. EVGA did not seem to try, however, to provide a list of compatible motherboards. Finally, Corsair, maker of my power supply, confirmed that my motherboard was compatible with their product. I did not bother to confirm compatibility with hard drives and other components, which I was confident were almost completely interchangeable among systems. At any rate, with the week-old drive image restored, the system rebooted into Normal Mode without a problem. I downloaded a few updates and rebooted. This time, it gave me a SysTray error, whose details I didn't write down, followed by Runtime Error 216 at 51F2242C. Microsoft said this might mean my system was infected with a SubSeven Trojan virus. I reinstalled the remaining antivirus and antispyware programs described above (whose recent installation had been erased, of course, when I reinstalled the week-old drive image) and ran the whole collection of security programs now found on the computer. I also installed the Microsoft Offline Crash Diagnostic again, and once again I could not figure out whether or where it might have installed itself. I was just in the process of downloading these upgrades, scanning my files, etc., and then the system crashed. On reboot, I decided to focus on running the scans. It wasn't clear to me what had caused the crash, but for various reasons I had loaded Word, Acrobat, and other programs in addition to the malware scanners themselves -- I had gotten too excited about having the computer working again -- so it was hard to tell what might have caused the crash. I did notice that the system was being funky shortly beforehand, such as when it would not let me create a new folder in WinXP without opening an ephemeral dialog box for the Installer program. I thought the problem with the Microsoft Offline Crash Diagnostic might be that I had downloaded it on another computer and then tried to install it on the problem machine. Microsoft had a validation process; maybe I had to do the download and installation, both, on that machine. But then I read on in the instructions (RTFM) and discovered that the way to do it is to run ocadiagnostic.exe. I did that and, sure enough, there was a screen, welcoming me to Offline Crash Diagnostic for Windows XP. So I set up a shortcut to it for ease of future reference. (It was in C:\Windows\pchealth\helpctr\binaries.) I wasn't sure it was going to work too well, because the description said it depended upon the Minidump folder, and as described above, that folder still wasn't being written to. The thing gave me the option of uploading those two three-week-old crash files, the ones that did exist in C:\Windows\Minidump, to see what sense Microsoft could make of them. I was curious, so I said sure, upload them. Almost immediately, it gave me a Web Response link. I clicked on it, and of course that opened Firefox. I noticed, down in the system tray, that my FreeRAM XP Pro program was telling me that I had very little memory left (since I was still using just the one memory module). I wondered if that fact might have been related to the most recent crash. But the system didn't crash. The analysis from Microsoft read as follows:
Problem report summary Problem type Windows stop error (a message appears on a blue screen with error code information) Solution available? No What does this problem mean? Windows has encountered a problem it cannot recover from and it needs to be restarted Cause Unknown Computer symptoms A message appears on a blue screen with error code information (for example: 0x0000001E, KMODE_EXCEPTION_NOT_HANDLED) Additional steps for you to take Please continue to send problem reports so analysts at Microsoft can study and try to correct the problem as quickly as possible
So that wasn't too helpful. But I liked the concept and -- who could say? -- if the Minidump folder miraculously began to be populated with more recent crash error data, I would continue to be interested in this program's reactions to them. I also got an e-mail back from Intel. Here's what they said about the idea that I could have them ship a replacement to me right away, instead of shipping my apparently defective CPU to them and waiting for them to send me a new one:
Thank you for contacting Intel(R) Technical Support. We do have a cross shipping service, however there is a fee of $25 (twenty five dollars) only for shipping and handling. If you agree with this payment you will need to contact Intel(R) Technical Support again since the cross shipping service is provided only by phone. If you prefer not to pay the $25, than we can process the order by email as an standard warranty replacement, meaning that you will need to send us first the defective processor and as soon as we receive the defective processor we will ship out the new processor and it will take from three to five business days for you to receive the new processor. Also we are missing two lines located on top of the processor on the edge of it, we need this information in order for us to complete the replacement processes, if you have any problem finding the processor markings please visit the following website to see an example of the processor markings: You can provide this number when you call in to request the cross shipping replacement or you can provide us the missing information by replaying to this email in case you prefer the standard warranty replacement. Your email case number is Please do not hesitate to contact us again if you need further assistance. Sincerely, Adolfo S. Intel(R) Technical Support Intel(R) Processor Support Web Site: This email was cleaned by emailStripper, available for free from
They didn't supply their phone number on their e-mail. Fortunately, I had been composing this post, so despite the chaotic nature of my workspace because of this computer crash, it was easy for me to find it in the words written above: 916-377-7000. I couldn't call yet; I was still doing virus sweeps. The virus sweeps found quite a few objectionable items, though only one or two that looked potentially serious. I had been concerned that sometimes the ZoneAlarm icon was not appearing in the system tray. I wasn't sure of the reason. I always had antivirus, firewall, etc. software running. By the time the sweeps had finished and I had cleaned out the objectionable stuff, I had decided how to proceed with Intel. Since I had to dismantle the computer somewhat to give them the remaining numbers from the CPU, I decided to run a little experiment. Before leaving Windows, I renamed my hardware profile (as described above) and made a copy of it. I called the first one Core2Duo, because that was the kind of CPU I had in the system now, and I called the copy P4, because ... you know. I also told Windows not to proceed with a profile until I selected one. Then I took out the entire motherboard and replaced it with the old one, which still had the fan and CPU and memory on it. I had been keeping it just in case I needed it. I set aside the new MSI motherboard, processor and all, preparatory to sending it back to Intel, and inserted the old Gigabyte GA-8IG100MK that had been running fairly stably before I removed it. I now saw one reason why the fan had not wanted to become mounted properly: one flimsy little plastic wing, or tab -- whatever -- had failed to go into the hole, bending off to the side instead. I rebooted the system with the old Gigabyte motherboard, using the old video card etc. I was glad to do so: the system had crashed once again, this time doing nothing more than moving files from one directory to another. I then spent several hours working on something else, but occasionally going to that computer to click or type something, so that the system could install various drivers and acquaint itself (that is, its Gigabyte/Pentium 4 self) with the hardware I had connected to it. In all this process, I did not have any of the random crashes that had been such a feature of life since I got the new motherboard, processor, and RAM. This little experiment tended to support the belief that the problem with this system was primarily a hardware problem. So now I just had to wait for Intel to replace the CPU. Actually, it wasn't quite that simple. Installing the Gigabyte mobo brought its own issues. One, mentioned above, was that, nearly every time I clicked on some program or tried to run some command, I got a dialog box (even if only for a fraction of a second) labeled "Windows Installer" that would inform me that the system was "preparing to install" something. One poster offered the following diagnosis:
The reason that windows installer is coming up in this case is that the user has a corrupted install that has installed a shared component. Most likely comctl, or oleaut32. The other programs that are triggering the repair are likely just calling into a shared COM object and that is what is triggering the repair. To figure out which installer is failing you have to look in your windows "Event Log". This is a log of activity on your windows NT based OS. To get to the event log right click on "My Computer" and select manage. In the list on the left you'll see "Event Viewer" Select that and then select "Application". If you sort by "Source" You'll see a huge number of MsiInstaller entries. Looking through those entries will tell you who the culprit is. If you either uninstall and re-install the offending software or MsiZap the offending software you'll probably be back in buisiness.
The system was running really slowly, despite my best efforts in installing drivers for the Gigabyte mobo. I took some of the steps described above -- fooling around in Safe Mode, defragmenting, checking for errors in Disk Management, possibly running SFC (can't remember) -- and I wound up with a basically functional system. Somehow the Windows Installer issue did fade away in this process. If it hadn't done so, I had just found one or two more websites that seemed likely to be helpful in that effort. But now I had a new issue: a BSOD (which was, as always, too fast for me to read) and a system reset! All of my new stuff was out. I was using strictly the old motherboard, old CPU, old memory ... ah, but I still had the new power supply inside the case. The power supply was the popular and capable Corsair HX Series CMPSU-620HX 620W. It was a monster. I probably didn't need a 620-watt power supply, and I was told that the larger one would not necessarily adjust its power consumption or noise level to be like a smaller power supply, in those instances when its full potential was not being tapped. Even with 4GB of RAM and four hard drives, it seemed like overkill. But it was a Corsair. Anyway, I could see no other culprit, so I returned it. In its place, I put my old power supply, an Antec Truepower 2.0, which had worked quite well for quite a while. So now, on the hardware side, I had completely reverted to my system as it was before the attempted upgrade. On the software side, I was still trying to run the new XP Pro installation. But it was not working. It would work OK in Safe Mode, but I was getting virtually no responsiveness in Normal Mode. For example, I did manage to get a command window to open; I typed SFC /BOOTONCE, and it did run SFC on reboot; but then the SFC dialog just sat there, not even starting. I was thinking about trying Fred Langa's suggestion to create a bootable WinXP thumb drive, using BartPE. But I really just needed regular access to my computer. So I opted for Intel's $25 service -- which, as it turns out, meant that they took my credit card number and promised that I would receive, the next day, a replacement CPU and a prepaid shipping label to use in returning the old one to them (which they wanted to receive within 30 days). The next day, sure enough, I had a replacement Core 2 Duo E4300 processor, with a note telling me to return the old one within 10 days. Some of Intel's communications had said 30 days. It didn't matter. It would be in the mail as soon as I could manage. The first step was to see whether it had indeed been the processor. I had to reinstall the putatively defective Corsair power supply -- its replacement would not be arriving for days -- because my old Antec didn't have an EPS plug. My new Arctic cooler had arrived at the same time, and there the joke was on me, because it attached to the motherboard with the same kind of connector as on the stock Intel fan. Oh, well. I could only hope that it was quieter. I discovered a couple of things about those little connectors, in the process of mucking around for fifteen minutes with what should have been a simple operation. One is that you needed to inspect them yourself to figure out how they work. The instructions -- from Intel, and also from Arctic, were backwards. To tighten them, you had to twist them clockwise, just as you would twist any ordinary nut or screw. Also, before you could tighten them, you had to push them down, not merely to get a good connection, but also to lengthen the shaft of the thing. And when you twisted them, you were supposed to just use your fingers. Yes, they had a slot in the top, as if to invite use of a screwdriver; but using a screwdriver would merely increase the likelihood of slipping and rupturing some tiny electrical connection on the vulnerable motherboard lying beneath. Finally, when screwing around with all this, you had to make sure not to smear the thermal paste, which they kindly pre-applied to the bottom of the cooler. In short, once I had carefully tightened down the motherboard and attached all the other connectors, so as to minimize the amount of screwing-around I would need to do with my static-sensitive CPU and RAM in place, I was obliged to dismantle it all, take the motherboard completely out of the case, and find a nice, hopefully not staticy tabletop where I could see this thing close-up and finally get the cooler attached to the mobo. I had been planning to give the Idiot Connector of the Year award to the people who designed those SATA hard drive connectors that fall off when you breathe on them, but now I could see I might have to reconsider. Of course, once I got the motherboard properly positioned in a vise on my workbench, where I could crank down on it with due force, I was able to see that this attachment was actually quite simple and logical, and after that (assuming my antics had not mini-lightninged a chip into dysfunctionality) everything went smoothly. I realized that, from another perspective, I was the idiot; but from the viewpoint of someone who has been putting coolers on PC CPUs for nearly 25 years, the natural thing was to try to install it while the motherboard was securely fastened inside the case. This time around, when I was reconnecting the Corsair 620W power supply, I did one thing differently. The MSI motherboard had come with a little clip covering four of the eight mini-sockets on the EPS 12V connector. I had taken that as a hint that I should preferably use a four-pin rather than an eight-pin plug. The power supply happened to have one of each. Now, however, I checked the power supply specifications and saw that only the eight-pin plug was a proper EPS connector. So it was possible (though unlikely, I believed) that all of my problems stemmed from not using an EPS power source for that connector on the motherboard. We would soon see. I wasn't sure, at this point, what the purpose of that little clip might have been. It didn't seem that they would have covered four of the eight pinsockets if they had intended me to use all eight. There didn't seem to be any instructions on point. Normally, I did review the installation literature supplied with my hardware, but I didn't recall actually seeing any installation instructions with the power supply, although possibly I had overlooked it. The motherboard manual didn't seem to say anything about that little clip, or about the importance of using the eight-pin plug rather than the four-pin. I might not have noticed it, even now, if it hadn't been for the experience of shopping for a replacement power supply that morning. I had noticed that the 520W Corsair indicated that its EPS plug was eight-pin, and I had thought to myself that possibly it would not be compatible with my mobo, which (I thought) required a four-pin. Now, reviewing the Newegg product specification page for the 620W power supply, I saw that it did indeed refer to an "8-pin EPS12V" connector. I had failed to review that webpage when the power supply arrived. Anyway, now I restored the last drive image that I had made, before all this swapping of motherboards and CPUs, and tried booting. The system went into Safe Mode. It also went into Normal Mode, but not until after I ran FIXMBR and CHKDSK /R again and did some other fixes. The most important of the fixes seemed to be the one, not previously documented here, involving LVPrcMon.sys. Now that I had reverted to the previous drive image, I had to redo this fix, which I had done early in the troubleshooting process but apparently did not document here. This error arose, at least in my case, from the Logitech Webcam driver. Removing that driver in Add/Remove programs eliminated this problem. Upon completing that and other fixes, I found that the system kept running all night while doing spyware scans using several programs (including especially Ad-Aware 2007, Spyware Doctor, Symantec Antivirus, and Spybot Search-and-Destroy). The next day, I rebooted, having also installed a number of assorted programs in the process of completing the rebuild of the Windows setup I had been using to date. I had a couple of programs running when the system froze. I rebooted and, after a while, it did it again. This time, though, it seemed to be attributable to Adobe Acrobat 8, which had updated itself. I wasn't sure what was the matter, but I scheduled and ran disk checks (right-click Properties for each partition). In the process, I spent several hours cooking up a batch file to automate these various maintenance processes, seeing how familiar I had become with CHKDSK and SFC and rebooting and all. By the time another day had passed -- this time, with (I think) no crashes since the last time I had run CHKDSK -- I was prepared to conclude that, one week after starting, my work on this project was done.

Automate Windows XP Maintenance and Shutdown

Using Notepad, copy the following text and paste it into a file named PowerDown.bat. Double-click on it to run it. Better -- put it in a folder somewhere and create a shortcut to it. If you like it, please post a kind comment on this webpage. *************************************** :: PowerDown.bat :: by Ray Woodcock :: Please post a kind word on my blog: :: Ray Woodcock's Latest :: This item posted on July 28, 2007 echo off cls :Menu1 echo. echo What would you prefer? echo. echo 1 Power Down echo 2 Hibernate (if available on your computer) echo 3 Restart echo 4 Maintenance echo 5 Nothing Further (Exit) echo. echo. echo Note: Ctrl-Break provides an emergency exit. echo. echo. echo. echo Choose a number and hit Enter ... echo. echo. echo. set /p x1= cls set x1=%x1:~0,1% if "%x1%"=="1" goto PowerDown if "%x1%"=="2" goto Hibernate if "%x1%"=="3" goto Restart if "%x1%"=="4" goto Maint if "%x1%"=="5" goto eof echo. echo Not a valid choice. echo. goto Menu1 :PowerDown shutdown -s -f -t 15 goto Undoit :Hibernate shutdown -h -f -t 15 goto Undoit :Restart shutdown -r -f -t 15 goto Undoit :Maint echo. echo What kind of maintenance would you like? echo. echo 1 Run System File Checker echo 2 Fix file system errors (/f) echo 3 Recover bad sectors (/r) echo 4 Defragment all drives echo 5 Previous Menu echo. echo Choose a number and hit Enter ... set /p x1= cls set x1=%x1:~0,1% if "%x1%"=="1" goto SFC if "%x1%"=="2" goto FixErrors if "%x1%"=="3" goto BadSectors if "%x1%"=="4" goto Defrag if "%x1%"=="5" goto Menu1 echo. echo Not a valid choice. echo. goto Maint :SFC sfc /scannow echo. echo System File Checker is now running in a separate process. echo Meanwhile, you are returning to the main menu in this program. echo. goto Menu1 :FixErrors echo. echo You will now choose the drives to check. echo Some will be fixed now. Most will require reboot. echo. pause cls echo. echo Checking drive C ... echo. chkdsk c: /f cls echo. echo Checking drive D ... echo. chkdsk d: /f cls echo. echo Checking drive E ... echo. chkdsk e: /f cls echo. echo Checking drive F ... echo. chkdsk f: /f cls echo. echo Checking drive G ... echo. chkdsk g: /f cls echo. echo Checking drive H ... echo. chkdsk h: /f cls echo. echo Checking drive I ... echo. chkdsk i: /f cls echo. echo Checking drive J ... echo. chkdsk j: /f cls echo. echo Checking drive K ... echo. chkdsk k: /f cls echo. echo Checking drive L ... echo. chkdsk l: /f cls echo. echo Checking drive M ... echo. chkdsk m: /f cls echo. echo Checking drive N ... echo. chkdsk n: /f cls echo. echo Checking drive O ... echo. chkdsk o: /f cls echo. echo Checking drive P ... echo. chkdsk p: /f cls echo. echo Checking drive Q ... echo. chkdsk q: /f cls echo. echo Checking drive R ... echo. chkdsk r: /f cls echo. echo Checking drive S ... echo. chkdsk s: /f cls echo. echo Checking drive T ... echo. chkdsk t: /f cls echo. echo Checking drive U ... echo. chkdsk u: /f cls echo. echo Checking drive V ... echo. chkdsk v: /f cls echo. echo Checking drive W ... echo. chkdsk w: /f cls echo. echo Checking drive X ... echo. chkdsk x: /f cls echo. echo Checking drive Y ... echo. chkdsk y: /f cls echo. echo Checking drive Z ... echo. chkdsk z: /f cls goto Summary :BadSectors echo. echo This can be very time-consuming, especially on large drives. echo Select only those drives that need this now. echo. pause cls echo. echo Checking drive C ... echo. chkdsk c: /r cls echo. echo Checking drive D ... echo. chkdsk d: /r cls echo. echo Checking drive E ... echo. chkdsk e: /r cls echo. echo Checking drive F ... echo. chkdsk f: /r cls echo. echo Checking drive G ... echo. chkdsk g: /r cls echo. echo Checking drive H ... echo. chkdsk h: /r cls echo. echo Checking drive I ... echo. chkdsk i: /r cls echo. echo Checking drive J ... echo. chkdsk j: /r cls echo. echo Checking drive K ... echo. chkdsk k: /r cls echo. echo Checking drive L ... echo. chkdsk l: /r cls echo. echo Checking drive M ... echo. chkdsk m: /r cls echo. echo Checking drive N ... echo. chkdsk n: /r cls echo. echo Checking drive O ... echo. chkdsk o: /r cls echo. echo Checking drive P ... echo. chkdsk p: /r cls echo. echo Checking drive Q ... echo. chkdsk q: /r cls echo. echo Checking drive R ... echo. chkdsk r: /r cls echo. echo Checking drive S ... echo. chkdsk s: /r cls echo. echo Checking drive T ... echo. chkdsk t: /r cls echo. echo Checking drive U ... echo. chkdsk u: /r cls echo. echo Checking drive V ... echo. chkdsk v: /r cls echo. echo Checking drive W ... echo. chkdsk w: /r cls echo. echo Checking drive X ... echo. chkdsk x: /r cls echo. echo Checking drive Y ... echo. chkdsk y: /r cls echo. echo Checking drive Z ... echo. chkdsk z: /r cls goto Summary :Defrag defrag c: /f defrag d: /f defrag e: /f defrag f: /f defrag g: /f defrag h: /f defrag i: /f defrag j: /f defrag k: /f defrag l: /f defrag m: /f defrag n: /f defrag o: /f defrag p: /f defrag q: /f defrag r: /f defrag s: /f defrag t: /f defrag u: /f defrag v: /f defrag w: /f defrag x: /f defrag y: /f defrag z: /f cls goto Summary :Summary echo. echo Your requested maintenance is complete. echo If maintenance requires rebooting, you echo will have that option now. echo. goto Menu1 :Undoit cls echo. echo If you want to cancel the reboot/shutdown, echo please hit Enter, quickly. echo. pause > nul shutdown -a cls goto Menu1

Batch Files to Automate Chores: WEBDAILY.BAT

You can use command-line files without knowing much about command lines. Here's an example of a program that I run by clicking on an icon. It's called WEBDAILY.BAT. I edit it in Notepad. In abbreviated form (i.e., just providing a few examples), its contents, as viewed in Notepad, are: ********************************* :: WEBDAILY.BAT :: Opens each website or file I want to visit daily. @echo off :: start firefox.exe start iexplore.exe :: start excel.exe "E:\Spreadsheets\Running Times and Distances.xls" start winword.exe "E:\Projects\Pain in the Ass Term Paper.doc" start acrobat.exe "E:\Big PDF File.pdf" start %SystemRoot%\system32\ntbackup.exe start %SystemRoot%\Explorer.exe "F:\Music CDs in Process\CDs" :: start C:\Windows\notepad.exe "E:\Current\Where I Was.txt" cls echo When everything else has loaded, you can proceed to load Cool Edit. pause start "Startup Commands Batch File" "C:\Program Files\Audio\Cool Edit\cool2000.exe" exit ********************************* OK, let's diagnose that. As you may have guessed, the two colons (::) at the start of a line make that line a non-command, i.e., a comment. The contents of that line will not actually run, when you run the program; they will just sit there. So you can see that I have "commented out" the line that used to run Excel and open the spreadsheet where I record my daily running times. I did that because I hurt my calf and was not running daily, so I didn't really want that spreadsheet opening up all the time. I've given examples of how you might run some of the more common programs in Windows XP. Examples here include Word, Excel, Adobe Acrobat, and the Firefox and Internet Explorer (iexplore) web browsers. Whatever it is, if you use it once daily, you can set this up and just click once to open all the stuff you want to work with every day. You can copy this file and modify it to be WEBWEEKLY.BAT or WEBMONTHLY.BAT or whatever, for those webpages or files that you want to open only once a week or on some other schedule. The last section, involving Cool Edit 2000, begins with CLS, which means Clear Screen. I was finding that Cool Edit was not loading properly in this automated way. It seemed to need everything else to be loaded and calmed down first, before it would run. So I added the clear screen, followed by a pause, to show me just this command, so that I would remember to let stuff settle before letting the program proceed. I don't remember exactly why I have that particular syntax about "Startup Commands Batch File," but it works. To wrap up this little project, save the WEBDAILY.BAT file somewhere and create a shortcut to it. Put the shortcut on your desktop or wherever is convenient, and you're done. You can right-click the shortcut to edit the batch file, which is convenient.

Tuesday, July 24, 2007

The Possibility of Great Change in the Housing Market

This item has been moved to my ideas blog.

Saturday, July 21, 2007

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.