BleepingComputer.com: pagefile.sys everywhere and nowhere

I've done a lot of searching to find earlier occurrences of this problem, but no joy. Hoping for some help here.

When virtual memory is enabled, Windows insists on putting pagefile.sys on my D: drive, even though it is configured to go to C:. I have reason to believe there is a phantom pagefile.sys on the C drive, which may be causing this behavior.

So my essential questions are:

• Is there a tool for doing fairly low level NTFS directory cleanup?
  
• Is there something else that can be causing this?

Looking at my system and researching on the forums, I identified the following possible causes (more details below):

• Permissions on C: not allowing system to write pagefile.sys in the root directory. I've ruled this out by inspecting the permissions.
  
• C: drive too fragmented to host pagefile.sys. I've used the windows defragmenter and JK Defrag to make this much, much better. There are vast clear openings on the C: drive now.
  
• C: drive corrupted. chkdsk has run automatically a few times recently leaving some "found" files and folders. Also, the JK Defrag log is reporting the existence of a C:pagefile.sys when it is not visible using Windows Explorer nor the DOS "dir" command.

Many thanks in advance for taking a look at this, and for any suggestions.

Here are lots of additional details.


Problem Description and Illustration

The following windows illustrate the system with Virtual Memory disabled:


No pagefile.sys on C:, as expected


No pagefile.sys on D:, as expected


Turning on Virtual Memory looks like this (note size is restricted to 500 MB, more on that later):


After a reboot the Virtual Memory config looks like this:


Notice how the memory amount is incorrect (850 MB actual vs. 500 MB configured).

And, there is no pagefile.sys on C:


But there is a pagefile.sys on D:!


That illustrates the problem in a nutshell. I have repeated this behavior multiple times with multiple defrags.

But how did we get to this point?



Narrative

Over this holiday break, I've been doing a lot of stuff on my laptop: Copied lots of files to a new external hard drive, used Media Monkey to catalog about 32 GB of music files, installed Exact Audio Copy and LAME to rip some CDs, etc.

Among all this, I also broke down and installed Windows XP Service Pack 3. That installation seemed to go OK. After the SP3 update was complete, Windows Update had me install the following additional updates:

• Broadcom - Network - Broadcom 802.11b/g WLAN
  
• Root Certificates Update
  
• Hewlett-Packard - Other hardware - HP Quick Launch Buttons
  
• Synaptics - Input - Synaptics PS/2 Port TouchPad
  
• CXT - Modems - HDAUDIO Soft Data Fax Modem with SmartCP
  
• Windows Genuine Advantage Validation Tool (KB892130)
  
• Update for Windows XP (KB951978)
  
• Security Update for Windows XP (KB954459)

I did notice chkdsk running during a couple of the reboot cycles required for all these updates.

At some point during or shortly after installing these updates and other software, the system started reporting that my D: drive was running low on space. But the D: drive is HP/Compaq's "recovery" partition, so nothing should be getting added to it. A quick look revealed that there was a pagefile.sys in the root directory, and it was large enough to leave just 32MB free on the partition.

Previous to all of this, I was getting errors loading the nVidia Systray applet libraries nvmctray.dll and nvcpl.dll. I believe this started after I loaded one of the following updates:

• Security Update for Internet Explorer 7 for Windows XP (KB960714)
  
• Security Update for Windows XP Service Pack 2 (KB952069)
  
• Update for Windows XP (KB955839)
  
• Cumulative Security Update for Internet Explorer 7 for Windows XP (KB958215)
  
• Windows Malicious Software Removal Tool - December 2008 (KB890830)
  
• Security Update for Windows XP (KB954600)
  
• Security Update for Windows XP (KB956802)

I wanted to rule this out as a cause of the pagefile.sys behavior. So I corrected it by downloading and reinstalling from HP (which complained that I was installing older drivers on top of newer ones), then updating to the latest version again with Windows Update.


System/OS Configuration

Here is the system summary as reported by msinfo32 when virtual memory is turned on and the problem is present. This is a Media Center PC. I'm not sure why it calls itself XP Pro, but it's always done it:


Steps taken

I've done lots of things in the last couple of days trying to solve this. Here is a list as best as I can remember:

• Got all latest Windows Updates
  
• Got nVidia drivers from HP web site, then updated with Windows update
  
• Several cycles of: Disable virtual memory, reboot into safe, delete D:pagefile.sys, defrag with JK Defrag, reboot, enable VM, reboot. One or two of these cycles was with Windows defrag and no safe mode. I also used PageDefrag at least once
  
• Tested the physical hard drive with Seagate SeaTools for DOS. SMART, Short, and Long tests all passed.
  
• At least once ran "Check Local Disk" on reboot

Ruling Out Root Causes

The first root cause I considered was whether the C: drive, which is NTFS, had somehow had its permissions restricted such that the system couldn't write a C:pagefile.sys.

Here is a screen grab of the current permissions:

As you can see, Administrator, Administrators and System all have Full Control access to C:. So I think this is not the cause of the problem.

The second root cause I considered was that the disk might be too fragmented for pagefile.sys to be written. After several cycles with JK Defrag and Windows defrag, some in Safe Mode, here is what the disk looks like now:

There should be more than enough defragmented clear space there.

The third root cause I am considering is some kind of disk corruption. There are two reasons I haven't ruled this out.

First, chkdsk has produced the a C:found.000 folder on the C drive which contains three subfolders containing the following files:


I don't know how those files could be related to this behavior, but the fact they are there is troubling.

Second, the log file from JK Defrag includes the following:


This C:pagefile.sys file is not visible in Windows Explorer nor does it appear when I run the DOS "dir" command. I am at a loss as to how JK Defrag is seeing it or how to make it go away.



That's about all the data I have on this right now.

My best guess at this point is that a corrupt c:pagefile.sys directory entry is preventing the system from writing a new c:pagefile.sys. If there were a way to look at and clean out that entry, I might have a chance to fix this.

I'd be delighted to collect and post any additional information that might be helpful.

Thanks in advance for any assistance.

Hello CraigBos and welcome to Bleeping Computer!

Before I start with the questions I have about your problem, I wanted to commend you on that post. I have several years experience on forums such as this one, and I have to say that your post has to be one of the best written, most informative, well documented and well presented problem I've ever seen! Kudos! It's not everyday we get to read something like this...

On to your problem. There's a few points I'd like to clarify here before I can say whether I can help. I understand what the issue is, but I'm unsure of the solution. There's a few possibilities I'd like to explore with you if you don't mind.

It seems to me, based on all the information you have collected that the main issue lies with the fact that Windows cannot write pagefile.sys to the C drive. It thus reverts to using the other available partition, the D drive. I suspect this has to do with the following:

Quote

When checkdisk runs automatically, it usually means that Windows has flagged the drive as "dirty" and requested the chkdsk. This is evident by the Found00* folders. Those are put there by checkdisk when it finds corruption in the File Allocation Table or if there are bad sectors on the drive. The files in those folders are not necessarily "clean", they may well be corrupted. They were found in corrupted sections of the drive. In your case, it seems as if some system files were found in those areas... I'm assuming that since you ran the HDD manufacturer diagnostics tool, that the health of the drive is fine, and that the problem is more related to Windows "bit rot".
You can't see the file in explorer or DOS. That is not unusual if the master file record is corrupted. Usually running checkdisk with fix will take care of that. So my question relating to this is the following, have you run checkdisk with the fix option? (start - run chkdsk /f or better yet, chkdsk /r) If not, I suspect this may clear the issue.

The other thing I wonder about, and this is probably not related to your problem at all, it's just something that piqued my curiosity in your post.

Quote

Are you sure the D drive is indeed the recovery partition? You can look in disk management. (Right click on "My Computer" and hit Manage. Scroll down to disk management and you should have a listing of all partitions on your system, including all drives (both fixed and removables) as well as opticals (CD-ROMs/DVDROMs).
The recovery partition should be restricted. Although I'm not 100% certain, normally they have special permissions so the users can't accidentally remove a critical file and break the recovery tool. Stranger things have happened though, and like I said, it is probably not related to your problem, but it is curious to me.

As for clean up, there's a few tools that do that, but I am not sure any of those would be of use to you in this situation. Atribune's ATF-Cleaner is one. It mostly concentrates on TIF (Temporary Internet Files) and such, but it does also clear out several system temp file folders. Might be worth a shot.

But as I have stated, I would tend to agree with your conclusion of a corrupted C:\pagefile.sys blocking the creation of a new one. It also might explain the discrepancy in virtual memory settings vs actual virtual memory being reported. If indeed there are remnants of a previous pagefile.sys on the C drive, the system may well see it in the File Allocation Table and report the size of the file incorrectly. That is indeed a symptom that something's not right there. Let us know if chkdsk /f or /r works. If not, I'll see if someone else with a little more insight might take a look.

Regards,

Gal

Nice post, and nice response!

Gal and dc3, thanks for your kind responses. chkdsk /r is in process now and I am headed to bed. I'll post results in the morning.

Good night!

In answer to your questions:
1. Is there a tool for doing fairly low level NTFS directory cleanup? It depends on what you mean by this. You can access and delete directories from outside of Windows by using a boot disk. This is the most likely way to locate and delete the C:\pagefile.sys that's hiding on your drive.
2. Is there something else that can be causing this? Yes there could be, and here's some suggestions:

Since the system has run CHKDSK /R more than once, that's suggestive of a drive/controller issue (and tends to rule out a file system issue). Since you're having pagefile issues, this tends to confirm that (since the pagefile holds virtual memory, it's read from and written to fairly regularly when it's in use. We can't rule out Windows as a possible cause at this point - but it's less likely than the other causes that I mentioned.

Since you've tested the drive with the SeaGate SeaTools, we'll have to assume that the drive isn't the issue.

Then the most likely problem is with the motherboard (remember, this is just the most likely scenario - not necessarily your scenario).

You can usually test the hard drive controller on the motherboard with the SeaGate SeaTools disk. I haven't done this from withing Windows, but it's easily selectable when booting from the bootable version.

Beyond that you can try this free program to see if there's any obvious issues with the motherboard: http://www.sisoftware.co.uk/index.html?dir...n=sware_dl_3264

I would also check in your Event Viewer for errors. To do this, go to Start...Run...and type in "eventvwr.msc" (without the quotes) and press Enter. Click on the System log file item in the left hand pane, then scroll down the right hand pane to look for the errors.

More questions/comments:
- Have you let Windows manage the pagefile? If so, what results do you get?
- I believe it was HP/Compaq systems with AMD processors that had issues with SP3 - due to the loading of an Intel processor driver. Have you check to see if this is disabled?
- I would suggest finding the exact model of your video card and visiting the nVidia website to download the latest drivers from there. Once you've downloaded them, uninstall the HP/Windows drivers from the Control Panel...Add/Remove Programs applet. In the past I've had issues with HP drivers from HP and Windows Update - the nVidia drivers work without fail. If you can't locate the drivers at the nVidia site, post back and we'll see what we can find.
- I suspect the pagefile on C: is a hidden Windows thing (but can't verify this) as similar issues have happened to me in the past. But my issues were with smaller sizes, while yours seems to be 1.5 gB.
- Media Center is a hodge-podge of XPHome, XPPro, and other stuff - the reporting isn't really an issue
- Your system specs from MSINFO32 reveal the pagefile on D: to be 1.68 gB - is this correct, or is it another quirk?

Quick update/response:

• The system still behaves the same after chkdsk /r
  
• I booted the system from CD (bootdisk.com NTFSWCDD). c:\pagefile.sys did not show up in the directory listing under NTFS-enabled DOS.
  
• I used PC Inspector to look for "lost" files on C:. Although PC Inspector found thousands of files, pagefile.sys is not one of them.
  
• Letting system manage VM size behaves the same way -- places pagefile.sys on D:

I will pursue your other suggestions also.

Right now I am focusing on the MFT.

Using Disk Investigator, I found the following data in cluster 13:

000000000C00  0C00    46 49 4C 45 30 00 03 00 AC 6E 42 B3 13 00 00 00    FILE0....nB.....
000000000C10  0C10    0F 00 01 00 38 00 01 00 60 01 00 00 00 04 00 00    ....8...`.......
000000000C20  0C20    00 00 00 00 00 00 00 00 04 00 00 00 0F 00 00 00    ................
000000000C30  0C30    03 00 00 00 00 00 00 00 10 00 00 00 60 00 00 00    ............`...
000000000C40  0C40    00 00 00 00 00 00 00 00 48 00 00 00 18 00 00 00    ........H.......
000000000C50  0C50    B0 98 96 6F 35 2B C7 01 60 B5 2F 94 29 69 C9 01    ...o5+..`./.)i..
000000000C60  0C60    60 B5 2F 94 29 69 C9 01 60 B5 2F 94 29 69 C9 01    `./.)i..`./.)i..
000000000C70  0C70    26 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    &...............
000000000C80  0C80    00 00 00 00 53 01 00 00 00 00 00 00 00 00 00 00    ....S...........
000000000C90  0C90    00 00 00 00 00 00 00 00 30 00 00 00 78 00 00 00    ........0...x...
000000000CA0  0CA0    00 00 00 00 00 00 02 00 5A 00 00 00 18 00 01 00    ........Z.......
000000000CB0  0CB0    05 00 00 00 00 00 05 00 B0 98 96 6F 35 2B C7 01    ...........o5+..
000000000CC0  0CC0    60 B5 2F 94 29 69 C9 01 60 B5 2F 94 29 69 C9 01    `./.)i..`./.)i..
000000000CD0  0CD0    60 B5 2F 94 29 69 C9 01 00 00 00 00 00 00 00 00    `./.)i..........
000000000CE0  0CE0    00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00    ........ .......
000000000CF0  0CF0    0C 03 70 00 61 00 67 00 65 00 66 00 69 00 6C 00    ..p.a.g.e.f.i.l.
000000000D00  0D00    65 00 2E 00 73 00 79 00 73 00 00 00 00 00 00 00    e...s.y.s.......
000000000D10  0D10    80 00 00 00 48 00 00 00 01 00 00 00 00 00 03 00    ....H...........
000000000D20  0D20    00 00 00 00 00 00 00 00 FF CF 05 00 00 00 00 00    ................
000000000D30  0D30    40 00 00 00 00 00 00 00 00 00 00 5D 00 00 00 00    @..........]....
000000000D40  0D40    00 00 00 5D 00 00 00 00 00 00 00 00 00 00 00 00    ...]............
000000000D50  0D50    33 00 D0 05 00 80 1B 00 FF FF FF FF 82 79 47 11    3............yG.
000000000D60  0D60    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
000000000D70  0D70    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

