(core.extension) Get-UninstallKey doesn't handle 64-bit registry from 32-bit processes

[ferventcoder]

Related to #214

On f7fe281
@DarwinJS mentioned that the code doesn't work with 32-bit processes attempting to access 64-bit keys. This is because it doesn't use the flag to override Registry Redirection. This could have issues with processes such as Chef that run in 32-bit mode calling this.

[ferventcoder]

cc @mwrock @dtgm

[dtgm]

I don't see redirection listed as affecting these keys:

$local_key       = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*'
$machine_key     = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*'
$machine_key6432 = 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'

EDIT

Nevermind, I missed the line above that table saying

Subkeys of the keys in this table inherit the parent key's behavior unless otherwise specified.

[DarwinJS]

@ferventcoder - I posted powershell code back to the original commit - handles some other edge cases as well.

[ferventcoder]

@dtgm are you familiar with registry redirection? Basically the 64bit view of the registry is missing unless explicitly opted into by a 32 bit process.

[wjk]

@ferventcoder I just wanted to point out that you can actually use the .NET Registry APIs to explicitly open either the 64-bit or the 32-bit Registry views, no matter what the bit-width of the system or the current process is. You can do so using the Microsoft.Win32.RegistryKey.OpenBaseKey() method (in C#). This class is documented by Microsoft as having existed since .NET Framework 4.0. I don’t know if you need to target anything earlier than that. (If you do, you can P/Invoke into the Win32 Registry access methods and use certain flags to the RegOpenKeyEx method to access them, but that’s a lot more work.)

While I don’t know if the PowerShell Registry cmdlets support this functionality, PowerShell can natively call CLR objects written in C# or any other language (as you probably already know); it just involves more verbose code than using native cmdlets. Furthermore, even if direct CLR object access is required, the nature of the extension being discussed means that the implementation details are irrelevant to the users of the extension; they call it just like any other cmdlet. I can provide a PR if desired.

[ferventcoder]

@wjk On the PowerShell side, this needs to work all the way back to PowerShell v2 / .NET Framework 2.0 (not 3.5, 2.0).

[gep13]

@ferventcoder is this still an issue? The uninstall extension as been deprecated in favour of the core extension. Is the reported issue still relevant to that extension?

[DarwinJS]

I don't know - I was analyzing the PowerShell code that did this when I made the original comment. It would depend on what the core extension code looks like. Is the core extension implemented as PowerShell or C# ?

[gep13]

@DarwinJS said...
Is the core extension implemented as PowerShell or C# ?

Powershell. The source for the extension can be seen here:

https://github.com/chocolatey/chocolatey-coreteampackages/tree/master/extensions/chocolatey-core.extension/extensions

Thanks!

[majkinetor]

I am going to close this at the end of the year if there is no activity due to its 6mo age.