Subject What a registry scanner is counting when it reports a number of errors Covers Hive files · HKEY_CLASSES_ROOT · class registration · shared-DLL counts · hive backup We ran it No. We hold no copy and distribute none. Sourcing Microsoft documentation and KB · one archived Microsoft support policy · archived vendor pages for claims only Ledger rows R-01 … R-11 Open questions 3 → /mechanisms/unverified/ Published 2026-08-06 Last verified 2026-08-06 · documentation current for Windows 11 25H2

A hive drawn as a tree lying on its side. Left of the dashed vertical boundary, dense nodes: keys that something on the machine still resolves by name. Right of it, sparse nodes hanging off nothing: entries whose target was uninstalled and which no longer resolve. The boundary marks **referenced ↔ orphaned**. Both sides are the same file, the same bytes and the same lookup cost; the boundary is a fact about what asks for a key, not a fact about the key. The image carries no lettering.

A registry cleaner reports a count. Here is what it is counting, entry category by entry category.

The Windows registry is a small set of hive files, and Microsoft names them. Its hive table lists HKEY_LOCAL_MACHINE\SAM, \Security, \Software and \System, backed by files named Sam, Security, Software and System; HKEY_CURRENT_CONFIG, backed by the same System files; HKEY_USERS\.DEFAULT, backed by Default; and HKEY_CURRENT_USER, backed by Ntuser.dat, one of which is created per user profile. That table is headed “the standard hives” and is not a count of the files on disk: Microsoft’s own sentence is that most of the supporting files are in %SystemRoot%\System32\Config, and a user profile carries a second hive file beside NTUSER.DAT that the table does not list (§1). Microsoft publishes the file extensions beside each hive as well, and the fact that a .log file next to a hive is “a transaction log of changes to the keys and value entries in the hive”. None of that is a description of something that decays. It is a description of a database with a transaction log.

So when a scanner reports a number of errors, the interesting question is not whether the number is large. It is which of those files it read, which named keys inside them it decided were wrong, and what it expects to change by deleting them. Every one of those questions has a documented answer, and this piece walks the categories one at a time.

Verdict SUPERSEDED the size premise · UNVERIFIED the cleaning claim · UNVERIFIED the count In one sentence The registry-size argument stopped being true on the NT line and Microsoft documents no explicit space limit for it since Windows XP and Server 2003 (R-01); no primary source connects deleting stale class registrations to any counter that moves (R-02); and a scan result that reports a count with no per-item key path names no surface at all, which is the thing regulators acted on (R-03). What we will not say That Microsoft debunked registry cleaners. It did not. See §4.

§1Windows names every file the registry lives in, and they are ordinary files with a transaction log

Costs to leave it alone: 2 GB max per hive; system hive 50% of physical memory, 1.5 GB cap on x64
Costs to change it: key path ≤ 255 chars; tree ≤ 512 levels; value ≤ available memory
Cost of being wrong: event 333, event 1508: the hive does not load

A hive, in Microsoft’s own definition, is “a logical group of keys, subkeys, and values in the registry that has a set of supporting files loaded into memory when the operating system is started or a user logs in”. Beside each hive sit files with documented extensions: .log for the transaction log, .sav for a setup-time copy, and .alt for the one alternate copy of HKEY_LOCAL_MACHINE\System. That is the whole storage story for the standard hives, documented on one page.

Almost everything a cleaner reports lives in two places: HKEY_LOCAL_MACHINE\Software\Classes, inside the SOFTWARE hive, and HKEY_CURRENT_USER\Software\Classes, inside the logged-on user’s profile. What people call HKEY_CLASSES_ROOT is not a file: Microsoft describes it as a key that “provides a view of the registry that merges the information from these two sources”, user settings taking priority. A tool reporting on it is reporting on two hives at once and writing to whichever the documented merge rules pick.

Which file on disk backs the user’s Classes subtree is not on the hive page: that table gives Ntuser.dat for HKEY_CURRENT_USER and names no separate file for Classes. Microsoft answers it on a different page. KB 3048895 names Usrclass.dat and Ntuser.dat as the two per-profile files a logon access check is applied to, states that the first is “typically located along a path like” C:\Users\<user_name>\AppData\Local\Microsoft\Windows on current releases — that is %LOCALAPPDATA%\Microsoft\Windows — or the pre-Vista Local Settings\Application Data\Microsoft\Windows\UsrClass.dat, and tabulates the event logged when it cannot be opened: event 1542, “Windows cannot load classes registry file”. So the file Windows calls the classes registry file is UsrClass.dat, one per profile, and a scanner reporting on the per-user half of HKEY_CLASSES_ROOT is reading and writing that file rather than NTUSER.DAT.

