Windows 7: "Registry area appears locked. Cannot continue" error

Hi,

I've just about completed the migration of my XP programs to my new Windows 7 x64 installation. All my programs work (astronomy related) except for one - MaxPoint by Diffraction Limited. The program installs correctly (no errors), but when I run it for the first time, I get a "Registry area appears locked. Cannot continue." error.

I've tried everything I could think of - running the program as an Administrator, setting the Compatibility to XP (SP2 and SP3), copying over the "HKEY_CURRENT_USER\Software\Diffraction Limited\MaxPoint" key from the XP install, but nothing works. I thought that it may be Kaspersky Internet Security 2009 that might be causing the problem, but after uninstalling KIS and then installing MaxPoint, I get the same error

This is my only program that won't run under Windows 7. Of course, the support organization for MaxPoint says that they have no problems installing and running MaxPoint on their Windows 7 x86 and x64 installations Does anyone have any idea as to what I can do next? I really don't want to keep XP around, since my other programs run perfectly under Windows 7.



Thanks.

Mike

Try running it in compatibilty with vista, select run as an administrator also - since the fix is for vista maybe it will work with those settings (I read you have already used administrator and xp, but who knows, also did you try just administrator?):
When I run MaxPoint in Windows Vista, I get the error "Vista - Registry appears locked...". How do I fix this?

Hi,

I've tried Compatibility with XP SP2/3, Vista, and Vista SP1/2 without any luck. My problem sure sounds like the helpdesk article that you cited, but for the life of me I can't get it to work.

Just to make sure I'm not imagining things, I went over to my old PC and verified that MaxPoint runs OK under XP SP3. It does. I even created another Admin user and installed it there, but no luck. Maybe a registry key it created has the wrong permissions? If so, I might be able to change it. But how to find out which key; that's the $20K question

Mike

You can easily find software in the registry - just expand HKEY CURRENT USER and HKEY LOCAL MACHINE go to SOFTWARE, and expand find max point / permissions and see if you can find anything.
Or do this - find a shortcut to the program right click it - properties - security - advanced - there is permissions you can alter you might even take ownership - owner - edit .
Set up a restore point before you start - or make sure you can return permissions etc to normal as they might not be returned after restoring - the registry would however. You can also export folders etc in the registry and just click on them to return to normal.

Thanks for the help; I'll try all your tips.

Michael

This is strange - MaxPoint created a registry entry under HKEY_CURRENT_USER but not under HKEY_LOCAL_MACHINE

There is nothing under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Diffraction Limited\ , but my other Diffraction Limited programs created entries under this key. I'm not sure what to make of that.

Michael

Hi,

just wanted to post back that my situation is resolved to the point that I can still use Win 7 x64 and run MaxPoint successfully. Here's what I found out after a month of debugging with tech support at Diffraction Limited (the folks who wrote MaxPoint):

Evidently, the real Administrator account (which I unhid and used as my main account) does not set the registry permissions correctly upon installation of MaxPoint (nothing under the Security tab, the Owner is undetermined). Even after manually setting up the owner for the main key and subkeys (HKEY_CLASSES_ROOT\Wow6432Node\Interface\…), permissions failures continue to occur when the program tries to access and update these keys. However, if you create a user account with Admin rights and install MaxPoint from there, MaxPoint runs fine The strange part is that if you now log into the real Admin account and try to run MaxPoint (which you just installed under the new user Admin account), MaxPoint will still *not* run, getting similar permissions errors Every other program that I have installed under the real Admin account runs fine except this one.

My solution is to create a user account with Admin rights and install MaxPoint from there, then reregister my software under this new user account. That got MaxPoint working again under this new user account, and transferred all my program registrations over to this new user.

This is definitely a better option than downgrading to Win 7 x86 (which installs and runs MaxPoint fine under the hidden Admin account), which would necessitate a reinstallation of all my software. I really didn't want to do that.

Michael

wow this took a while and should help others.

I know; it's crazy

I've used the Administrator account ever since there was one one; I've never experienced something like this before. That's why it took so long to debug; neither one of us could believe that it was the Administrator account that was causing the problem. We tried everything else we could think of, including putting in debugging messages into the program to determine exactly where the failure occurred. It only dawned on us that the real Admin account might be the problem when the support person couldn't duplicate the errors using a fresh Windows 7 x64 partition (the same as I started with). It's only after he said that he's using a User Admin account (their normal procedure there at Diffraction Limited) that we began to wonder if the real Admin account might be the culprit. Now, the MaxPoint program hadn't been compiled since 2003, and the InstallShield is from that time also, but there was NO error during installation, only execution.

Personally, I think it has something to do with how Microsoft fudged the registry with all this WOW6432Node crap to allow 32-bit programs to run in a 64-bit environment. Any 32-bit program that writes hard registry paths to the registry is screwed royally. This is proved by the fact that the InstallShield from 2003 did not assign the correct permissions for the registry keys that it built under the real Admin account. This is the first time I've ever encountered a program that, while running fine under a User Admin account (permissions-wise), would not run under the real Admin account. Of course, this is the first time I've used an MS 64-bit OS too.

The fact that the real Admin account is needed to fix permissions problems with installs/reinstalls of Office 2007 makes me more suspicious of all this registry and permissions hocus-pocus that's occurring in the background. I'm hoping that with the release of SP1, this problem will be fixed.

Michael

Mike,

I've experienced the same thing. I can't fully uninstall a program, or reinstall the program either as the locked section blocks Windows Installer from replacing files there in the normal installation process. By going through an extended, time-consuming series of steps, you still can access these files in Registry Editor, Take Ownership of each separate file and grant yourself Full Control of "this key and subkeys".

You have to do this individually for each entry, you can't batch the Change Properties process from a higher position on the tree--the frozen sections still reject any changes. It would be great if someone could write a program that could break through the "No Permissions" parts, or automate the more time-consuming process?