10000 Need check OS version in installation packages and maybe binary · Issue #4315 · PowerShell/PowerShell · GitHub
[go: up one dir, main page]

Skip to content

Need check OS version in installation packages and maybe binary #4315

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
iSazonov opened this issue Jul 21, 2017 · 15 comments
Closed

Need check OS version in installation packages and maybe binary #4315

iSazonov opened this issue Jul 21, 2017 · 15 comments
Labels
Area-Maintainers-Build specific to affecting the build Resolution-Fixed The issue is fixed.
Milestone

Comments

@iSazonov
Copy link
Collaborator

I install PowerShell-6.0.0-beta.4-win10-win2016-x64.msi on Windows Server 2012 R2 and get an exception (see test below). The same package I install on Windows Server 2012 - no exception with the same test.

Conclusion: we should check OS version in our packages and block setup on inappropriate OS version.

Discussion: User can copy-paste folder with installed PowerShell Core from one OS to one with inappropriate version and get unpredictable results. We should to protect in some way. Maybe have a manifest to check dll versions at startup.
(Microsoft.Management.Infrastructure.Native.Unmanaged.DLL version is the same in Win10 and Win81 packagees).

I test Test-Connection computername on Windows Server 2012 R2. The Microsoft.Management.Infrastructure.Native.Unmanaged.DLL is present in root PowerShell Core folder.

TypeName       : Microsoft.Management.Infrastructure.Native.ApplicationMethods
Message        : The type initializer for 'Microsoft.Management.Infrastructure.
                 Native.ApplicationMethods' threw an exception.
Data           : {}
InnerException : System.DllNotFoundException: Unable to load DLL
                 'Microsoft.Management.Infrastructure.Native.Unmanaged.DLL':
                 The specified module could not be found. (Exception from
                 HRESULT: 0x8007007E)
                    at
                 MI_ApplicationWrapper_Initialize(_MI_ApplicationWrapper* ,
                 UInt16* , IntPtr , IntPtr , IntPtr , IntPtr , IntPtr , IntPtr
                 , IntPtr , IntPtr , IntPtr , IntPtr , IntPtr , IntPtr ,
                 IntPtr )
                    at Microsoft.Management.Infrastructure.Native.MI_Applicatio
                 nWrapper_Initialize_Managed(_MI_ApplicationWrapper*
                 pmiApplicationWrapper)
                    at Microsoft.Management.Infrastructure.Native.ApplicationMe
                 thods.InitializeCore(InstanceHandle& errorDetails,
                 ApplicationHandle& applicationHandle)
                    at Microsoft.Management.Infrastructure.Native.ApplicationMe
                 thods..cctor()
TargetSite     : Microsoft.Management.Infrastructure.Native.MiResult Initialize
                 (Microsoft.Management.Infrastructure.Native.InstanceHandle
                 ByRef,
                 Microsoft.Management.Infrastructure.Native.ApplicationHandle
                 ByRef)
StackTrace     :    at Microsoft.Management.Infrastructure.Native.ApplicationMe
                 thods.Initialize(InstanceHandle& errorDetails,
                 ApplicationHandle& applicationHandle)
                    at Microsoft.Management.Infrastructure.Internal.CimApplicat
                 ion.GetApplicationHandle()
                    at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode)
                    at System.Lazy`1.ExecutionAndPublication(LazyHelper
                 executionAndPublication, Boolean useDefaultConstructor)
                    at System.Lazy`1.CreateValue()
                    at Microsoft.Management.Infrastructure.Options.CimOperation
                 Options.<>c__DisplayClass9_0.<.ctor>b__0()
                    at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode)
                    at System.Lazy`1.ExecutionAndPublication(LazyHelper
                 executionAndPublication, Boolean useDefaultConstructor)
                    at System.Lazy`1.CreateValue()
                    at Microsoft.Management.Infrastructure.Options.CimOperation
                 Options.set_Timeout(TimeSpan value)
                    at Microsoft.PowerShell.Commands.TestConnectionCommand.Proc
                 essWSManProtocolForTestConnection()
                    at Microsoft.PowerShell.Commands.TestConnectionCommand.Proc
                 essRecord()
                    at System.Management.Automation.Cmdlet.DoProcessRecord()
                    at
                 System.Management.Automation.CommandProcessor.ProcessRecord()
HelpLink       :
Source         : Microsoft.Management.Infrastructure.Native
HResult        : -2146233036
@iSazonov iSazonov added the Area-Maintainers-Build specific to affecting the build label Jul 21, 2017
@SteveL-MSFT SteveL-MSFT added this to the 6.0.0-HighPriority milestone Jul 25, 2017
@SteveL-MSFT
Copy link
Member

