MSFT_MsiPackage.Integration.Tests.ps1: Tests fail with: RuntimeException: The variable '$responseStream' cannot be retrieved because it has not been set #142
Comments
mhendric
added
bug
|
Adding some more troubleshooting info, since it turned out that my theory on Strong Crypto being the problem was wrong. After digging deeper, it turns out that the following error message is really just a result of the test machine being in Strict mode for PowerShell: Specifically this occurs in MSFT_MsiPackage\MSFT_MsiPackage.psm1\Set-TargetResource when a null responseStream is returned from Get-WebRequestResponse. This particular error can be avoided by using Test-Path to see if the responseStream variable is null. After fixing the above and adding some additional logging, I found another problem in Tests\TestHelpers\MSFT_MsiPackageResource.TestHelper.psm1\Start-Server, which is used to create an HTTP(S) server to host a test MsiPackage. A major problem in this function is that it starts and runs the HTTP(S) server within a PowerShell Job, and that it doesn't check to see if the job encountered errors or exceptions before signaling to the client that the server is setup correctly. Further, if an exception was encountered in the job, it would not be bubbled up to the calling code. A future fix for this issue should include bubbling up any underlying failures in the PowerShell job so that we can fail quicker, and also see why we failed. With the above logging and exception raising in place, I found that this was an underlying error being encountered when trying to start the HTTPListener in Start-Server: And with the $responseStream issue addressed above, I could see that Set-TargetResource was failing with: So in this case, the HTTPListener failed to setup properly because there was a lock on the test file, and then Set-TargetResource failed to connect to the HTTP server. I believe this particular problem can be avoided by ensuring that all test HTTP(S) jobs are fully closed and removed before trying to setup new jobs. A new fix for all of this should be getting submitted very soon. |
|
Adding some more troubleshooting info. I had last suspected that this issue was being caused because the PowerShell jobs that run the HTTP Listener were being left open. However, I added code to ensure that jobs were being closed, and I still encountered this. I then added some additional logging around where the error occurs, and found that the AppVeyor build agent was running on port 1243 (the same port the HttpListener is trying to register on). I also found that WmiPrvSE likes to snag ports in the 1230 - 1240 range, so plausibly could conflict with 1243 at some point as well. Given all this, my next attempt at a fix will be to move these HttpListeners to a much higher port number (thinking of picking a high number, unassigned port in here: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=130) |
Details of the scenario you tried and the problem that is occurring
I'm not sure what the full set of conditions that cause this are, but tests have been failing lately in MSFT_MsiPackage.Integration.Tests.ps1 with the below error when trying to connect to a local HTTPS endpoint. It appears that this occurs at least in part when [Net.ServicePointManager]::SecurityProtocol is set to: Ssl3, Tls. The fix appears to be to set SchUseStrongCrypto to 1 on the test machine, which changes [Net.ServicePointManager]::SecurityProtocol to Tls, Tls11, Tls12.
Verbose logs showing the problem
Suggested solution to the issue
On test machines, set the following keys before executing MsiPackage tests:
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord -ErrorAction Stop
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord -ErrorAction Stop
The operating system the target node is running
OsName : Microsoft Windows Server 2019 Standard
OsOperatingSystemSKU : StandardServerEdition
OsArchitecture : 64-bit
WindowsVersion : 1809
WindowsBuildLabEx : 17763.1.amd64fre.rs5_release.180914-1434
OsLanguage : en-US
OsMuiLanguages : {en-US}
Version and build of PowerShell the target node is running
PS C:> $PSVersionTable
Name Value
PSVersion 5.1.17763.316
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.17763.316
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Version of the DSC module that was used ('dev' if using current dev branch)
dev
The text was updated successfully, but these errors were encountered: