Mystery Of The "Registry Clean'.

Nil wrote:

sam.walker38 wrote:

All the garbage makes the reg. get larger and larger. There is a
limit on registry size.

What is that limit? A quick search finds some reports that the USER
registry file can't be more than 200 MB. I installed XP about 6
years ago on this computer. I've installed and removed hundreds of
software packages. I use it heavily every day. My USER file is 6 MB.
My SOFTWARE file is 40 MB. from what I gather, any limit will only be
approached by systems with many, many accounts, such a Terminal Server.
No personal home computer is likely to come anywhere close to a limit.

I did hit 100 MB in one workstation but that's not the norm. My current
registry files (on disk) from %windir%\system32\config and my user.dat
files consume 46.6 MB. That's from a fresh build I did for my XP host
with all apps and tweaking starting back on 03-Jan-2013. Yeah, it went
up fast but hereafter I will not see again that level of app installs,
tweaking, or app config changes.

The max size of the registry is a registry setting:

System Key: [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l]
Value Name: RegistrySizeLimit
Data Type: REG_DWORD (DWORD Value)
Value Data: (0xffffffff = maximum)

4 MB is the lowest value allowed. Entering a value less than this
results in using 4 MB. If set to more than 80% of the paged memory
pool, the real upper limit used with be 80% of the paged memory pool up
to 102 MB.

There is a console-mode command to see how much memory the registry
image there is consuming but damn if I remember it at the moment.

And even if you dont reach the limit, the bigger the reg. is, the
longer it takes for Windows to find what is needed. This may be
an insignificant amount of time, but every task windows performs,
takes up time. Combined all the useless tasks and sorting thru
garbage will slow down performance. Over time, people ask why
their computer is slow. That is why!

No, I don't think so. Any slowdown by the registry is minuscule and
insignificant. If your computer is slow, there are other problems.
"Cleaning" the registry will not make your computer seem faster. You
will never be able to detect the difference. It's a waste of time.

Sam doesn't know in-memory hives are used by the OS and apps to get
registry values. The OS and programs use the memory copy for not just
for speed to access individual entries but also to randomly access them
so there is no delay caused by pollution within the registry for
orphaned entries. The orphans aren't accessed, doesn't take time to
skip them as they aren't read, and, yes, they're superfluous but
they're not in the way. It's called RAM for a reason.

Why would you NOT want peak performance. Sure the registry is
efficient, but the bigger it is, the longer it takes to find the
needed info.

No, it doesn't, not in any perceivable way.

The only performance gained yet imperceptible is the time to read the
smaller registry *disk* files into memory. Thereafter the memory copy
is used, not the disk files. Deleting orphaned entries in the registry
will not reduce the size of the registry's disk file. Those delete-
marked records are still physically within the database. Like you
mentioned, after cleanup the database would have to be purged of
delete-marked records within it and then the database compacted (which
has nothing to do with file defrag). Personally I don't recall any
registry cleaner that I've trialed or read about that ever truthfully
state they compact the database after the cleanup operation (see below
about removing slack space in a cluster after the *file* which is NOT
compacting the database within that file). So they delete some registry
entries and you hope their cleanup database for entry definition, rules,
and their dependency walking is accurate but still that does not reduce
the size of the database in the registry's disk files. This like
vacuuming your room of dust and dirt and thinking this makes your room
smaller. The dirt is still in the vacuum bag and you still have the
same space to walk around within. You need to run a purge on the
delete-marked records to physically remove them from the database and
then compact the database (which is NOT the same as defragging the disk
files). This gives you more free dataspace in which the database can
grow. Personally I don't recall seeing, finding, or using any cleanup
utility that dug into the registry's database that way, like you would
for SQL, but then, to be honest, I never bothered to look for one. To
me, it makes no sense to spend time to remove delete-marked records and
compact the database when, one, that same space is going to get reused
later and, two, the entire database gets read into system RAM and,
three, fragmentation in sequencing of records in the database is a
non-issue after it's all copied into memory. Deleting, purging of
delete-marked records, and compacting the database is useful when that
database is getting accessed on slow media (compared to memory).

