773077 - helper.exe updates HKCU when it should update HKLM (likely due to launching unelevated)

Status: RESOLVED DUPLICATE of bug 789743

(Toolkit :: Application Update, defect)

Description

[Robert Strong (they/them - no direct email)]

This causes HKCU\Software\Mozilla registry keys to be updated instead of HKLM\Software\Mozilla

Comment 1

[Brian R. Bondy [:bbondy]]

Did you confirm that it doesn't update HKLM at all? If so, then I *think* this is a bgupdate issue as we run the post update process from both the elevated context in session 0 and the unelevated context when we have a service update without bgupdates involved.

workmonitor.cpp:
> if (useService && !sBackgroundUpdate) {
> ...
>  if (!LaunchWinPostProcess(installDir, gSourcePath, false, NULL)) {

updater.cpp:
> if (useService && !sBackgroundUpdate) 
> ...
>   if (!LaunchWinPostProcess(installDir, gSourcePath, false, NULL)) {

Comment 2

[Robert Strong (they/them - no direct email)]

Agreed... likely bgupdates. I haven't had a chance to investigate thoroughly... I just noticed that HKCU has updated Software\Mozilla keys and that HKLM does not.

Comment 3

[Robert Strong (they/them - no direct email)]

Just verified that HKCU has the updated Software\Microsoft\Windows\uninstall entries for 16.0a1 and HKLM has the old Software\Wow6432Node\Microsoft\Windows\uninstall entries for 15.0a1.

Comment 4

[Brian R. Bondy [:bbondy]]

I was wondering why this wouldn't work for bgupdates since the replace request should do it in the quoted code above.  Tested it out and I can't reproduce this issue.

This key's values:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Nightly 16.0a1 (x86 en-US)

All get updated in both of these cases:
1) app.update.service.enabled && !app.update.stage.enabled
2) app.update.service.enabled && app.update.stage.enabled

at least for my install it works.

Comment 5

[Robert Strong (they/them - no direct email)]

Note: I haven't explicitly tested this out... I'm just seeing this with the nightly build that I use. Could be something specific about my system.

Comment 6

[(no longer active)]

(In reply to comment #5)
> Note: I haven't explicitly tested this out... I'm just seeing this with the
> nightly build that I use. Could be something specific about my system.

Could you please use procmon the next time you update and see what helper.exe does exactly?

Comment 7

[Robert Strong (they/them - no direct email)]

Just noticed the following under HKCU which implies it is staging that is causing this
C:\Program Files (x86)\Nightly\updated\uninstall\helper.exe

I just updated Aurora and it updated the registry correctly.

I think it might be due to a bug in the way the keys were updated that has since been fixed. I'll keep an eye on it.

Comment 8

[Robert Strong (they/them - no direct email)]

(In reply to Robert Strong [:rstrong] (do not email) from comment #7)
> Just noticed the following under HKCU which implies it is staging that is
> causing this
> C:\Program Files (x86)\Nightly\updated\uninstall\helper.exe
> 
> I just updated Aurora and it updated the registry correctly.
I just noticed that I have duplicate entries under HKCU\Software\Mozilla and HKLM\Wow6432Node\Software\Mozilla for Aurora.

Comment 9

[Brian R. Bondy [:bbondy]]

I think Aurora has staging enabled too.

Comment 10

[Robert Strong (they/them - no direct email)]

Yes, I am just seeing slightly different behavior there.

Comment 11

[Brian R. Bondy [:bbondy]]

Gotcha. I did a diff between m-c and aurora locally but nothing jumps out at me, they are mostly the same. for toolkit/mozapps/update and toolkit/comoponents/maintenanceservice

Comment 12

[Robert Strong (they/them - no direct email)]

I suspect my nightly install got into a different state than my aurora install and the reason they are different is due to a bug that was fixed after I experienced the bug on nightly.

Comment 13

[(no longer active)]

Hmm, this looks to me like a dupe of bug 765227, especially because of the presence of "updated" in the path name there.  I wonder if there is a way to get the last modified date of a registry key?  (I guess there isn't.)

Robert, did you ever get a chance to try what I suggested in comment 6?

FWIW, all of the patches that we landed for bgupdates on central are on Aurora now (well, Beta now, Firefox 15.)

Comment 14

[Robert Strong (they/them - no direct email)]

I suspect so but I haven't had the time to investigate it yet.

Comment 15

[Brian R. Bondy [:bbondy]]

(In reply to Ehsan Akhgari [:ehsan] from comment #13)
> Hmm, this looks to me like a dupe of bug 765227, especially because of the
> presence of "updated" in the path name there.  I wonder if there is a way to
> get the last modified date of a registry key?  (I guess there isn't.)
> 
> Robert, did you ever get a chance to try what I suggested in comment 6?
> 
> FWIW, all of the patches that we landed for bgupdates on central are on
> Aurora now (well, Beta now, Firefox 15.)

Seems this wasn't a dupe of bug 765227 and also Comment 7 must have been wrong.  Probably the registry entries were updated, but they just appeared the same.  I fixed this issue in 789743 so I'm going to mark this a dupe of that.