Repository navigation
test(rules): the in-box module table is held against the Windows client the tests run on - #21
Conversation
fadwen
left a comment
fadwen
left a comment
There was a problem hiding this comment.
Notes on the lines whose reason the diff does not show.
| # Listed, and rightly, but not a folder Get-Module -ListAvailable finds: the engine's own module | ||
| $script:EngineModule = 'Microsoft.PowerShell.Core' | ||
| # Pro and Enterprise features a Home edition does not ship (Windows 11 Home 24H2, ARM64) | ||
| $script:EditionOnly = 'AppLocker', 'AppvClient', 'AssignedAccess', 'BranchCache', 'ConfigCI', 'iSCSI', 'UEV' |
There was a problem hiding this comment.
Measured on a Windows 11 Home ARM64 24H2 host against the Enterprise x64 device: these seven are the whole difference in that direction. A Home host in CI would otherwise fail the first assertion for features it never had.
| $script:EditionOnly = 'AppLocker', 'AppvClient', 'AssignedAccess', 'BranchCache', 'ConfigCI', 'iSCSI', 'UEV' | ||
| # Present on a Windows 11 Home ARM64 24H2 host and absent from the Enterprise x64 device the | ||
| # table was captured on; neither is a plain device every script can count on | ||
| $script:SeenElsewhere = 'HostNetworkingService' |
There was a problem hiding this comment.
Kept out of the table rather than added: the Enterprise x64 device, re-captured on 2026-10-06, does not have it, so a script cannot count on it. Whether it is an ARM64 or a Home artefact was not established.
| $system | Where-Object { $module.ModuleBase.StartsWith($_, 'OrdinalIgnoreCase') } | ||
| } | Select-Object -ExpandProperty Name -Unique | Sort-Object -Unique | ||
| # The engine module has no folder and Import-Module of it fails; its commands are there | ||
| $engine = (Get-Command -Name Get-Command).ModuleName |
There was a problem hiding this comment.
Get-Module -Name Microsoft.PowerShell.Core returns nothing on either host and Import-Module of it fails, so the engine module is proved by the module a core command reports. The first draft asked Get-Module and failed on both hosts.
| if (Get-Command powershell.exe -ErrorAction SilentlyContinue) { | ||
| # ProductType 1 is a workstation; the table describes a client, and a server's set differs | ||
| $os = Get-CimInstance -ClassName Win32_OperatingSystem -ErrorAction SilentlyContinue | ||
| $script:ClientHost = [int]$os.ProductType -eq 1 |
There was a problem hiding this comment.
windows-latest in CI is Windows Server, whose in-box set has server modules and lacks client ones; the table describes a client, so the host assertions run on windows-11-arm and on a developer's machine, not there.
…nt the tests run on Get-IslInboxModule is a hand-written list captured as SYSTEM on the lab device, and nothing checked it afterwards: a misspelt name, or a module Windows drops, would have made IslModuleDependency wrong without a test noticing, the way the PowerShell 7-only tables were before they got a test of their own. The new test asks the host's Windows PowerShell, as a child process, for the modules under the two system module paths a SYSTEM session reads (REM-PSMODULEPATH). Every listed module must be there, except the engine module, which has no folder, and the seven a Home edition does not ship; and nothing may be there that the table or the test does not account for. The test runs on a Windows client (ProductType 1) and is skipped on a server, whose set differs. Measured for this change: the table re-captured as SYSTEM on VM 125 on 2026-10-06 (Windows 11 Enterprise LTSC 24H2, build 26100) is the same 90 modules. A Windows 11 Home ARM64 24H2 host has 84 of them, lacking AppLocker, AppvClient, AssignedAccess, BranchCache, ConfigCI, iSCSI and UEV, and has HostNetworkingService besides. Import-Module of Microsoft.PowerShell.Core by name fails on both hosts although its commands are there; the help says so. The table is unchanged.
…ows folder only A GitHub runner has fifty installed modules under Program Files\WindowsPowerShell\Modules, Graph, AWS, SQL and the rest, and so may any managed device; that folder is where software and the Gallery's AllUsers scope install to, and says nothing about the table. The completeness assertion reads System32\WindowsPowerShell\v1.0\Modules alone, with Hyper-V and the container and host-guardian family allowed as features a host may have turned on (the ARM64 runner has them). The existence assertion still reads both folders, where PackageManagement, PowerShellGet and Pester live.
fadwen
left a comment
fadwen
left a comment
There was a problem hiding this comment.
Notes on the second commit, after the first dispatched CI run.
| # Windows features that put a module under System32 when they are turned on: Hyper-V and the | ||
| # container and host-guardian family. HostNetworkingService is there on a Windows 11 Home ARM64 | ||
| # host without the feature. None is on a plain device, so none is in the table | ||
| $script:FeatureModules = 'Hyper-V', 'HgsClient', 'HgsDiagnostics', 'HostComputeService', |
There was a problem hiding this comment.
The ARM64 runner has Hyper-V, HgsClient, HgsDiagnostics and HostComputeService under System32: features turned on in the runner image. They are not in the table because a plain device has none of them, which the help of Get-IslInboxModule says of feature modules.
| $encoded = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($probe.ToString())) | ||
| $raw = & powershell.exe -NoProfile -NonInteractive -EncodedCommand $encoded 2>&1 | ||
| $answer = ($raw | Where-Object { "$_".StartsWith('{') } | Select-Object -Last 1) | ConvertFrom-Json | ||
| $script:WindowsModules = @($answer.Windows) |
There was a problem hiding this comment.
Two lists rather than one so that completeness can be judged on the Windows folder alone while existence still accepts Program Files, where PackageManagement, PowerShellGet and Pester 3.4 live on a plain device.
1 participant
Summary
Get-IslInboxModule, the listIslModuleDependencyreports from, was captured as SYSTEM on the lab device and never checked afterwards: a misspelt name, or a module Windows drops, would have made the rule wrong without a test noticing, as the PowerShell 7-only tables were before #12 gave them one. This adds the equivalent test for the module table, and re-captures the table on the device.Stacked on #20 (base branch); the diff is this change only. Merge #16 through #20, then this.
What was measured
Get-Module -ListAvailableunder the two system module paths gives the same 90 modules the table lists (the 91st,Microsoft.PowerShell.Core, is the engine module and has no folder). The table is unchanged.HostNetworkingServicebesides, which the Enterprise x64 device does not have.Import-Module Microsoft.PowerShell.Coreby name fails on Windows PowerShell 5.1 and PowerShell 7.6 alike ("no valid module file was found"), although every session has its commands. The help says so now; what the rule should say about a script that imports it is an open question, since "not in-box" would be the wrong message.Changes
Tests/Unit/Private/Get-IslInboxModule.Tests.ps1(new). Asks the host'spowershell.exeas a child process for the modules underSystem32\WindowsPowerShell\v1.0\ModulesandProgram Files\WindowsPowerShell\Modules, the paths a SYSTEM session reads (REM-PSMODULEPATH). Every listed module must be there, except the engine module and the seven Home lacks; the engine module's commands must be present without a folder; nothing may be under the Windows module folder,System32\WindowsPowerShell\v1.0\Modules, that the table does not name or the test does not account for. The Program Files folder is left out of that last check: a GitHub runner has fifty installed modules there, Graph, AWS, SQL and the rest, and so may any managed device; it is where software and the Gallery's AllUsers scope install to. Hyper-V, HgsClient, HgsDiagnostics, HostComputeService and HostNetworkingService are allowed as features a host may have turned on; the ARM64 runner has the first four. Runs on a Windows client (ProductType1), skipped on a server, whose set differs; the ARM64 CI runner is a Windows 11 client and runs it.Private/Get-IslInboxModule.ps1. Help records the re-capture, the engine module's import failure and the Home and ARM64 differences. The list is unchanged.Verification
Notes
FeatureModuleslist (a feature of that host). The first dispatched CI run did exactly that for the ARM64 runner, which is how the Program Files exclusion and the four Hyper-V family entries got here.