Just in case sam decides to go there, nope, defragmenters will not
reduce the size of the registry's disk files, either. Some claim to
defrag and compact the registry. They don't compact the files (make
them smaller) by purging the delete-marked records and compacting the
database. They just defrag the *file* to compact it into a contiguous
set of clusters on the hard disk to reduce overall slack space. That's
a reduction in size in the file system, not a reduction of the database
within that file. Reducing the disk footprint for the registry's files
does not reduce the memory footprint when the database is copied into
system RAM.

Delete-marked records (invisible remnants) *within* the registry's
database is a non-issue regarding performance. Pollution from orphaned
entries (visible remnants) in the registry's database is a non-issue.
None of that matters after copied into *random* accessed memory (RAM).
The difference to load into a memory image a 10 or 100 MB file will be
far less than a couple seconds but that's swamped (masked) by all the
other load-time processes on Windows startup. Registry access is
randome memory access, not some sequential memory access method. The
registry isn't getting read from disk or sequentially off tape media.

Remnants (visible for orphaned records or invisible for delete-marked
records) within the database structure is irrelevant for a database that
is completely loaded into memory. Those remnants aren't accessed when
the non-orphaned records are accessed. File fragmentation of the
registry's file is irrelevant since only the memory copy is accessed.
No one here is still using a 5 or 10 MB hard disk from the PC-AT days to
worry about the size of the registry's disk files being 4 or 100 MB.

There is a concern regarding approaching the maximum size (in memory)
for the registry. That's when cleanup will help in providing breathing
room for subsequent pollution; however, rare few users that do registry
cleanup have a clue as to what is their current registry's image size in
memory. They don't think about that. They want to vacuum their room to
keep it clean, not because it slows them down from walking across it.
They think deleting records in the registry is going to reduce the size
of its database. Nope. They think running file defragmenters, even
those specifically for the registry files (since those have to be
defragged before the files are inuse so you restart Windows to run the
defrag early), will reduce the database size but all they're doing is
eliminating slack space across a 1 to 3 clusters so reduce it to the
slack space in 1 cluster. The "compaction" obtained by these registry
defraggers is just the same reduction in slack space in making files
contiguous in the file system.

Registry cleaners are generally considered snake-oil because very little
benefit and nearly immeasurable gain are achieved in exchange for a LOT
of risk. Yes, you can backup the registry but how are you going to
restore unless you load an OS to under which to run that registry
cleaner to restore those registry changes? Rare few users of registry
cleaners have an escape plan. They think a registry cleaner that saves
backups before making changes is somehow going to allow them an easy
restoration. Maybe if the changes are small and non-critical. They get
caught when the OS won't load after a cleanup and have those backups
that are now useless unless they planned on how to reinsert those
backups without the OS running.

There is one use for a registry cleaner that does have a benefit: on
rare occasion, it fixes a behavioral problem with an app. Typical
registry cleaners won't deal with that. It takes a good one that can
trace through the interdependencies between keys and their data items to
discover missing handlers to realize, for example, a shell extension is
no longer valid. For example, I've seen where the context menu won't
show or causes a crash in an app because a shell extension added for
that object got orphaned by an uninstall. The uninstall was dirty. It
left behind its entry for the context menu. Windows still wants to
build the context menu but fails so it doesn't show. A smart registry
cleaner will trace the dependencies to see the handler is missing and
remove that orphaned shell extension and suddenly the context menu on
that object starts working again. However, if the user had enough
expertise to make an educated decision regarding the registry cleaner's
proposed changes that will fix that invalid shell extension, they have
the same expertise to drill into the registry to make that change
themself; however, it is handy to use an automated tool to *find* the
no-longer-valid key and let the expert then decide to delete it.

For the prevalent usage of registry cleaners, you have dumb users that
are ignorant of the proposed changes (assuming use of a registry cleaner
that actually pauses to show its proposed changes). They use this tool
blindly. They assume the registry cleaner knows what it is doing but
neglect to realize why there are updates to such tools. They were
wrong, didn't understand the purpose of some keys, or learned some more
about dependencies between them. After presented with the list of
proposed changes, they just bang the Clean button and hope it all works
okay now and no problems show up week later when they've long forgotten
about cleaning the registry. Sometimes it's the fault of the registry
cleaner, too, in not presenting enough information to make an educated
decision (assuming the user understands the changes). They know
ignorants are using their program and these same boobs are the types
that never will learn about the registry but expect the software does it
all correctly for them. It worked now but sometime later they step on
that landmine caused by the cleanup. These same users don't plan for
escape. They don't know how to replace registry files from a different
booted OS into the inactive one from which the registry backups were
made. They think a registry cleaner professing to save backups before
making changes will always be available and then get caught when the OS
won't load under which that registry cleaner must run to restore the
registry snapshot. They see just the registry cleaner, not the environ
under which they may require when the OS won't load. Even saving image
backups of the OS partition is something these registry cleaner toting
users don't do. They use a dangerous tool meant for use by experts
without planning on how to recover. Having a super-sharp ultra-thin
flexible filet knife is great when used by someone expert in fileting
fish but the knife wielded by a boob is dangerous and results a messy
filet job. Those expert enough to use a registry cleaner don't need the
registry cleaner. It just makes quicker the cleanup or repair job.
Alas, that's not the prevalent type of user employing this tool.

There are some benefits to using good registry cleaners but they are
small and often insignificant or immeasurable. Probably the only
benefit to the vast majority of ignorants using registry cleaners is
they feel better afterward. The placebo effect. The danger is these
same ignorant users are hunting blind in a field aplenty with pheasants
and pleased to have hit a few with their multiple shotgun blasts that
they relied on someone else to aim the barrel but then wonder later why
the dog doesn't come when called for dinner.

VanguardLH wrote:
Paul wrote:

Barry Bruyea wrote:

I have three programs that are used to clean the Registry. One of
them, jv16 I've used for years and it has been very reliable. The
problem I've been having for a couple of days is that when I use them,
the start up the process and suddenly the computer crashes. It is so
fast that I can't tell which found entry might be the cause. Even
RegEdit freezes when checking. Other than that the computer is
running normally. Any ideas?

A restore point, from System Restore, keeps copies of the
registry.

All you need to do, is use a restore point from a few days
ago, to get out of your bind.

*IF* the OS still loads after the registry cleanup. For the prevalent
majority type of users of this type of cleanup tool, they won't
understand how to insert registry files into an inactive copy of the OS.
Remember that these type of users don't understand the registry and why
they're blindly relying on software to do it for them (versus use as an
automatic tool to show an expert who is still responsible for making
educated decisions).

Reminds me of going to the gun range. I go there for practice to
improve my proficiency and accuracy: get my groupings down to a dime
size and reduce my firing time. While I'm there, I see the bozos that
party, don't focus, and go squirt a bunch of bullets at maybe 20 feet
away and feel happy they manage to get a few to hit a man-sized target.
I dismantle my semi-auto handguns to thoroughly clean and properly lube
them. They might run a swab down the barrel and consider that cleaning
their firearm, or they don't bother to clean at all and wonder why they
start experience problems with shell ejects. Yeah, like me, they can
buy firearms, too, but there are gun owners and gun experts. I
certainly wouldn't want those bozos dismantling my firearms. Let them
treat theirs as disposable toys. I like mine in top operating
condition. Yep, I'm equating the vast majority of users of registry
cleaners with those jerks almost blindly squirting out bullets and not
knowing how to proper cleanup.

Those that know how to do manual cleanup of the registry use good
registry cleaners as a convenience. Those that don't understand the
registry should be touching registry cleaners. The benefits of registry
cleanup are tiny. The hazards are great.

