Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Get-ComputerInfo : Unable to find an entry point named 'GetFirmwareType' in DLL 'kernel32.dll'." #3023

Closed
n3l5 opened this issue Jan 20, 2017 · 10 comments
Closed

Get-ComputerInfo : Unable to find an entry point named 'GetFirmwareType' in DLL 'kernel32.dll'." #3023

n3l5 opened this issue Jan 20, 2017 · 10 comments
Labels
Resolution-Fixed The issue is fixed. Up-for-Grabs Up-for-grabs issues are not high priorities, and may be opportunities for external contributors WG-Cmdlets general cmdlet issues

Comments

@n3l5
Copy link

n3l5 commented Jan 20, 2017 •
edited by joeyaiello

Error Message:
"Get-ComputerInfo : Unable to find an entry point named 'GetFirmwareType' in DLL 'kernel32.dll'."

Environment:

Windows Management Framework 5.1
Operating System: Windows 7 x64

Examples

PS C:\Users\user> Get-ComputerInfo -Property OsInstallDate
Get-ComputerInfo : Unable to find an entry point named 'GetFirmwareType' in DLL 'kernel32.dll'.
At line:1 char:1
+ Get-ComputerInfo -Property OsInstallDate
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-ComputerInfo], EntryPointNotFoundException
    + FullyQualifiedErrorId : System.EntryPointNotFoundException,Microsoft.PowerShell.Commands.GetComputerInfoCommand

PS C:\Users\user> Get-ComputerInfo -Property TimeZone
Get-ComputerInfo : Unable to find an entry point named 'GetFirmwareType' in DLL 'kernel32.dll'.
At line:1 char:1
+ Get-ComputerInfo -Property TimeZone
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-ComputerInfo], EntryPointNotFoundException
    + FullyQualifiedErrorId : System.EntryPointNotFoundException,Microsoft.PowerShell.Commands.GetComputerInfoCommand

Name                           Value
----                           -----
PSVersion                      5.1.14409.1005
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14409.1005
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
@iSazonov
Copy link
Collaborator

@n3l5 Thanks for bug report!

GetFirmwareType is introduced in Windows 8 and Windows Server 2012

@joeyaiello joeyaiello added the WG-Cmdlets general cmdlet issues label Jan 23, 2017
@joeyaiello
Copy link
Contributor

Given the behavior isn't there on Win7, I'm not sure what we can do other than do a better of job of erroring out. We also wouldn't ship a change for that unless we had a hypothetical WMF 5.2, though I'm not speaking here to whether that's happening or not.

@n3l5
Copy link
Author

n3l5 commented Jan 23, 2017

Unless there is an option to feature request a kernel fix for Win 7 to support this, can be closed out since this appears to be a kernel feature and Win 7 is on the way out.

@joeyaiello
Copy link
Contributor

Thanks @n3l5!

@iSazonov iSazonov added the Resolution-Won't Fix The issue won't be fixed, possibly due to compatibility reason. label Mar 15, 2017
@zii-dmg
Copy link

zii-dmg commented Mar 19, 2017

Isn't solution is just one if check for windows version in GetComputerInfoCommand.cs?

@SteveL-MSFT SteveL-MSFT added Up-for-Grabs Up-for-grabs issues are not high priorities, and may be opportunities for external contributors and removed Resolution-Won't Fix The issue won't be fixed, possibly due to compatibility reason. labels Mar 19, 2017
@SteveL-MSFT SteveL-MSFT reopened this Mar 19, 2017
@SteveL-MSFT
Copy link
Member

We should wrap the api calls so this fails silently.

@jeffbi
Copy link
Contributor

jeffbi commented Mar 20, 2017

Just as a point of interest, at the time this cmdlet was written the target OS was Win10.

Fortunately there aren't too many native API calls, so wrapping them shouldn't be too onerous.

@SteveL-MSFT I can take this one if you like.

@iSazonov
Copy link
Collaborator

Perhaps it is time to start porting this cmdlet instead of doing partial fixes. It would be good to do it in Beta time.

@SteveL-MSFT
Copy link
Member

Making it cross-platform is a pretty big task and probably something we'd do for 6.1.0. @jeffbi it should be pretty straightforward to wraps so they silentlycontinue for current release.

@jeffbi jeffbi mentioned this issue Mar 22, 2017
Merged
@zii-dmg
Copy link

zii-dmg commented Apr 12, 2017

Alpha 18 no longer crash on GetFirmwareType in Windows 7, but other strange crash - #3541.

@iSazonov iSazonov added the Resolution-Fixed The issue is fixed. label Apr 13, 2017
@jmilacek jmilacek mentioned this issue May 31, 2017
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Resolution-Fixed The issue is fixed. Up-for-Grabs Up-for-grabs issues are not high priorities, and may be opportunities for external contributors WG-Cmdlets general cmdlet issues
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@joeyaiello @zii-dmg @n3l5 @jeffbi @SteveL-MSFT @iSazonov