This looks like an MFT file entry. I am attempting to decode it using the documentation here: http://sourceforge.net/project/showfiles.p...ackage_id=16543

More as I know it.

Thanks again for the attention and assistance.

When Windows manages the pagefile, what size is it?

I'm gonna have to do some reading about the details of the MFT before I can even start to comment on your work - this is way beyond anything that I know!

This problem is now solved.

In this post I will boil down to the essential info needed to diagnose and correct the issue. Later I'll make a separate post with some broader comments. Maybe.

If you've found this thread as a result of a search for a solution to your pagefile.sys problem, welcome. I hope there is some useful information here for you.

This post contains the following:

• Steps to diagnose the problem
  
• Steps to rule out other causes
  
• How to do a complete "VM Off/Defrag/VM On" Cycle
  
• How to delete the phantom page file

DISCLAIMER: This post is written in tutorial form, but you should really understand what you are doing before attempting any of this. If you are unsure, print out this post and take it to a more knowledgeable person who can explain what each of these steps actually does. Or better yet, have him/her help you directly.

Before starting, I want to thank BleepingComputer users Galadriel and usasma for their comments and suggestions. Also, I'd like to thank the providers of the freeware tools JkDefrag, CCleaner, and NTFS4DOS. They were all very helpful in getting this solved.