State the size limits flatly, because they are the numbers the folklore is arguing with. A key path is capped at 255 characters, a tree at 512 levels, a value at available memory in the latest hive format and 1 MB in the standard one, and all the values of one key at 64K in total. A hive is capped at 2 GB, except the system hive, capped at 50 percent of physical memory up to 1.5 GB on x64. Views of the registry files are mapped in paged pool memory.

One sentence in that documentation links registry content to performance, and it is not about stale keys: “Long values (more than 2,048 bytes) should be stored in a file… This helps the registry to perform efficiently.” The documented concern is value size, not entry count, and no Microsoft page we fetched makes the count argument at all.

§2A bigger registry is not a slower registry, and the limit that once made it one was removed on the NT line

Costs to leave it alone: no explicit hive-space limit documented since Windows XP / Server 2003
Costs to change it: RegistrySizeLimit set non-zero re-imposes the old cap on XP–Win7 and 2003–2008 R2
Cost of being wrong: logon fails with “Insufficient system resources”, event 1500

Claim when the computer be used for a period of time, the registry becomes very large, serious impact on computer speed Archived vendor help topic, tlwinset.com/wineb/wh16.htm, capture 2013-09-24. Checked 2026-08-06 · Ledger row R-01

That claim was true once, on a different operating system. Windows 9x and Windows 2000 charged registry data against the paged pool, and Microsoft documented a RegistrySizeLimit value under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control capping how much of that pool the registry could take: by default 25 percent of a paged pool that itself defaulted to 32 MB, so 8 MB. Growing into that ceiling produced a real, visible failure, which is why the era’s maintenance advice was about size, and why Microsoft shipped a cleaner of its own for it (§4).

That ceiling now sits on the current page under a heading reading Windows 2000, and the paragraph above it ends the argument: for “Windows Server 2003 with SP1, Windows Server 2003 and Windows XP: There are no explicit limits on the total amount of space that may be consumed by hives in paged pool memory and in disk space”. A per-hive 2 GB cap arrived with Server 2003 SP2 and remains. Nothing in that sequence leaves room for a machine bought this decade to be near a registry size limit.

One caveat we will not suppress, because it cuts against us. KB 2567018 states that Windows Server 2003 through 2008 R2 — and, in its closing line, client XP, Vista and Windows 7 — still honour the old limit where an administrator has set RegistrySizeLimit to something other than zero, with event 1500, “Windows cannot log you on because your profile cannot be loaded”, as the documented failure and deleting the value as the documented fix. A registry-size failure does exist in the record, then. It is caused by writing a tuning value, which is what this product category does, and not by accumulating keys, which is what it says it fixes.

§3Every registry scanner counts the same handful of things, and each category has a different answer

Costs to leave it alone: an unregistered ProgID is ignored by Windows — documented, no effect
Costs to change it: 1 delete per item; 0 counters documented to move
Cost of being wrong: a live SharedDLLs count removed → the file it guards is deleted at the next uninstall

Claim Scan and clean up Windows registry by Windows Winset. Archived vendor capability index, tlwinset.com/help.htm, capture 2012-08-24. Checked 2026-08-06 · Ledger row R-02

The categories below are the ones every scanner in this class reports, from Microsoft’s own RegClean to whatever is sold this month. They are described here from the documentation of the surfaces rather than from any product, because the surfaces are documented and the products are not.

Four hops, two failure modes. A file name extension subkey names a ProgID; a ProgID names a CLSID; a CLSID names a DLL path under InprocServer32. The dashed boundary marks named in the hive ↔ must exist on disk. Left of it, a broken link is ignored by Windows and costs nothing. Right of it, a broken link is a call that fails at the moment something asks for the class. A scanner reports both as one error.

