Tech Line

Registry Rejection

Troubleshooting Registry write errors during software installation -- a tale of rejection and acceptance.

Chris, I have been trying to install software for days without success, and the vendor’s support line has been of little help. When I attempt to install the software, I receive an error 1406: "Could not write value InprocServer32 to key \CLSID\...." The message then asks me to verify that I have sufficient access to that key. I’m a local administrator, so I can’t see why I would not have sufficient rights. I do not want to rebuild my system just to install this software; I want to fix whatever is preventing the installation. How can I see what is preventing access to the Registry if I’m the administrator?
— David

Tech Help—Just An
E-Mail Away

Got a Windows, Exchange or virtualization question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to the MCPmag.com editors at mailto:editor@mcpmag.com; the best questions get answered in this column and garner the questioner with a nifty MCPmag.com baseball-style cap.

When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message, but submit the requested information for verification purposes.)

I understand your frustration, David. Sometimes I wish software vendors had to follow the same advertisement rules that pharmaceutical companies must adhere to. As a computer, it would be nice to know what side effects you might experience before the software enters your system.

Being that David had local administrative access, I had him analyze Registry access using Regmon. The idea here was to ensure that no other application was locking access to the Registry keys that the installation program was attempting to access. When Regmon opened, I first had David set a filter similar to HKCR\CLSID\{D27CDB70-AE6D-11cf-96B8-444553540000}\* and had him select all of the logging checkboxes. Note that the specific filter path would be dependent on the Registry key in which he was denied access.

David then reran the installation and received the same error message. This time, he could see in Regmon that the only process that was accessing the key was msiexec.exe. Since this was the installer application itself, we were able to confirm that the key was not being locked by another process. Another way to view process locks on a Registry key is to use Sysinternal's Process Explorer.

This was starting to look like nothing more than a permissions problem, but before checking the permissions of the key, I had David first check the Application event log for errors. Sure enough, the Application log listed several errors with Event ID 11406. In the event description, it stated, "Verify that you have sufficient access to that key."

So at this point it was certainly clear that this was a permissions problem, as unlikely as that normally would be for a local administrator running an installation program that was installing as the "NTAUTHORITY\System" user. To check permissions, David ran regedit and navigated to the key in question. When he right-clicked on the key and selected Permissions, he found that the Everyone group had Deny -- Full Control permissions. Once he removed the Everyone group from the ACL, the problem was solved.

David was unsure of how the Deny permission was ever set on such a specific key in the first place, but was happy to solve the problem without having to rebuild his system. To me, this is why tools like the Event Viewer, Regmon and Process Explorer are so valuable. They can allow you to see the problem (in the case of Regmon or Process Explorer) as it’s happening, which is especially useful when dealing with locking issues stemming from competing processes accessing the same object.

Hopefully, with the right tools and a little patience, you’ll find that your systems can comfortably run new software, without any harmful side effects such as nausea, sudden liver failure or blindness.

About the Author

Chris Wolf is a Microsoft MVP for Windows --Virtual Machine and is a MCSE, MCT, and CCNA. He's a Senior Analyst for Burton Group who specializes in the areas of virtualization solutions, high availability, storage and enterprise management. Chris is the author of Virtualization: From the Desktop to the Enterprise (Apress), Troubleshooting Microsoft Technologies (Addison Wesley), and a contributor to the Windows Server 2003 Deployment Kit (Microsoft Press).learningstore-20/">Troubleshooting Microsoft Technologies (Addison Wesley) and a contributor to the Windows Server 2003 Deployment Kit (Microsoft Press).

comments powered by Disqus

SharePoint Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.