The MSI should check to make sure it's the right OS. I think it should also check dependencies (Win10 URT and VC++ redist). However, if someone copies the expanded zip from one OS to another, I don't know how much effort we want to spend detecting that.

@iSazonov
Copy link
Collaborator Author

It seems not only Windows issue but Unix too.
We have Issues to get universal packages #2608 (Windows) and #3961 (Linux) - maybe we can resolve the Issue there.

@bergmeister
Copy link
Contributor

@iSazonov @adityapatwardhan See here on how you could do this using functionality already built into WiX. It is not perfect but a good starting point.

@iSazonov
Copy link
Collaborator Author

@bergmeister Thanks!

@SteveL-MSFT
Copy link
Member

Unassigning from @adityapatwardhan who is on leave

@iSazonov
Copy link
Collaborator Author

Did we have a proper fix?

@daxian-dbw
Copy link
Member

@iSazonov this issue got closed because #4540 mentioned 'Fixes #4315 and #2608'. Please re-open it if you don't think that PR fixes this issue.

@daxian-dbw daxian-dbw reopened this Aug 29, 2017
@daxian-dbw
Copy link
Member

@iSazonov I think it's safer to reopen it directly and let you close if you think #4540 fixed it.

@adityapatwardhan
Copy link
Member

@iSazonov with beta.7, we have a single package for all Windows OSs. Is it ok to close this issue?

@iSazonov
Copy link
Collaborator Author

I'll test this on next week.

@iSazonov
Copy link
Collaborator Author

I get an error on Windows Server 2012 for Test-Connection with Beta.7. 😕 I guess we can catch more errors if we run full test set on all supported platforms.

@adityapatwardhan
Copy link
Member

@iSazonov What error do you get for Test-Connection?

@iSazonov
Copy link
Collaborator Author
iSazonov commented Sep 19, 2017

On Windows Server 2012 (not R2):

PS C:\Program Files\PowerShell\6.0.0-beta.7> Test-Connection fs
Test-Connection : Unable to find an entry point named 'GetCurrentThread' in
DLL 'api-ms-win-core-processthreads-l1-1-2.dll'.
At line:1 char:1
+ Test-Connection fs
+ ~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Test-Connection], EntryPointN
   otFoundException
    + FullyQualifiedErrorId : System.EntryPointNotFoundException,Microsoft.Pow
   erShell.Commands.TestConnectionCommand

PS C:\Program Files\PowerShell\6.0.0-beta.7> $error[0].Exception | fl * -Force


Message        : Unable to find an entry point named 'GetCurrentThread' in DLL
                 'api-ms-win-core-processthreads-l1-1-2.dll'.
TypeName       :
Data           : {}
InnerException :
TargetSite     : Void* GetCurrentThread()
StackTrace     :    at GetCurrentThread()
                    at Microsoft.Management.Infrastructure.Native.SessionHandle
                 .ReleaseHandleAsynchronously(OnSessionHandleReleasedDelegate
                 completionCallback)
                    at Microsoft.Management.Infrastructure.Native.SessionHandle
                 .ReleaseHandle()
                    at
                 System.Runtime.InteropServices.SafeHandle.InternalDispose()
                    at Microsoft.Management.Infrastructure.CimSession.Dispose(B
                 oolean disposing)
                    at Microsoft.Management.Infrastructure.CimSession.Dispose()
                    at Microsoft.PowerShell.Commands.TestConnectionCommand.Proc
                 essWSManProtocolForTestConnection()
                    at Microsoft.PowerShell.Commands.TestConnectionCommand.Proc
                 essRecord()
                    at System.Management.Automation.Cmdlet.DoProcessRecord()
                    at
                 System.Management.Automation.CommandProcessor.ProcessRecord()
HelpLink       :
Source         : Microsoft.Management.Infrastructure.Native
HResult        : -2146233053

@SteveL-MSFT SteveL-MSFT added the Resolution-Fixed The issue is fixed. label Sep 19, 2017
@SteveL-MSFT
Copy link
Member

That issue is #2777

For the purpose of this original issue, since we have unified Windows packages now. We can close this.

@iSazonov
Copy link
Collaborator Author

The error is absent in previous builds - it is up with unified Windows packages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Maintainers-Build specific to affecting the build Resolution-Fixed The issue is fixed.
Projects
None yet
Development

No branches or pull requests

5 participants
0