File name extensions with no handler. A subkey such as HKEY_CLASSES_ROOT\.myp holds one string: the ProgID of the application that opens it. Microsoft’s guidance for uninstallers is the fact that matters here, and it is explicit: applications that own a file type “should not attempt to remove that value when uninstalling”, and “Windows respects the Default value only if the ProgID found there is a registered ProgID. If the ProgID is unregistered, it is ignored.” So this category is stale by design, harmless by documented behaviour, and deliberately left behind on Microsoft’s instructions. A scanner counting it is counting compliance with a Microsoft guideline as an error.

Class registrations whose DLL is gone. A CLSID subkey carries an InprocServer32 subkey whose default value is the path to the DLL. Delete the file and the registration resolves to a path that is not there — a failure that surfaces when something asks for the class, not at idle. The documentation implies the cost of leaving it is one failed load at call time, which was going to happen either way, because what is missing is the DLL and not the key. It is also the category carrying the risk, since the scanner cannot see who is going to ask.

Uninstall entries for software that is gone. These live in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall, keyed by product-code GUID, and Microsoft tabulates every value Windows Installer writes there: DisplayName, UninstallString, InstallLocation, EstimatedSize and about fifteen more. A stale entry here is read by one thing, when you open the installed-programs list. Deleting it changes what that list shows and nothing else.

Shared-DLL reference counts. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs holds a count per file, and Microsoft documents the mechanism from the installer side: setting msidbComponentAttributesSharedDllRefCount (value 8) means “the installer increments the reference count in the shared DLL registry of the component’s key file”. The same page walks through what happens when the count is wrong: an application removes a component another application still needs. This is the one cleaning category with a documented, named route to breaking a machine — and the break lands at the next uninstall, possibly months later, which is why the advice survives. The damage is never attributed to the tool that caused it.

The MUICache entries, which almost every scanner reports, are the honest gap in this taxonomy. Searching learn.microsoft.com and support.microsoft.com for the key name on 2026-08-06 returned no Microsoft reference page — every result was a user-authored Q&A thread, which is not documentation. Third-party forensic references state a location for it; we are not repeating one, because we could not confirm the path, the data type or the default from a primary source. The category is UNVERIFIED until Microsoft documents it.

§4Microsoft says it does not support registry cleaners; it does not say they fail to make a PC faster

Costs to leave it alone: 0 — Microsoft publishes no registry maintenance schedule
Costs to change it: support scope: 3 sentences of disclaimer, 0 sentences of measurement
Cost of being wrong: reinstallation of the operating system, in the policy’s own words

The article everyone cites is KB 2563254, Microsoft support policy for the use of registry cleaning utilities, read by us in an archived capture on 2026-08-06. It contains, verbatim: “Microsoft does not support the use of registry cleaners.” “Microsoft is not responsible for issues caused by using a registry cleaning utility.” “Microsoft makes no warranty, implied or otherwise, about the performance or reliability of third-party registry cleaning utilities.” Its applies-to list runs from Windows XP to Windows 10 and the page metadata carries the date 2018-04-18.

Read what those three sentences are. A support-scope statement, a liability statement and a warranty disclaimer. Not one says a registry cleaner fails to make a computer faster — and in one place the article says the opposite of what it is quoted for: “A damaged Windows registry can exhibit a range of symptoms including excessive CPU utilization, longer startup and shutdown times, poor application functionality or random crashes or hangs.” Microsoft names damage as a cause of slowness, which is the premise the category sells against, then declines to warrant the products claiming to repair it. Citing this KB as Microsoft proving cleaners useless is an overreading, and we say so even though it suits us.

The article is also unpublished, and that is a finding. On 2026-08-06 the live URL took three redirects and landed on the generic support.microsoft.com/en-us/windows/ hub with no registry-cleaner text in it. The archived capture from 2023-12-06 returns HTTP 200 with the full body. So the most-cited document in this argument survives only in an archive, and every page that links it live is now linking a redirect.

Microsoft shipped a registry cleaner of its own, which almost nobody states when quoting the support policy. The KB is numbered Q147769; it describes RegClean 4.1a as analysing “Windows Registry keys that are stored in HKEY_CLASSES_ROOT”, recording what it removes in an Undo.reg file, and it concedes in its own text that running it could stop other programs working. Identical scope to §3’s first two categories, from Microsoft, in the Win9x era. We could not read that KB at any Microsoft URL: support.microsoft.com/en-us/help/147769 and support.microsoft.com/kb/147769 both returned HTTP 404 on 2026-08-06, so the text above comes from a third-party archive and is UNVERIFIED against a Microsoft-hosted copy.