Most problems I've seen caused by registry cleaners are not immediately
effected after the cleanup. The OS or apps don't immediately blow up
with behavioral defects, like not loading, won't perform a function, the
video goes haywire when later running a game (old one that hasn't been
played in a while or after installing a new one). Immediately blowing
up in their face right after performing a registry cleanup would be far
better than the effects showing up long after the user has any
remembrance of the cleanup. The user won't make a connection between
their blind use of a registry cleaner and problems that show up later.
The restore point might be long gone by then.

Don't use really ancient restore points. Use one that is only
a few days old. System Restore does more than it needs
to, on WinXP, and you can lose data files (if they're
stored outside My Documents).

As for system restores (remember this is for Windows XP), I wouldn't
trust any other than the most recent one. That is, I'd trust only one,
the last one, to get back to a stable state before the registry cleanup.
To be honest, I don't rely on (trust) restore points. It's one of those
"see if it works but probably not."

I've tested System Restore on a few occasions, and it (generally) has done
pretty well, surprisingly. In some cases, some app or two needs to be
reinstalled, but that's no biggie, but I prefer not relying on it.

But in the case of the OP, he may not have a better choice.

I prefer using ERUNT "when the need arises", but ERUNT is only a subset of
what System Restore can do (which is sometimes a useful thing).

Best of all is to restore an image or clone backup of your system, of
course, which is what I routinely do after testing out some software app
that I may not want to keep.

In message , VanguardLH
writes:
[]
(leaving aside registry _cleaners_ and looking at registry _defragging_
[possibly after a "clean"]

Just in case sam decides to go there, nope, defragmenters will not
reduce the size of the registry's disk files, either. Some claim to
defrag and compact the registry. They don't compact the files (make
them smaller) by purging the delete-marked records and compacting the
database. They just defrag the *file* to compact it into a contiguous
set of clusters on the hard disk to reduce overall slack space. That's
a reduction in size in the file system, not a reduction of the database
within that file. Reducing the disk footprint for the registry's files
does not reduce the memory footprint when the database is copied into
system RAM.

But, as you and others have said at length, the registry that is
actually in _use_ is the one in RAM. Thus anything that only defrags the
one on disc is not, surely, doing _anything_ useful, since those files
will be rewritten back at the full size next time the RAM copy is saved
back. Surely there _are_ some that garbage-collect the one in RAM.
(Whether this is _useful_ is another matter: as someone in this thread
pointed out, it _will_ affect how much _memory_ the reg. occupies;
whether the difference makes any perceptible difference to performance
depends on what else you have in memory, or rather, how close to running
out of memory you run [if nowhere near, then using more doesn't
matter].)
[]
The difference to load into a memory image a 10 or 100 MB file will be
far less than a couple seconds but that's swamped (masked) by all the
other load-time processes on Windows startup. Registry access is

Agreed.
[]
Remnants (visible for orphaned records or invisible for delete-marked
records) within the database structure is irrelevant for a database that
is completely loaded into memory. Those remnants aren't accessed when
the non-orphaned records are accessed. File fragmentation of the

IME, the majority of such entries that an RC finds are MRU (most
recently used) lists for app.s anyway. (Usually recognisable by their
being single-letter pointers - 'file "a" points to a file that no longer
exists' sort of thing - which will just grow back when that app. is next
used anyway.)
[]
There is a concern regarding approaching the maximum size (in memory)
for the registry. That's when cleanup will help in providing breathing
room for subsequent pollution; however, rare few users that do registry

What would happen if you did reach it, anyway?
[]
Registry cleaners are generally considered snake-oil because very little
benefit and nearly immeasurable gain are achieved in exchange for a LOT
of risk. Yes, you can backup the registry but how are you going to
restore unless you load an OS to under which to run that registry
cleaner to restore those registry changes? Rare few users of registry
cleaners have an escape plan. They think a registry cleaner that saves

