The system has reached the maximum size allowed for the system part of the registry

The system has reached the maximum size allowed for the system part of the registry. Additional storage requests will be ignored

If you get this error on a machine it's a major annoyance. There are plenty of potential issues as to why this may be happening, but I'm not going to get into those. This article is going to assume that the registry truly has reached it's breaking point through normal means. Also, as a disclaimer, messing with your registry without understanding what you're doing is very dangerous so if you do continue with this process be careful. This article is my version of MS KB 2498915

The trick to reducing the size of your registry files is to open them within regedit without having your main OS running and exporting them. You can do this with a WinPE boot disk if the device is a physical machine. In my case the server was actually a VMWare ESXi client, and the WinPE disk wouldn't boot. In that case what I did is shut down my server and open the virtual hard drive on another ESXi client to gain access to the files.This created a new problem, but it was fixable. Make sure to check that link beforehand if you'll be doing the same in a ESXi environment.

The files you need access to are in the C:\Windows\system32\config directory: Software, System, Default, etc. These are your registry files. Whether you boot from WinPE or use a 2nd computer, those files remain the same. However, you can look at those registry files to see what their sizes are. Whichever one is the largest is the one I would suggest starting with. In my example I'll assume you're shrinking the software hive too, but you can repeat these steps for any of the registry hive files.

In my case, the software file was 3-4x larger than any of the others so that's where I suspected I had the most free space to reclaim. Once you have access to the registry files through WinPE or a 2nd computer, open regedit.

Once regedit is open, click on HKEY_LOCAL_MACHINE to select it and then go to File->Load Hive... This will open a file dialog box, and here you'll want to navigate to the registry files directory from above and open the hive, which in this case we're using software. You will be prompted to give it a temporary name, which you can use whatever you'd like to refer to it. In my case I used the name toshrink.

After the hive has loaded, select it and go to File->Export... and save it somewhere. Do not overwrite the existing hive, just in case you need it again. Something like softwarecompressed would be a good name. At this point you'll have to let regedit run, and it could take a while. My software hive was ~180MB and it ran for somewhere between 30-60 minutes before completing. Smaller will run faster of course.

After the export process has completed, close regedit and then reopen it. Once it is open again, click the hive you loaded in HKLM and go to File->Unload Hive... This will unload it from the registry.

Now go to the location of your newly compressed hive file. In our example we have softwarecompressed, which should be smaller than the software hive we started with. Rename software to software_orig, and rename softwarecompressed to software. Place the compressed and newly renamed file into the C:\Windows\system32\config folder and then reboot your machine normally. This should load the system with the compressed hive file, and get rid of your maximum size allowed error.

For me the software hive was 192MB, and after this process it was 133MB. The other hives didn't shrink enough to make it worthwhile, but the compression on the software hive was significant.

Good luck

VMWare error: The parent virtual disk has been modified since the child was created

I needed to shrink the registry files on a ESXi guest (guest1), and in order to do so I shut it down and mounted the virtual disk on a separate ESXi guest (guest2). Once it was done, I removed the temporarily shared virtual disk from guest2 and went to boot guest1. I received an error that said "Cannot open disk: .... The parent virtual disk has been modified since the child was created". I then tried reverting to a snapshot and that failed, so for a minute I thought I may have just lost one of my servers. Fortunately this is something that can be fixed, and it wasn't too difficult.

The ESXi guest's virtual hard disk can consist of multiple files. What was happening is that the ID tag(s) saved in those files to tell the system which order to align those files in to create the complete hard disk were getting changed when I mounted it on guest2. To fix the problem I needed to sort through those virtual disk files and correct any mismatched ID tags. Here's how I did that

First, I had to enable SSH access to my ESXi host. You can also get in through the ESXi CLI too if you'd prefer. To enable SSH access to an ESXi host, you can do it from the direct console or from the vSphere Client. From the direct console, log in and go to Troubleshooting Options->Enable SSH. To enable it through the vSphere client, open the host and go to Configuration->Security Profile. Then in the Services section, click Properties, click on SSH, then Options. From there you can set the startup policy, and also start the service.

Once I had SSH access enabled, I logged into the host holding guest1. Now you want to get into the datastore where the virtual hard disk files are stored for the guest, and navigation commands are the same as you'd use in Linux. For me it was cd /vmfs/volumes/datastore1/guest1. Once I was in that directory I could use the ls command to list all the files. What I needed where the guest1.vmdk, guest1-0000001.vmdk, guest1-000002.vmdk, etc files. For my machine, I had guest1.vmdk, and then three add-ons, so four total virtual disk files to look at.

At this point you'll want to use your favorite text editor to open these files. Personally, I use vi, but you can use whatever you'd like that is available. Open each of the virtual disk files and note the value at the top for CID and parentCID, then close and move to the next. The parent CID of guest1.vmdk should be something like ffffffff. Once I had opened each of my files I had this


guest1.vmdk
CID: 32b76102, parentCID: ffffffff

guest1-0000001.vmdk
CID: 7d3d984f, parentCID: fa1f4813

guest1-000002.vmdk
CID: 49eb6c66, parentCID: 6e1b350e

guest1-000003.vmdk
CID: fa1f4813, parentCID: 49eb6c66

Now is where you get to solve the puzzle. Which CID or parentCID is incorrect and screwing up your virtual hard disk? I had to draw it out, but what I ended up with is

6e1b350e (???)<-49eb6c66 d3d984f="" fa1f4813="" guest1-000001="" guest1-000002="" guest1-000003="" p="">
For me it was that the parentCID value on guest2 was pointing to an unknown CID. Once I found that out, I opened guest1-000002.vmdk in vi and changed the parentCID value to the CID value of guest1.vmdk, 32b76102. Saved and closed, then booted up guest1 without any other problems.

I did try it a second time just to see, and in that case the same thing happened on the same file. It looks like when I mount the virtual disk in guest2, the CID value on the primary vmdk file gets changed. All the others stay the same, so if you can find the parentCID value that is going nowhere and change it, then you're back in business.


Articles I found that helped me come out with the solution

VMWare KB about hard disks failing to open

VMWare KB about resolving CID mismatch on virtual hard disks

Enabling ESXi Shell or SSH access to ESXi host

Editing VMWare config files