§5Microsoft’s current and enforceable position is about the scan, not about the cleaning

Costs to leave it alone: criteria page dated 2026-01-29, last updated 2026-03-24
Costs to change it: NOT ESTABLISHED — see §5: Microsoft publishes no detection counts by category
Cost of being wrong: classification as unwanted software, enforceable through Defender

The better citation is live, current and has teeth. Under Unwanted software → Lack of choice, Microsoft’s classification criteria name three behaviours that get software classified as unwanted: “Display exaggerated claims about your device's health.” “Make misleading or inaccurate claims about files, registry entries, or other items on your device.” “Display claims in an alarming manner about your device's health and require payment or certain actions in exchange for fixing the purported problems.”

Notice which half of the product that describes: not the deletion, but the scan, the count, and the price attached to the count. It matches the shape of the regulatory record, where what has been punished is the fabricated diagnosis rather than the failure to deliver speed. The eight questions at the top of the Ledger are built on that distinction, and the fifth and sixth are the two a count-only scan cannot pass.

Row R-03 exists for this. Its SURFACE IT MUST TOUCH column reads: none named. A result that reports a number of issues and no per-item key path has named no surface, so it can be neither verified nor refuted — which is why the row is UNVERIFIED rather than NO-OP, and why this is the most useful test a reader can apply in the thirty seconds before paying for anything.

§6The entire published measurement record in this argument fits in one short list

Costs to leave it alone: NOT ESTABLISHED — see §6
Costs to change it: 10 s off one desktop boot, 0 s on the laptop, stopwatch, updated 2016-07-26
Cost of being wrong: 0 academic studies; 1 independent test still readable

PCWorld, Steve Bass and Josh Norem, updated 2016-07-26, read by us 2026-08-06. Five products, three machines, a stopwatch on boot and application launch. Their result, in their words: “Using a stopwatch with our desktop system, we saw 10 seconds shaved off its boot time.” And, on the second machine: “the laptop we tested didn't show any improvement.” Their answer to the headline question is “emphatically and unequivocally, maybe.” Note the qualifier they attach themselves: that desktop had a spinning platter, not a solid-state drive. This is the only fully readable independent measurement in the record, and it is positive on one machine of three.

Windows Secrets, Fred Langa, 2011. The comparison the rest of this argument’s coverage rests on, including the piece below. UNDETERMINED: it is unreadable at every URL we hold, and summarising a study from other people’s summaries of it is not something we will do. It sits at /mechanisms/unverified/ as an open question; if you hold a readable copy the address is the contact form.

How-To Geek, Chris Hoffman, dated 2016-05-17, read by us 2026-08-06. It runs no measurements — its empirical basis is the 2011 comparison above — but it carries the most useful falsifiable number anyone has published here, and Hoffman gets the credit in the body rather than in a footnote. A commercial cleaner reported 21.33% data fragmentation on a volume where “the Windows Disk Defragmenter tells us we have 2% fragmentation”, because the product counted fragmented files instead of measuring fragmented space. One machine, two instruments, an order of magnitude apart, and the whole gap is in the definition.

Ed Bott, 2005-04-19, read by us 2026-08-06. Not a measurement, and he says so: “I have never seen any evidence that routine ‘cleaning’ of the registry has any positive effect.” Cite him as evidence that the tests did not exist, from somebody looking for them at the time. We found no academic or independent-lab study of registry cleaning, and no benchmark from Ars Technica, Tom’s Hardware or AnandTech — worth stating because the belief that one of them settled this is common, and we could not locate the article.

That is the whole record: one readable test, positive on one machine of three; one unreadable test; one credited number about a different metric; and one dated absence of evidence. The consensus is far larger than its evidence base, and repeating it louder is not our job.

§7Two statistics now circulating about registry cleaners have no source at all

Costs to leave it alone: 0 sources located for either figure
Costs to change it: 2 minutes: search the claimed body of literature, find nothing
Cost of being wrong: 1 fabricated figure, laundered into every downstream summary