Many of the discussions I've seen regarding backup strategies, not just
registry cleaners, seem to omit this aspect: people go on about how
excellent this or that backup utility/strategy is, but omit discussion
of the restore-when-OS-not-bootable method it includes (assuming it
does). To be fair, I think most around now do include some mechanism,
but it gets left out of many - I'd say most - discussions of the
subject.
[]
There is one use for a registry cleaner that does have a benefit: on
rare occasion, it fixes a behavioral problem with an app. Typical

And, arguably, to save time for those who know what they're doing.
[]
they feel better afterward. The placebo effect. The danger is these
same ignorant users are hunting blind in a field aplenty with pheasants
and pleased to have hit a few with their multiple shotgun blasts that
they relied on someone else to aim the barrel but then wonder later why
the dog doesn't come when called for dinner.

(-:
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

It is dangerous to be sincere, unless you are also stupid. - George Bernard
Shaw

In message , Paul
writes:
[]
Don't use really ancient restore points. Use one that is only
a few days old. System Restore does more than it needs
to, on WinXP, and you can lose data files (if they're
stored outside My Documents).

I've seen this statement (or ones very like it) before. So system
restore actually deletes files? Is that only from certain locations on
drive C, or what? When you say data files, I presume you mean ones
created by applications, such as documents, pictures, sound, video, or
whatever the application is there to handle.

*******

On a system where you cannot manage to run System Restore immediately,
you can follow this procedure.

"How to recover from a corrupted registry that prevents Windows XP from
starting"

http://support.microsoft.com/kb/307545

What that does, is repair the registry in two steps.
[]
(This post marked as keep.)
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

It is dangerous to be sincere, unless you are also stupid. - George Bernard
Shaw

In message , Bill in Co
writes:
[]
I've tested System Restore on a few occasions, and it (generally) has done
pretty well, surprisingly. In some cases, some app or two needs to be
reinstalled, but that's no biggie, but I prefer not relying on it.

I don't think I've had to use it on my own machine, but have helped
others use it, and it does as yo say often work (-:.

But in the case of the OP, he may not have a better choice.

I prefer using ERUNT "when the need arises", but ERUNT is only a subset of
what System Restore can do (which is sometimes a useful thing).

Yes. I have it here, and do a save with it from time to time; I also
have BartPE ready to make it possible to restore with it if Windows
won't boot. So far I haven't _had_ to _do_ a restore with it, but it's
good to know I have the option - and yes, I did prove to myself (by
trying) that I _could_.

As with all backup strategies - from ERUNT through system restore to
full clone - knowing "when the need" is _going_ to "arise" is the main
difficulty (-:! I guess doing it regularly is best, but how regularly is
worthwhile is going to differ from user to user.

Best of all is to restore an image or clone backup of your system, of
course, which is what I routinely do after testing out some software app
that I may not want to keep.


(So you make the clone directly before the test install?)
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

It is dangerous to be sincere, unless you are also stupid. - George Bernard
Shaw

On Sun, 10 Mar 2013 09:33:21 +0000, "J. P. Gilliver (John)"
wrote:

In message , Paul
writes:
[]
Don't use really ancient restore points. Use one that is only
a few days old. System Restore does more than it needs
to, on WinXP, and you can lose data files (if they're
stored outside My Documents).

I've seen this statement (or ones very like it) before. So system
restore actually deletes files? Is that only from certain locations on
drive C, or what? When you say data files, I presume you mean ones
created by applications, such as documents, pictures, sound, video, or
whatever the application is there to handle.

*******

On a system where you cannot manage to run System Restore immediately,
you can follow this procedure.

"How to recover from a corrupted registry that prevents Windows XP from
starting"

http://support.microsoft.com/kb/307545

What that does, is repair the registry in two steps.
[]
(This post marked as keep.)


I've received some great information and suggestions in regards to my
initial post, but not one reply has covered the fact that all of a
sudden the system crashes when doing a registry check. As I said in
the initial post the check starts and proceeds and then suddenly
crashes. I would appreciate some info on why this is happening. I've
taken to heart the suggestion of not using these programs, but this
question remains.

Barry Bruyea wrote:
On Sun, 10 Mar 2013 09:33:21 +0000, "J. P. Gilliver (John)"
wrote:

In message , Paul
writes:
[]
Don't use really ancient restore points. Use one that is only
a few days old. System Restore does more than it needs
to, on WinXP, and you can lose data files (if they're
stored outside My Documents).
I've seen this statement (or ones very like it) before. So system
restore actually deletes files? Is that only from certain locations on
drive C, or what? When you say data files, I presume you mean ones
created by applications, such as documents, pictures, sound, video, or
whatever the application is there to handle.
*******

On a system where you cannot manage to run System Restore immediately,
you can follow this procedure.

"How to recover from a corrupted registry that prevents Windows XP from
starting"

http://support.microsoft.com/kb/307545

What that does, is repair the registry in two steps.
[]
(This post marked as keep.)


I've received some great information and suggestions in regards to my
initial post, but not one reply has covered the fact that all of a
sudden the system crashes when doing a registry check. As I said in
the initial post the check starts and proceeds and then suddenly
crashes. I would appreciate some info on why this is happening. I've
taken to heart the suggestion of not using these programs, but this
question remains.


If we knew all the answers about the Registry, there'd be no lengthy
arguments about registry cleaners.

The fact your system blows up, that tells me the registry parsing
software is not defensively designed. There can't be any cross
checks on the registry file format, such that the software can
safely detect a problem. As an example, say a record has a "length"
parameter, and it gets corrupted. The parser walks off the end of
one record, and into the middle of the next. When it starts parsing
there (looks first for the record type), it's going to go nuts. The
only way to stop it, is if the file format has multiple features
that delimit a record, and prevent a single corruption from blowing
things up. An example of a way of stopping it, would be if each record
had a checksum. Any record failing the checksum test, would stop
the parser (without crashing). If the file format isn't defensively
designed (i.e. we're relying on each and every length parameter to be
correct), then bad things are going to happen.

*******

Now, I was running the Kaspersky offline scanner, and noticed in the
screen icons, they actually have a Registry Editor in there. If you
were curious, you could run that Registry Editor, and see if it can
parse your registry :-)

http://support.kaspersky.com/8092

It's the 237MB file, an ISO9660 file. You can either load the software
on a USB key (which is how I'm running it on the laptop at the moment).
Or, you can burn a CD with the software, then boot the computer with it.
Then, you can try out their Registry Editor, and see if it works
any better than the Windows software :-) You don't have to actually
use it, just see whether the Registry Editor survived "munching"
on your current set of corrupted files.

Paul

In message , Barry Bruyea
writes:
[]
I've received some great information and suggestions in regards to my
initial post, but not one reply has covered the fact that all of a
sudden the system crashes when doing a registry check. As I said in
the initial post the check starts and proceeds and then suddenly
crashes. I would appreciate some info on why this is happening. I've
taken to heart the suggestion of not using these programs, but this
question remains.

Sorry, I had indeed lost in the noise that precise aspect of your
original query.

To forestall others asking the same (and apologies if your original post
answered this): what exactly do you mean by "doing a registry check" - a
clean (if so with what software), just trying to edit it (with regedit
or something else), or what.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"Going to church doesn't make you a Christian anymore than going to a garage
makes you a car." - Laurence J. Peter

J. P. Gilliver (John) wrote:

VanguardLH writes:

There is a concern regarding approaching the maximum size (in memory)
for the registry. That's when cleanup will help in providing breathing
room for subsequent pollution; however, rare few users that do registry

What would happen if you did reach it, anyway?

Depends on how the app was coded to handle an error from a registry API
call, assuming the app tested for an error. Too many times I've seen
code that called a function but never tested the return status.

Registry cleaners are generally considered snake-oil because very little
benefit and nearly immeasurable gain are achieved in exchange for a LOT
of risk. Yes, you can backup the registry but how are you going to
restore unless you load an OS to under which to run that registry
cleaner to restore those registry changes? Rare few users of registry
cleaners have an escape plan. They think a registry cleaner that saves

Many of the discussions I've seen regarding backup strategies, not just
registry cleaners, seem to omit this aspect: people go on about how
excellent this or that backup utility/strategy is, but omit discussion
of the restore-when-OS-not-bootable method it includes (assuming it
does). To be fair, I think most around now do include some mechanism,
but it gets left out of many - I'd say most - discussions of the
subject.

I haven't found a registry cleaner yet that plots an escape route should
the cleanup cause the OS to not load. They run under that OS (or
another instance of it if you plan on using bootable recovery media) and
may even offer to save a backup of the registry before applying changes;
however, if that OS doesn't load, you'll need another OS that does load
under which to run that registry cleaner to restore from backups. Alas,
most of the registry cleaners that I've seen only know how to restore
the registry backup into the active (loaded) instance of the OS under
which it is running. Their restore would need a means of pointing at
the file system on a slave drive to restore the registry files over
there.

Since the registry cleaners don't themselves generate rescue discs that
let you boot from those and run the registry cleaner from there (which
would still have to read the backups from wherever the user saved them
which, by far, is improperly saved in the same partition as the OS),
users go merrily saving registry backups using the registry cleaner,
doing the cleanup, and hope nothing breaks.

I'm sure even those that plan for disaster recovery when the OS won't
load started out that way. I probably did it that way, too, until the
first time after a cleanup and a following but later reboot the OS
wouldn't load, I had an unusable OS, didn't have a spare computer or had
setup alternate bootable OS discs, and got screwed. We often burn and
then learn. We all start out as newbs in any new endeavor.

There is one use for a registry cleaner that does have a benefit: on
rare occasion, it fixes a behavioral problem with an app. Typical

And, arguably, to save time for those who know what they're doing.

That's why I mention, for experts (well, those more proficient) with the
registry, it's a automated quick-find tool but the user is still
responsible for making the educated decisions on whether the registry
cleaner is allowed to apply all or some of the proposed changes.
Although I have CCleaner and have looked at other registry cleaners, my
first impulse and usually the only method for cleanup that I use is to
go into the registry myself. I still program HTML using Notepad, too,
instead of using a fancy color-coding auto-syntax programming IDE.

Barry Bruyea wrote:

I've received some great information and suggestions in regards to my
initial post, but not one reply has covered the fact that all of a
sudden the system crashes when doing a registry check. As I said in
the initial post the check starts and proceeds and then suddenly
crashes. I would appreciate some info on why this is happening. I've
taken to heart the suggestion of not using these programs, but this
question remains.

So what registry cleaners have you tried? You mentioned jv but I don't
know that one. Does it scan first, present a list of proposed changes,
and then halt until you select which changes to allow and then commit
those changes when you tell it to continue? What are the other 2
registry cleaners you have used?

That regedit.exe freezes sure sounds like something running (active) on
your host doesn't want you peeking in there. If it let you edit the
registry, and they weren't clever enough to know how to add non-ASCII
characters, like nulls or backspaces, into registry key names to block
you from seeing or editing those keys, changing permissions, or some of
the other tricks to hide or make impossible using regedit (which won't
show some of the hives because even admins aren't allowed there and some
tricks rely on parsing rules for that editor), then you could possibly
neuter that malware. They may even define policies that restrict you
from running regedit.

So what updated anti-malware software have you used to scan your host?

Have you clear the event logs, ran the registry cleaner(s) to have
it(them) crash, and then review the event logs for errors?

In message , VanguardLH
writes:
Barry Bruyea wrote:

I've received some great information and suggestions in regards to my
initial post, but not one reply has covered the fact that all of a
sudden the system crashes when doing a registry check. As I said in
the initial post the check starts and proceeds and then suddenly
crashes. I would appreciate some info on why this is happening. I've
taken to heart the suggestion of not using these programs, but this
question remains.
[]
That regedit.exe freezes sure sounds like something running (active) on
your host doesn't want you peeking in there. If it let you edit the
[]
I think we need to wait until he replies (if he does) to my query as to
what precisely he means when he says "doing a registry check". You have
assumed (a) he means he was using regedit (b) that it froze: he said
"crashes", which could be a freeze, or could be something else.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Happiness isn't happiness without a violin-playing goat. [Anna Scott (Julia
Roberts) in "Notting Hill" (1999)]