Diagnosis

The essential problem was that there was a corrupt entry for pagefile.sys on my C: drive. This caused the system to be unable to write a pagefile.sys on C:, so it fell back to writing it on D:. On my laptop, this is a "Recovery Partition" with little free space. I first noticed the problem when the PC started reporting that my D: drive was low on space (down to 32 MB).

More generally, if you notice Windows putting pagefile.sys on some drive other than the one that is configured in the Virtual Memory dialog, you might have the same problem.

To diagnose, check where pagefile.sys is supposed to go vs. where it actually is.

To see where the file is supposed to be, right click My Computer and select Properties. Click the Advanced tab, then click the Performance Settings button. In the Performance Options box, select the Advanced tab and click the Change button under Virtual Memory.

Here is what my Virtual Memory window looked like when the problem was occurring:



Highlight each volume that is listed and look at the radio buttons. Volumes with the "No paging file" button selected should not have an active pagefile.sys, while volumes with the "Custom size" or "System managed size" buttons selected should have an active pagefile.sys. Make a note of how each volume is configured.

Next, see if pagefile.sys is actually where it is supposed to be. Make sure Explorer is configured to show all files. Open an Explorer window, select Tools->Folder Options... and make sure the red circled items are configured like this:



I click the "Apply to All Folders" button to make sure it does what I want in all locations.

Now use Explorer to look at the root directory of each hard drive. Here is a C: drive with an active pagefile.sys on it:



Pay attention to the date/time on any pagefile.sys files you see. The time of the file corresponds to the time the PC was booted. It is possible for a pagefile.sys to be laying around on a drive but not in active use. Use the date/time to determine this. Make a note of which volumes have visible active pagefile.sys files and which do not.

If you find an active pagefile.sys on a volume that is not configured to have one, that indicates a problem. Conversely, if there is no visible active pagefile.sys on a volume that is supposed to have one, that also indicates a problem.