Two specific, confident, extremely quotable figures are circulating in search summaries right now. The first asserts an absence of empirical evidence across a named number of peer-reviewed human-computer-interaction studies over a stated range of years. The second asserts a percentage of registry-related blue-screen failures in enterprise environments attributed to third-party cleaners, sourced to Reliability Monitor. Both are fabricated, both trace to a single machine-generated page, and we are deliberately not restating either number here, because restating it is how it travels.

The first fails because that body of literature does not exist; there is no such set of peer-reviewed studies to have been surveyed. The second fails on the instrument: Reliability Monitor is a per-machine reliability history, and it does not produce aggregated enterprise attribution of stop errors by third-party product. A number cannot be computed from a tool that does not compute it.

A figure with a specific decimal and a plausible-sounding instrument travels further than an honest “we could not measure this”, and it travels fastest through summaries that fetch nothing. Every number on this page carries a fetch date for that reason.

§8The genuinely useful feature in this category is the backup, and a backup is not a cleaning feature

Costs to leave it alone: 0 bytes: Windows takes no scheduled hive backup by default since version 1803
Costs to change it: 1 command: reg save HKLM\SOFTWARE C:\bak\SOFTWARE.hiv
Cost of being wrong: a partial export restores part of a change

Claim Backup and restore whole Windows registry by Windows Winset. Archived vendor capability index, tlwinset.com/help.htm, capture 2012-08-24. Checked 2026-08-06 · no Ledger row yet, flagged for the next revision

Claim It do not backup all setting about your computer, it only backup registry items in the list Archived vendor help topic, tlwinset.com/wineb/wh16.htm, capture 2013-09-24. Checked 2026-08-06 · no Ledger row yet, flagged for the next revision

Of everything that 2012 capability index advertises, this is the entry describing something worth having, and it is the one nobody markets. The same vendor draws the distinction itself on the archived help topic quoted here: the backup button offered before a clean writes only the items in the scan list, and the topic sends a reader wanting everything else to a separate whole-registry backup function. That is the difference between an undo list and a backup, stated by the product in 2013.

What can “the whole registry” mean while Windows is running? Microsoft documents three answers, all in-box. reg save <keyname> <filename> writes a hive file for a subtree, and its remarks state the discipline plainly: save the parent subkey before editing, and restore it with reg restore if the edit fails. Under the covers those are RegSaveKeyEx and RegRestoreKey, and both hive formats they write are documented. regedit’s File → Export is the same idea for a subkey in a text format, and it is the only method Microsoft’s consumer-facing backup article describes. A system restore point captures registry state inside a wider snapshot, and it is what Microsoft now recommends for recovering a corrupt hive (§9).

Our judgement, marked as judgement: a tool that takes a restorable hive backup before it touches anything, and can put back one change at a time six months later, is doing the only unambiguously valuable work in this category. It is also work that needs no scan, no count, and cannot be sold with an alarming number.

§9Windows stopped backing up your hives on a schedule, and there is a documented switch that turns it back on

Costs to leave it alone: the RegBack hives are present and 0 KB each since version 1803
Costs to change it: 1 REG_DWORD set to 1, plus 1 restart
Cost of being wrong: WinRE recovery finds 0 KB files where a support article told it to look

The release and the article number are both pinned, which is what this section was held on. Microsoft’s KB 4509719, The system registry is no longer backed up to the RegBack folder starting in Windows 10 version 1803 — page dated 2026-02-12, read by us 2026-08-06 — states: “Starting in Windows 10, version 1803, Windows no longer automatically backs up the system registry to the RegBack folder. If you browse to the \Windows\System32\config\RegBack folder in Windows Explorer, you will still see each registry hive, but each file is 0 kb in size.” The stated reason is disk footprint. The stated replacement is a system restore point.

The switch is documented on the same page: HKLM\System\CurrentControlSet\Control\Session Manager\Configuration Manager\EnablePeriodicBackup, REG_DWORD, value 1, followed by a restart. Windows then backs the registry up to RegBack at restart and creates a RegIdleBackup scheduled task under Microsoft\Windows\Registry to manage later ones.

The consequence is the most practically important dated fact on this page. Microsoft’s own startup-troubleshooting article still offers, as Method 5, copying the files from C:\Windows\System32\config\RegBack into config to restore a system hive — and then carries the note that those files are empty from version 1803 onward. Anyone following a decade of copied recovery instructions finds five zero-byte files at the moment they need them most. The fix is to have taken a restore point or a reg save beforehand.

§10When a registry really does fail, it fails in ways a cleaner did not cause and cannot repair

Costs to leave it alone: NOT ESTABLISHED — see §10: Microsoft publishes no hive-corruption rate
Costs to change it: 1 restore point, or 5 hive files copied back from WinRE
Cost of being wrong: “Unable to boot due to system hive missing or corrupted”

Three documented failure modes exist, and entry count is not one of them.

The hive will not load at boot. Microsoft’s startup troubleshooting article lists Unable to boot due to system hive missing or corrupted among the boot-loader-phase errors, and describes what the kernel is doing at that point: it “loads the system registry hive into memory” before anything marked BOOT_START. The documented repair is to restore the hive.

The registry cannot complete an I/O operation. Event 333: “An I/O operation initiated by the Registry failed unrecoverably. The Registry could not read in, or write out, or flush, one of the files that contain the system's image of the Registry.” A storage or resource failure surfacing through the registry, not a registry failure.

A profile hive will not load. Events 1500 and 1508 from the user-profile service: “Windows was unable to load the registry. This problem is often caused by insufficient memory or insufficient security rights”, naming the specific ntuser.dat involved. Permissions and resources again, not accumulation.

The pattern is the same across all three: real registry failures are named, logged, and repaired by replacing a hive. None is addressed by deleting stale class registrations, and no product in this category advertises fixing them, because that is not what it does.

§11Our answer: the deletion is usually harmless and usually pointless, and the scan is where the problem sits

Costs to leave it alone: 0 documented cost in any Microsoft source we fetched
Costs to change it: NOT ESTABLISHED — see §6: 1 readable measurement, 1 machine of 3
Cost of being wrong: asymmetric: unmeasured upside against a documented reinstall

Stated as judgement, because it is judgement and not documentation. We think deleting a stale file-type association or an uninstall entry is very probably harmless and very probably worthless, and that the asymmetry is the whole argument: the upside is bounded by a measurement nobody has produced at scale, the downside by Microsoft’s own sentence about reinstalling the operating system. An unmeasured gain against a documented catastrophic tail is a bad bet even when the tail is rare.

The deletion is not where the interesting problem is. The scan is the product. The count is what is sold, what is priced, and what Microsoft’s current criteria name as grounds for classifying software as unwanted. A tool showing every key path it proposed to delete, letting you refuse each one, and saving a restorable hive first would be defensible — and could not print a frightening number, which is why almost nothing here is built that way.

To check any of this against your own machine rather than against us, the instruments are already installed, and the eight questions at the top of the Ledger are the buyer’s version of this page in about ninety seconds.

§12Standing, so you can see which sentences are which

Costs to leave it alone: 11 sections, 24 sources, all fetched 2026-08-06
Costs to change it: corrections published at the same prominence as the original claim
Cost of being wrong: 3 items below we could not settle

Standing 2026-08-06 Documented The standard hive list and their supporting files, and UsrClass.dat as the per-profile classes registry file named by KB 3048895; the absence of an explicit hive-space limit since Windows XP and Server 2003, and the 2 GB per-hive cap that replaced it; that an unregistered ProgID is ignored; the SharedDLLs reference-count mechanism; the RegBack change at version 1803 and its EnablePeriodicBackup switch; the three sentences of the retired support policy; the three unwanted-software criteria; events 333, 1500 and 1508. Inferred That a broken CLSID costs one failed load at call time rather than anything at idle — this follows from InprocServer32 holding a path that is resolved when the class is requested, and Microsoft does not state the cost in those words. Our judgement That the risk is asymmetric and the scan rather than the deletion is the defect in this product category (§11); that a backup-first, per-item, restorable tool would be defensible (§8). Not established (1) MUICache — no Microsoft documentation of the key, its location, its type or its default; searched 2026-08-06. (2) KB Q147769 on RegClean — HTTP 404 at both Microsoft URLs we checked; our description comes from a third-party archive of the KB text and is UNVERIFIED against a Microsoft-hosted copy. (3) The 2011 Windows Secrets comparison that most coverage rests on — unreadable at every URL we hold, so we neither summarise nor rely on it.

§13Sources and method, with the date each one was read

Costs to leave it alone: 24 numbered sources, 1 access date: 2026-08-06
Costs to change it: 2 sources are archives because the originals are gone
Cost of being wrong: 1 KB unreadable at Microsoft, reported rather than cited as primary

