Little Green Delusions - For July 2009
-
Registry Hive Madness
Came across a small problem with a client of mine. Turns out her nice new installation of XP 64-bit crashed, big-time. It was throwing the following issue:
The registry cannot load the hive (file):
\SystemRoot\System32\Config\SOFTWARE
or its log or alternate. It is corrupt,
absent, or not writable.Well, many of the suggested solutions available on the net were largely unavailable to me.
I could have used the registry hives in %WinNT%/repair/, but these were created upon the first successful boot of the system - they were massively out of date. And even when I tried to use them in the manner suggested (pulling the drive, connecting it to my computer, renaming the most recent SOFTWARE hive and putting the first-load backup in its place), the system would still throw the same error.
I could have reinstalled, but that was a lot of work for such a simple problem.
I could have used the versions available in System Restore (and since the system wouldn't even boot into Windows, it would have to be a rename-and-copy, as before, since an actual Restore would be impossible to do). Problem is, my setups are so well constructed and maintained that I usually turn off System Restore - it ends up being a colossal waste of space and a major performance drain. Especially when it sucks up 20% of a drive which is already 60% full.
However, I believe that I managed to do something that got it back up and running. Now, this may not work for everyone (and it may have only worked in my case because the corruption may have been VERY minimal!), but it is worth a try.
Pull the drive from the computer that it is in. Find one with the same O/S (in my case, XP 64-bit). Connect it to that computer. Open up Regedit on the host computer, and open the hive in question that exists on the guest drive (you need to be in the root of HKEY_USERS or HKEY_LOCAL_MACHINE to do this). When I did so successfully (there were no errors), I was truly stumped. If the hive was seriously corrupted, it shouldn't have opened up at all!
I even ran Ccleaner, but it came up with nothing that existed within the key in question (a loaded hive comes up as a key within the section you load it into). Resigned to do a full reinstall, I unloaded the hive, unmounted the drive, and put it back into the client's computer.
As a final last gasp, I made one more attempt to boot into Windows.
It worked.
I can only assume that mounting the hive managed to clean up or eliminate any corruption that existed within it. I can also only assume that serious corruption (as in, major sh*t) would prevent the hive from being loaded in the first place. So if you can load the hive, you may have corrected the corruption.
Give it a whack, and comment below. I would love to hear any success stories.
-
We’re off to see the wizard…
It seems that I have managed to make most of AtomSite function on my server by now. It has been a frustrating adventure, full of cranial depilation and temple-to-masonry impacts.
The trick is to NOT use the binary. There is a cruftload of material missing from it, not least the Javascript used to make much of the basic functionality possible. Try deleting a post when using the binary version -- you won't get far.
When I went to use the Source, I ran into another problem. Good luck getting it to work with Visual Studio 2005. I also struck out with Visual Web Developer Express 2008. When I finally installed VS2008, I ran smack into a massive problem: while the main AtomSite solution would open, the WebCore project would not -- and it is the linchpin of the entire source!
When loading up the entire app (for the first time, unmodified), I always got the following problem:
The project file "C:/ … /WebCore.csproj" cannot be opened. The project type is not supported by this installation.
I "solved" it (quotes intentional) by editing the WebCore.csproj file and removing these two entries:
{D0B348D5-387D-46EF-BD9A-DC3C25DD68B9}
{603c0e0b-db56-11dc-be95-000d561079b0};{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}However, once I did this I was unable to "Publish" this site either through a right-click on the WebCore project, or via the Build drop-down menu. Unfortunately, this site must be created using the Publish functionality -- it won't be usable any other way.
Once I wiped my original Source copy and extracted a new one, I replaced the second line above with the following:
{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}Once I did this, not only was WebCore able to load with the rest of the AtomSite solution, but I was also able to publish via a right-click on the WebCore solution.
Now, of course, I am running into another problem. It seems that most of the project's contributors are from the States. While this is normally not the problem, it is a very big problem when it comes to dates. It appears that many of the date functions within the site make use of highly regional-specific U.S. date formats - specifically the MM-DD-YYY format. Unfortunately, my server makes use of the international ISO 8601 date standard, which uses YYYY-MM-DD. This causes any post submission to crash the site unless I manually edit the publish date to conform to the ISO 8601 standard.
Will I fix this now? Hell no. It's 0110hrs, and I need my beauty sleep. Cheers.