Little Green Delusions
-
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.
-
Working with Windows 7
I have been working with Windows 7 for the last few days now. A not-quite-legal copy, to be sure, but it's just a temporary situation - I'm just trying to determine if I am even going to waste my energy with it, or if I am simply going to continue to recommend XP (usually XP 64-bit) to my clients.
My first impressions are that Microsoft really did solve the performance issue. It runs nearly as fast - and in some rare situations, even faster - than Windows XP 64-bit. That alone has nearly made me begin to recommend this release to clients.
Where they failed to fix glaring problems is with the User Interface. No, I'm not talking about Aero. It might be a performance hog, and nothing more than some pretty on-screen baubles, but it doesn't impact usability all that much (and in some cases even improves on it!). What I am talking about is how people access the nuts and bolts of how Windows is configured.
Microsoft seems to be obsessed with "dummy-proofing" Windows 7 by adding roadblocks, unnecessary warnings and obscuring paths to vital system settings. Take display settings for one. In XP, it was as simple as a right-click anywhere on the Desktop, and then selecting "Properties" from the resulting drop-down menu. You were presented with a SINGLE window with 5 tabs holding all the desired display settings. Now in Windows 7 these settings are buried much deeper - at least two screens and a dogpile mess of confusing links later.
There are other problems throughout the entire OS. While I appreciate the new folder sidebar in Windows Explorer, I desperately miss the very power-centric folder tree it used to contain. It takes a map and two guides to find out how to reach the list of protocols for a network card, whereby it was available via two clicks in XP. And the Start Menu, with its All Programs menu shoehorned into it -- don't even get me started on that!!
This all reminds me of a favourite quote: "The problem with people who try to make things completely idiot proof, is that they always underestimate the ingenuity of complete idiots." The new UI that Windows 7 inherited from Vista is nothing more than a big frustration. It gets in the way of what I need to do when examining and diagnosing a computer, and it does nothing but slow me down if I am using Windows 7 by myself. Microsoft should have implemented a "power users" setting which could eliminate many of these frustrations and bring the UI back to more of an XP-like efficiency.
But hey. This is Microsoft we're talking about. When have they ever not taken two steps sideways for every step forward?
-
The first post…
Right now, I have installed AtomSite v1.1 in order to test its capabilities. So far, I am impressed with their ambitions, but disappointed in their progress. Much of the backend (the "dashboard") remains unusable, and requires manual editing of XML files. In fact, even the 'delete' buttons (in the blog area, for example) appear to not work, despite the install-checks (which include checking if a file can be deleted) coming back as all passed.
Plus, I seem to have to write out my posts in raw HTML. This is NOT user-friendly. I am surprised that a lot of things (slug creation, textarea formatters such as TinyMCE) aren't even automatically included in the default install.
I'm going to play around with this, and see if I can't fix some of the more glaring and simple problems. Please forgive me if this site remains butt ugly in the near future.