Method. Every source below was fetched and read by us on 2026-08-06, which is the access date for all of them; the Microsoft pages were read in preference to any coverage of them, and where a page had been unpublished we say so rather than citing the redirect. We have not run Windows Winset or any product in this category, we hold no copy of any of them, and nothing on this page is a report of using software. Three things could not be verified and are listed under Not established above rather than smoothed over here.

Registry hives (Win32), for the hive list, the supporting-file extensions and the transaction log.
Registry storage space (Win32), for the paged-pool mapping, the 2 GB hive cap, the system-hive limits and the Windows 2000 RegistrySizeLimit heading.
Registry element size limits (Win32), for the 255-character key path, the 512-level tree and the 2,048-byte value guidance.
Registry files (Win32), for the standard and latest hive formats and RegSaveKeyEx / RegRestoreKey.
HKEY_CLASSES_ROOT key (Win32), for the merged view and the write-precedence rules.
File types (Win32 Shell), for extension subkeys, and for the uninstall guidance and the unregistered-ProgID sentence.
InprocServer32 (Win32 COM), for the CLSID to DLL path hop.
Windows Installer properties for the Uninstall registry key, for the key path and its documented values.
Component table (Windows Installer), for msidbComponentAttributesSharedDllRefCount and the shared-DLL reference-count behaviour.
Registry Size Limit functionality is still honored if the RegistrySizeLimit registry key is set (KB 2567018), for the surviving limit and events 26, 333, 1500 and 1508.
The system registry is no longer backed up to the RegBack folder starting in Windows 10 version 1803 (KB 4509719), page dated 2026-02-12.
Windows startup issues troubleshooting, page dated 2026-02-12, for the boot-phase error list, Method 5 and the kernel loading the system hive.
reg save, for the syntax and the save-before-editing remark.
How to back up and restore the registry in Windows, for the export and import procedure.
How Microsoft identifies malware and potentially unwanted applications, page dated 2026-01-29 and updated 2026-03-24, for the three Lack of choice bullets quoted in §5.
Microsoft support policy for the use of registry cleaning utilities (KB 2563254), archived capture 2023-12-06, HTTP 200. Unpublished by Microsoft: the live URL took three redirects to the generic Windows hub when we checked it.
KB Q147769, RegClean 4.1a Description and General Issues. Not readable at Microsoft: support.microsoft.com/en-us/help/147769 and support.microsoft.com/kb/147769 both returned HTTP 404. Read at a third-party KB archive and reported as a claim, not cited as documentation.
How to clean your Windows registry, Steve Bass and Josh Norem, PCWorld, updated 2016-07-26, for the stopwatch method and the ten-second figure.
PC cleaning apps are a scam, Chris Hoffman, How-To Geek, dated 2016-05-17, for the 21.33% against 2% fragmentation comparison.
Why I don’t use registry cleaners, Ed Bott, 2005-04-19, for the stated absence of evidence.
Archived Windows Winset capability index, tlwinset.com/help.htm, capture 2012-08-24.
Archived Windows8 Winset help topic, registry, tlwinset.com/wineb/wh16.htm, capture 2013-09-24.
Windows registry for advanced users (KB 256986), page dated 2026-02-12, for the 64K per-key value total, the merged-view description and the Registry Editor warning that incorrect modification “might require that you reinstall the operating system”.
Profile loading fails (KB 3048895), page dated 2026-02-12, for Usrclass.dat as the second per-profile hive file, its documented location under AppData\Local\Microsoft\Windows, and event 1542, “Windows cannot load classes registry file”.

Ledger rows this article maintains: R-01, R-02, R-03, R-04, R-05, R-06, R-07, R-08, R-09, R-10, R-11. Rows R-04 to R-11 are registry writes rather than registry cleaning — a menu delay, a scheduler quantum, a last-access flag — and each one is a separate claim with its own verdict. A product that does both is two products.

§14Where to go next, and why each one follows from this page

Previous Free RAM is the wrong number — why Windows works hard to keep your free memory low, and what a memory cleaner on a timer does to your machine. HARMFUL
Next What a service costs when it is doing nothing — an idle service costs a countable number of threads, handles and kilobytes, and here is how to count them. TRADE