Skip to content

Fix per-package architecture detection for windows/app packages#6875

Merged
czunker merged 1 commit intomainfrom
czunker/win_pkg_arch
Mar 11, 2026
Merged

Fix per-package architecture detection for windows/app packages#6875
czunker merged 1 commit intomainfrom
czunker/win_pkg_arch

Conversation

@czunker
Copy link
Copy Markdown
Contributor

@czunker czunker commented Mar 11, 2026

Summary

  • Previously all windows/app packages used platform.Arch (e.g. AMD64) regardless of whether they were 32-bit or 64-bit, causing duplicate package scores when both x86 and x64 variants (e.g. Microsoft .NET Runtime - 8.0.7 (x86) and (x64)) were installed on the same system
  • Implemented two-tier architecture detection:
    1. Primary: Wow6432Node in registry path — authoritative for HKLM, which is redirected by WOW64
    2. Fallback: Program Files (x86) in InstallLocation/UninstallString — covers HKCU where HKCU\SOFTWARE is a shared, non-redirected key
  • Applied to all three code paths: local registry, filesystem/device, and PowerShell remote (via PSPath property added to Select-Object output)
  • windows/appx packages are not affected — they already report per-package architecture via the Architecture field from Get-AppxPackage or AppxManifest.xml

Test plan

  • Unit tests for archForRegistryPath (all path variants: HKLM, HKCU, PSPath, filesystem)
  • Unit tests for archFromInstallPath (Program Files x86 detection, edge cases)
  • Integration test for ParseWindowsAppPackages with PSPath (Wow6432Node vs native)
  • Integration test for ParseWindowsAppPackages with install path fallback (HKCU entries)
  • Regression test: getPackageFromRegistryKeyItems with Wow6432Node-determined arch is not overridden
  • Existing tests pass unchanged (backward compatible for data without PSPath)
  • Manual verification on a Windows system with both x86 and x64 .NET Runtime installed

🤖 Generated with Claude Code

Previously all windows/app packages used platform.Arch (e.g. AMD64)
regardless of whether they were 32-bit or 64-bit. This caused duplicate
package scores when both x86 and x64 variants of the same package
(e.g. Microsoft .NET Runtime) were installed.

Two-tier detection:
1. Primary: Wow6432Node in the registry path (authoritative for HKLM,
   which is redirected by WOW64)
2. Fallback: "Program Files (x86)" in InstallLocation/UninstallString
   (covers HKCU where HKCU\SOFTWARE is a shared, non-redirected key)

Applied to all three code paths: local registry, filesystem/device, and
PowerShell remote (via PSPath property added to Select-Object output).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@czunker
Copy link
Copy Markdown
Contributor Author

czunker commented Mar 11, 2026

/review

Copy link
Copy Markdown

@mondoo-code-review mondoo-code-review Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Windows packages now report correct per-package architecture (x86 vs native) instead of always using the platform arch.

@github-actions
Copy link
Copy Markdown
Contributor

Test Results

5 354 tests  +21   5 350 ✅ +21   2m 6s ⏱️ -12s
  411 suites ± 0       4 💤 ± 0 
   31 files   ± 0       0 ❌ ± 0 

Results for commit 4cffa1a. ± Comparison against base commit ef88233.

@czunker czunker marked this pull request as ready for review March 11, 2026 09:33
@czunker czunker merged commit 1df045a into main Mar 11, 2026
23 checks passed
@czunker czunker deleted the czunker/win_pkg_arch branch March 11, 2026 09:34
@github-actions github-actions Bot locked and limited conversation to collaborators Mar 11, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant