Installer program can’t read my registry

Topic

New Reply

I run and provide support for a program that gets updated regularly however I can not install the latest update.  It fails with an error opening registry key.  The developer reads a registry key to obtain the current installation path and then displays that for confirmation of the upgrade to the correct path.  I am in direct contact with the developer and we have not been able to identify why I am encountering the problem.  He has made this update publicly available and has many confirmations of update success.  So far, I am the only one reporting this problem.  I pulled an old laptop out of the closet and successfully ran the update on it so the problem is unique to my Win11 machine.  I have confirmed that it exists.  I have run the upgrade using “Run as administrator” and while logged in as an admin user.  Does anyone know of anything that I could fix that is preventing the reading of a registry key?

Reply | Quote

Replies

You may have key permissions that deny access.

Open Registry Editor, navigate the the key and right click it. Select Permissions.
All users should have read permission.

cheers, Paul

2 users thanked author for this post.

Peobody, TechTango

Reply | Quote

@Paul T, I didn’t mean to ignore you.  I checked permissions as suggested.  All looks fine.  Thanks for that tip.  I didn’t know about registry permissions.

Reply | Quote

Now you have to run the burning hoops of fire as described by Rick. 

cheers, Paul

Reply | Quote

@Peobody If you log the installer activity using process monitor (available from  https://learn.microsoft.com/en-us/sysinternals/downloads/procmon ) you may be able to provide the developer with some information about why the attempted read of the registry key failed.  The amount of information that it logs can be substantial but this can be controlled by limiting logging to registry activity and also filtering by path.

Reply | Quote

EricB wrote:

The amount of information that it logs can be substantial but this can be controlled by limiting logging to registry activity and also filtering by path

@EricB is right about this. Process Monitor (ProcMon) has a bit of a learning curve and one of the annoying things is that when you run it and accept its EULA (first-time use only), it starts capturing thousands of events a minute immediately.

So, here’s a couple of tips to make using ProcMon easier:

1. Always run ProcMon from a modified shortcut:

Create a shortcut to the procmon.exe file then amend the shortcut’s properties as follows:

a) This will run the executable using the Run as administrator option. You will need this elevation for ProcMon to capture system-wide events (like registry activity from installers) instead of just user-level events.

b) The /NoConnect switch will stop the executable auto-capturing events when run.

2. Filter what capture activity is shown.

You are looking for a registry event (most likely a result of ACCESS DENIED) so filter out extraneous captures from view by deselecting the 3 activity icons to the right of Show Registry Activity:

This will change the view to show you only registry activity, nothing else. (It just hides the display of the other activities.)

3. Create a filter (using Filter in the main menu) to include the image path to the installer.

You didn’t mention the name of the installer so here’s an example image path filter for Paint Shop Pro 7:

You create the entry to the installer executable and make sure the new entry ends with Include (a); then you ADD (b) the entry to the filter list; then you Apply (c) the change then click on OK (e) to close the dialog.

So, do this:

Create the shortcut then run it to open ProcMon (and accept the EULA).

Deselect the Activities view so only Show Registry Activity is active.

Create the image path filter, similar to the example screenshot above.

Practice clicking on the Capture icon to start captures (or use CTRL+E) then clicking on the icon again to end captures (or use CTRL+E again).

Adjust the ProcMon windows size so you can see the installer executable next to it.

When you’re ready, do this:

Start ProcMon capturing then quickly swap to the installer and run it.

Swap back to the ProcMon window then stop the capture immediately you see the installer fails with error opening registry key.

In ProcMon‘s Results column you should be able to spot the error and its cause near to the end of the capture list.

Hope this helps…

3 users thanked author for this post.

Peobody, PKCano, TechTango

Reply | Quote

In addition to Rick Corbett’s excellent advice you can further reduce the volume of registry information by filtering on the registry path itself.  For example, lets say the registry key to be interrogated looks like this –

Since the registry path is known the procmon filter can look like this –

A successful retrieval of the InstallPath looks like this –

Failure to open the registry key looks like this –

 

1 user thanked author for this post.

Peobody

Reply | Quote

Sorry, @EricB, but I can’t see how anyone could guess beforehand with any certainty which registry key(s) to filter on without first picking apart the installer update.

For example, what if the ‘update’ is to upgrade a previous 32-bit install to 64-bit, removing the 32-bit version (filesystem and registry) at the same time? Which registry InstallPath to look for… old or new?

For some reason @Peobody has given little to no information about which program and/or upgrade he/she is seeking help on.

Without further info, I think we’re all just guessing… hence why I provided just a generic answer about using ProcMon to look for further info, especially errors as that was what was mentioned.

Hope this helps…

Reply | Quote

Peobody wrote:

It fails with an error opening registry key.  The developer reads a registry key to obtain the current installation path and then displays that for confirmation of the upgrade to the correct path.  I am in direct contact with the developer and we have not been able to identify why I am encountering the problem

I agree that the description of the problem is rather vague. However, from what I have read it seems to me the interaction with the developer would have provided that information. Also, earlier post referred to checking of permissions on the registry key.

Reply | Quote

@EricB did good.  Apparently he picked up on the fact that I was in contact with the developer so knew the registry keys.  I just didn’t know how to help him identify what was causing the failure.  I don’t know whether the results from Process Monitor will help him but I was able to produce them thanks to you both.  I saved to a .csv and sent them on to him.  Now I wait to hear whether they helped.  Regardless, you guys introduced me to something new, and in such detail that I didn’t feel over my head whereas I certainly would have without it.  Thanks again.

BTW, I didn’t include the details of the product because the product is irrelevant to the issue, plus it’s a bit obscure and I didn’t want that to sidetrack the discussion.

Reply | Quote

@Peobody Unless you are familiar with how Windows permissions work it is easy to misinterpret how the system enforces them.

It is very unusual for an application running with elevated privileges as Administrator to fail to read a registry key.

Following shows the typical permissions for the example HKLM\Software\ImaginaryCorp registry key from my earlier example.  Right clicking on permissions and then clicking the Advanced button will result in this more detailed display –

If you can share the same display for your registry key with us (or the developer) there may be something relevant to the access failures that you have experienced.

 

Reply | Quote

Peobody wrote:

@EricB did good. Apparently he picked up on the fact that I was in contact with the developer so knew the registry keys.

Yes, I didn’t pick up on that at all. My apologies to @EricB… I got it wrong.

PS – Another ProcMon tip: If you’re going to save results from ProcMon, always save them in the default .PML format (unless asked to send them in a different format) and ZIP the .PML file before sending.

The reason is… the recipient can load the .PML file into their own copy of ProcMon and use its tools to further filter/examine the results. That’s not possible with a .CSV file.

PML files can be quite large so I suggest you don’t save all events, only the events displayed by the current filter. I use these settings:

Hope this helps…

1 user thanked author for this post.

EricB

Reply | Quote

EricB wrote:

@Peobody Unless you are familiar with how Windows permissions work it is easy to misinterpret how the system enforces them.

I am when it comes to NTFS file/folder permission.  Until now, I was unaware that there was similar security for registry keys.

I discovered, and reported to the developer, that the previous version still installs fine.  Dev then sent me a revised test installer that again abended due to being unable to read a registry key, actually three, because it has two fallback keys and the abend was after the third one failed.   Baffling to the dev is why is it happening and why I am the only one to report it.

I don’t think there is anything more to be done on this topic now.  I’ll be back if I need you.

Reply | Quote

Just curious, have you tried after turning off any antivirus/antimalware software?

Reply | Quote

EricB wrote:

Just curious, have you tried after turning off any antivirus/antimalware software?

I hadn’t, but I have now (MS Defender).  No joy.

Reply | Quote

The inability to read a key (even as Administrator) seems so unusual that my curiosity has maxed out.

Can you share the error results that were obtained from Process Monitor?  For example, was it access denied or some other error?

 

 

Reply | Quote

The Process Monitor results won’t help, but perhaps you might have a clue into why.

The installer is updating a program called IERenderer which is an add-on to the email client Pegasus Mail.  The three registry keys being read by the installer are being done to determine the installation path of Pegasus Mail.  Two of the tree keys being checked are HK<span style=”text-decoration: underline;”>CU</span>\Software\Pegasus Mail\BaseDir and HKCR\Software\Pegasus Mail\BaseDir (this is the last one being checked so is the one referenced in the error notice.  Surprising to me is that I don’t find either of these keys when I search for “Pegasus Mail” in the .csv export of the registry filtered results.  I have attached that .csv in the hopes it might provide a clue into what is going on, or what I did wrong when I used Process Monitor.

Reply | Quote

Was the account used to run the installer the same account under which Process Monitor was running as an Administrator?

How did you filter the results?

Reply | Quote

EricB wrote:

Was the account used to run the installer the same account under which Process Monitor was running as an Administrator?

Yes

EricB wrote:

How did you filter the results?

The only filter was image path set to the path of the installer IERendererSetup.exe.

“Show registry activity” was the only “Show” button active.

Reply | Quote

If IERendererSetup.exe starts a child process to do the work then the Image path filter used could result in activity being excluded.

Get rid of the image path filter and try this one –

 

1 user thanked author for this post.

Peobody

Reply | Quote

@EricB, I think your intellectual curiosity has paid off.   The Path filter you suggested resulted in the recording of registry events that the Image Path filter did not.

Below are two screenships of those entries.  The first one was taken when I was logged in as the admin user.  It shows three registry keys that weren’t found.  None of them exist when I look at the registry as the admin user but the first one exists when I look at the registry as Me, a standard user.  I don’t understand this but I consider it irrelevant to the topic at hand, other than that it prompted me to run process monitor and the installer again while logged in as me.  The second image shows the IERendererSetup.tmp process entries from that test.   The registry keys are different.  One shows a buffer overflow condition which I assume causes the abend in this case.  This is valuable info for me to take to the developer.  I hope it also satisfies your curiosity.

 

 

Reply | Quote

Looks like you’re making progress.

By the way, the Buffer Overflow errors are not a problem.  It is very common to call a Windows API function twice.  The first call returns the size of the memory buffer needed to hold the desired data.  That’s the one that shows as Buffer Overflow.  After a suitably sized buffer is allocated the function is called again and the data is returned.

The HKCU registry key is a shortcut way of referring to a specific user’s registry hive that actually resides under HKU.  So it maps to HKU\User’s SID\.

When a user is not logged on their specific registry hive is not loaded.

When an Administrator account references HKCU it refers to the Administrators hive mapped to HKU\Administrator’s SID\.  So its not surprising that nothing was found for the Administrator account if the software installation wrote to the non-administrator account registry hive.

Finally, HKCR is a merged view of HKLM\Software\Classes and HKCU\Software\Classes.  So again, it would not contain the data when viewed under the Administrator’s account.

 

Reply | Quote

Yup!  Making progress (I think), and learning a lot.  Thank you for sharing your knowledge.

Since my last post I have learned that the developer is in the midst of a major internet outage with earliest hope for service restoration still two days away.  I feel bad that he is having to try to get the word out via cell service but grateful for his efforts at trying to get the word out via cell service.  I’ll be back in a few days or so if I still need assistance.

 

Reply | Quote