Finally, check to see if there is a phantom pagefile.sys on any of your volumes. The easiest way I found to do this with Windows running is to use JkDefrag (http://www.kessels.nl/JkDefrag/index.html) to analyze the drive then look at JkDefrag's log.

Assuming you have installed JkDefrag to someplace like this: C:/Program Files/JkDefrag-3.36, do Start->Run...

This will analyze the C: drive and put some info into C:/Program Files/JkDefrag-3.36/JkDefrag.log

Use Notepad to look at this plain text file. Near the bottom there will be a list of the 25 largest files on the volume. When my system was experiencing the problem, this examination turned up a 1.5 GB pagefile.sys on C:, even though none was visible in Explorer.

It looked like this in the log file:
This indicates that a pagefile.sys is on the volume. If it is not visible in Explorer after following the above instructions, then something is wrong.

Repeat this for each volume.

In my case, I had all three problem signs:

• There was no visible pagefile.sys on C: when one was configured to be there
  
• There was an active pagefile.sys on D: when none was configured for that volume
  
• A phantom c:pagefile.sys was visible in the JK Defrag log but not in Explorer

Ruling out other causes

According to my research, there are a couple of other things that might cause Windows to redirect pagefile.sys:

• File permissions might have been altered, not allowing the system to write pagefile.sys in its configured location
  
• The volume might be too fragmented to support a pagefile.sys

Rule out the file permissions cause by verifying them directly. I am running Media Center, so I first had to disable "Simple file sharing."

To do this, get back to the Folder Options window and uncheck the "Use simple file sharing" box, like this:



Now use Explorer to navigate over to the root directory of each volume (c:, d:, etc.), right click the root directory, select Properties, then click the Security tab. Click on the Advanced button under that tab.

The Advanced Security Settings box should look something like this:



Notice that "Administrator" and "SYSTEM" have Full Control permission on my C: drive. That is as it should be. If yours does not look like this, edit the permissions for those names and make sure they have full control. Make sure to do this for all volumes.

Once complete, execute a "VM Off/Defrag/VM On" cycle and start again at the top of the diagnosis section. Done properly, the "VM Off/Defrag/VM On" cycle will also rule out disk fragmentation as a cause.


"VM Off/Defrag/VM On" Cycle

We want the hard disk to be as clean as possible before we start playing with a possibly corrupt Master File Table. So I recommend the following steps be performed before going any further:

• Do a disk cleanup.
  
  Using the Windows tool is fair to middlin, but I also recommend you use a stronger cleaner such as CCleaner (http://www.ccleaner.com/download). Take your time and do a good job with this. Less junk on your hard drive makes everything else easier. Note, this is for file system cleanup only. I don't necessarily recommend using CCleaner's registry cleaner.
  
  Repeat for each volume.
  
  
  
• Disable Virtual Memory.
  
  Get to the Virtual Memory dialog as listed above. For each volume in your system, make sure the "No paging file" radio button is selected. Don't forget to click the "Set" button on each volume.
  
  
  
  
  
• Reboot
  
• Once back into Windows, use Explorer to navigate over to the root directory of each volume and delete any left over pagefile.sys files. While you're at it, you might as well disable Hibernation and delete hiberfil.sys also. (If you don't know how to do this, never mind.)
  
• Run chkdsk.
  
  Start->Run... chkdsk c: /r
  
  Type Y to have chkdsk run on the next reboot. Reboot and let the check run.
  
  
  
• Repeat for each volume
  
• Let the last chkdsk complete a normal boot
  
• Reboot (again) into safe mode, by pressing F8 after the hardware power on self test
  
• Log into the Administrator account
  
• Defragment the volume(s) where you want pagefile.sys to land
  
  As with disk cleanup, the Windows tool is only OK. I had good luck with JkDefrag (http://www.kessels.nl/JkDefrag/index.html). It seemed to do a much more complete job.
  
  When the defrag is complete, the volume should have vast open spaces on it like this:
  
  
  
  If your disk is too full to do a good defrag, I recommend freeing up some space. In my case, I had about 25% free space to start with and freed up more as I went along.
  
  
  
• Enable virtual memory.
  
  Get the to the Virtual Memory dialog as described above. Select which volume you want pagefile.sys to be on, and how much space you want to allocate, or let the system manage the size. Mine now looks like this:
  
  
  
  
  
• Reboot
  
• Follow the steps in the Diagnosis section to see where your pagefile.sys ended up

If pagefile.sys is not where you configured it to be, and especially if the JK Defrag log shows a page file where Explorer shows none, read on.


Hunting The Phantom Page File

I believe the cause of my phantom pagefile.sys was an ever-so-slightly corrupted Master File Table on my NTFS volume C:. This corruption left the remnants of a pagefile.sys on my C: drive, preventing Virtual Memory from operating properly.

I got rid of it by making a bootable DOS CD-ROM with NTFS4DOS on it. I used the one at http://www.bootdisk.com/ntfs.htm, but I suspect the original freeware (http://www.free-av.com/en/tools/11/avira_n...s_personal.html) would have worked just as well and saved me $4.

Either way, make your boot disk, and have it ready.

Start another "VM Off/Defrag/VM On" Cycle, but stop after step 7.

Insert your NTFS4DOS bootable CD and reboot. Jump through whatever hoops you have to in order to get to a DOS prompt.

Note, since NTFS support is an add on, all of your FAT volumes will be ahead of your NTFS volumes in drive letter. For me, my "Recovery partition" came up as drive C: and my Windows boot partition came up as D:.

Change to the drive where you think your phantom pagefile.sys resides, as revelaed by the JK Defrag log, adjusted by the drive letter reordering. In my case, the phantom page file was on D: in the NTFS4DOS environment.

Type dir /ah /as

If you see a pagefile.sys, you are in luck. But it isn't over just yet.

Type del pagefile.sys

When I did this, I got a very scary warning about deleting all files in the directory. Since this was the root directory of my Windows boot drive, I did NOT let it complete that delete operation. Turns out the corruption made the system think that pagefile.sys was actually a directory, not a regular file. I could cd to it, but there were no files in it, not even the "." or ".." directories.

If you get the same warning, do not let the delete continue.

Instead, type rmdir pagefile.sys

Type dir /ah /as again to verify it is gone.

Resume the interrupted "VM Off/Defrag/VM On" Cycle at step 8.

Execute the diagnostics steps again to make sure your pagefile.sys is now where you wanted it. (In other words, trust but verify.)

If the diagnostics steps check out fine you are done.

If this had not worked for me, I was considering the following alternatives:

• Get a sector editor and fix the corrupted MFT entry by hand (risky, might force choice 2)
  
• Reformat the partition, or maybe repartition the entire drive and start fresh (painful)
  
• Let pagefile.sys stay on D: and suppress the warning (inelegant but relatively safe and painless for now)

I'm glad I didn't have to make that choice.

Hopefully this information will be useful to others in the future. Corrections and comments are welcome.

CraigBos, you rock!

Great troubleshooting work! It was a pleasure to read and participate in this topic (even if I didn't really do much) and I thank you for it.

The only thing I would caution users about is the use of CCleaner. If any use it, I strongly recommend against the use of the Issues tab/button. The registry is a very fickle area, and one automated tools really shouldn't attempt to "clean". For more info on the reasoning behind this caution, I strongly recommend this read: XP Myth: Registry Cleaners.

Galadriel, on Dec 31 2008, 12:37 PM, said:

If I read his post correctly, he is using CCleaner to clean the Temporary files, not the registry.

Quote

Galadriel, on Dec 31 2008, 12:37 PM, said:

The article that Galadriel posted the link for is an eye opener, but there are still going to be those that will not read and understand the instructions and will go ahead and use the cleaner which can result in turning your computer into a door stop. For those that feel that they must use a cleaner I would suggest that they back up their registry with a tool like Erunt before using the cleaner.

Backup Your Registry with ERUNT

• Please use the following link and scroll down to ERUNT and download it.
  http://aumha.org/freeware/freeware.php
  
• For version with the Installer:
  Use the setup program to install ERUNT on your computer
  
• For the zipped version:
  Unzip all the files into a folder of your choice.

Click Erunt.exe to backup your registry to the folder of your choice.

Note: to restore your registry, go to the folder and start ERDNT.exe

LOL, the dangers of "Edit Post."

xblindx, on Dec 31 2008, 09:51 AM, said:

I edited the post and added the registry disclaimer because of Gal's comment.

Sorry for any confusion!

xblindx,

Back to the Study Hall I say!!!


(Just kidding)

Galadriel, on Dec 31 2008, 01:40 PM, said:

Where is that beating up someone with a stick smiley at? I dont see it Oh wait! What's this? You uploaded it from photobucket! :D

I'll begin working on my next PL this weekend or next week once holidays pass.

Craig, excellent post! Would you mind if I downloaded the images and hosted them here so they do not eventually disappear?