On Sun, 10 Mar 2013 16:17:29 +0000, "J. P. Gilliver (John)"
wrote:

In message , VanguardLH
writes:
Barry Bruyea wrote:

I've received some great information and suggestions in regards to my
initial post, but not one reply has covered the fact that all of a
sudden the system crashes when doing a registry check. As I said in
the initial post the check starts and proceeds and then suddenly
crashes. I would appreciate some info on why this is happening. I've
taken to heart the suggestion of not using these programs, but this
question remains.
[]
That regedit.exe freezes sure sounds like something running (active) on
your host doesn't want you peeking in there. If it let you edit the
[]
I think we need to wait until he replies (if he does) to my query as to
what precisely he means when he says "doing a registry check". You have
assumed (a) he means he was using regedit (b) that it froze: he said
"crashes", which could be a freeze, or could be something else.


A registry check, for instance with jv16, means the program throws up
what it consider bad or obsolete entries and asks you to either check
to remove or leave alone. During the process, the blue screen appears
and Windows crashes, reboots ok.

On 10 Mar 2013, "J. P. Gilliver (John)"
wrote in microsoft.public.windowsxp.general:

But, as you and others have said at length, the registry that is
actually in _use_ is the one in RAM. Thus anything that only
defrags the one on disc is not, surely, doing _anything_ useful,
since those files will be rewritten back at the full size next
time the RAM copy is saved back.

Some registry compactors deal with that issue. Just this morning I ran
NTRegOpt to see what happened. It compacts the registry to temporary
files, then instructs you to reboot. At bootup, the compacted copies
are moved into place.

Not that it made much difference - there was only a 1% decrease in file
size.

J. P. Gilliver (John) wrote:

In message , VanguardLH
writes:
Barry Bruyea wrote:

I've received some great information and suggestions in regards to my
initial post, but not one reply has covered the fact that all of a
sudden the system crashes when doing a registry check. As I said in
the initial post the check starts and proceeds and then suddenly
crashes. I would appreciate some info on why this is happening. I've
taken to heart the suggestion of not using these programs, but this
question remains.
[]
That regedit.exe freezes sure sounds like something running (active) on
your host doesn't want you peeking in there. If it let you edit the
[]
I think we need to wait until he replies (if he does) to my query as to
what precisely he means when he says "doing a registry check". You have
assumed (a) he means he was using regedit (b) that it froze: he said
"crashes", which could be a freeze, or could be something else.

No, I assumed the register cleaner(s) did some sort of check and they
crashed. He also tried to just load regedit.exe and it crashed
(although "crashed" may actually be something else terminating those
processes or policies used to prevent them from loading).

On Sun, 10 Mar 2013 14:15:59 -0400, Nil
wrote:

On 10 Mar 2013, "J. P. Gilliver (John)"
wrote in microsoft.public.windowsxp.general:

But, as you and others have said at length, the registry that is
actually in _use_ is the one in RAM. Thus anything that only
defrags the one on disc is not, surely, doing _anything_ useful,
since those files will be rewritten back at the full size next
time the RAM copy is saved back.

Some registry compactors deal with that issue. Just this morning I ran
NTRegOpt to see what happened. It compacts the registry to temporary
files, then instructs you to reboot. At bootup, the compacted copies
are moved into place.

Not that it made much difference - there was only a 1% decrease in file
size.


And even if the percentage was higher, it would scarcely have made any
difference, since the registry is never very large.