Why does GetFirmwareEnvironmentVariable exist on a BIOS-based PC?

Question

Why does GetFirmwareEnvironmentVariable exist on a BIOS-based PC?

Norman Diamond 101

https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getfirmwareenvironmentvariablew

"Firmware variables are not supported on a legacy BIOS-based system. The GetFirmwareEnvironmentVariable function will always fail on a legacy BIOS-based system, or if Windows was installed using legacy BIOS on a system that supports both legacy BIOS and UEFI. To identify these conditions, call the function with a dummy firmware environment name such as an empty string ("") for the lpName parameter and a dummy GUID such as "{00000000-0000-0000-0000-000000000000}" for the lpGuid parameter. On a legacy BIOS-based system, or on a system that supports both legacy BIOS and UEFI where Windows was installed using legacy BIOS, the function will fail with ERROR_INVALID_FUNCTION."

But GetFirmwareEnvironmentVariable DIDN'T fail with ERROR_INVALID_FUNCTION. It failed with ERROR_PRIVILEGE_NOT_HELD. This made my program think the PC is UEFI-based. How can I detect that the PC is BIOS-based?

I think the MSDN document used to be correct in the past but a Windows Update broke it. How can I detect that the PC is BIOS-based?

RLWA32 49,551 Reputation points

2021-11-20T16:04:21.547+00:00

What does the function do if you try running with elevated privileges as administrator?
Castorix31 90,686 Reputation points

2021-11-20T16:17:53.317+00:00

How can I detect that the PC is BIOS-based?

Maybe with GetFirmwareType ?
Norman Diamond 101 Reputation points

2021-11-21T15:12:08.273+00:00

I was running with elevated privileges as administrator, after accepting the UAC prompt. The function failed with ERROR_PRIVILEGE_NOT_HELD.
Norman Diamond 101 Reputation points

2021-11-21T15:15:55.427+00:00

You're right, on Windows 8 and later. For Windows 7 and earlier I can't call GetFirmwareType but can use the code suggested by MSDN because GetFirmwareEnvironmentVariable returned ERROR_INVALID_FUNCTION in those days.

Accepted answer

2 additional answers

Your answer

RLWA32 49,551 Reputation points

2021-11-20T16:04:21.547+00:00

What does the function do if you try running with elevated privileges as administrator?
Castorix31 90,686 Reputation points

2021-11-20T16:17:53.317+00:00

How can I detect that the PC is BIOS-based?

Maybe with GetFirmwareType ?
Norman Diamond 101 Reputation points

2021-11-21T15:12:08.273+00:00

I was running with elevated privileges as administrator, after accepting the UAC prompt. The function failed with ERROR_PRIVILEGE_NOT_HELD.
Norman Diamond 101 Reputation points

2021-11-21T15:15:55.427+00:00

You're right, on Windows 8 and later. For Windows 7 and earlier I can't call GetFirmwareType but can use the code suggested by MSDN because GetFirmwareEnvironmentVariable returned ERROR_INVALID_FUNCTION in those days.

Answer 1

One PC has both Windows 7 and Windows 10 1703 installed (selectable by Windows 10's boot manager). In both, when running elevated as Administrator but not enabling SE_SYSTEM_ENVIRONMENT_NAME, MSDN's suggested attempt to call GetFirmwareEnvironmentVariable returns ERROR_INVALID_FUNCTION so I detect that the PC is BIOS-based.

(On that PC, Windows 10 repeatedly downloaded and failed to install newer versions of Windows 10 because of the display adapter, so I hid those updates.)

Some time after that, a Windows Update broke MSDN's code.

Yes the fix was to enable SE_SYSTEM_ENVIRONMENT_NAME. My program works now in Windows 7 (BIOS), Windows 10 1703 (BIOS), Windows 10 21H1 (BIOS), and Windows 10 21H1 (UEFI). I get ERROR_INVALID_FUNCTION on BIOS-based PCs. I didn't inspect what error is set in Windows 10 21H1 (UEFI) since the dummy firmware variable doesn't exist, but it wasn't ERROR_INVALID_FUNCTION so I detect that the PC is UEFI-based.

I still wonder why.

Answer 2

The documentation for the function indicates that "To read a firmware environment variable, the user account that the app is running under must have the SE_SYSTEM_ENVIRONMENT_NAME privilege."

In my quick tests the process calling the function must have the privilege (e.g., running as Administrator) AND the privilege must be enabled in the token before the function is called. If this is not done the function returns ERROR_PRIVILEGE_NOT_HELD. When the privilege is present and enabled then the function returns ERROR_INVALID_FUNCTION.

Answer 3

Norman Diamond 101

'The documentation for the function indicates that "To read a firmware environment variable [...]"'

On a BIOS-based PC there are no firmware environment variables. Meanwhile according to MSDN the function GetFirmwareEnvironmentVariable doesn't even exist if Windows was installed on a legacy BIOS. I don't actually need to read the value of a non-existent dummy variable when attempting the call that MSDN says to do; I just need to find out if the function exists or not the way MSDN says to do.

Furthermore MSDN's suggested code used to work. Why did MSDN's code stop working? Why did a Windows Update add a function on BIOS-based Windows installations that isn't supposed to exist on BIOS-based Windows installations?

RLWA32 49,551 Reputation points

2021-11-21T11:24:31.247+00:00

Meanwhile according to MSDN the function GetFirmwareEnvironmentVariable doesn't even exist if Windows was installed on a legacy BIOS.

I don't know why you think this. The documentation says "The GetFirmwareEnvironmentVariable function will always fail on a legacy BIOS-based system, or if Windows was installed using legacy BIOS on a system that supports both legacy BIOS and UEFI."

And the function documentation indicates that the minimum supported clients are "Windows Vista, Windows XP with SP1 [desktop apps | UWP apps]". So it doesn't seem to me that a recent Windows Update added the function.
Castorix31 90,686 Reputation points

2021-11-21T12:06:12.357+00:00

according to MSDN the function GetFirmwareEnvironmentVariable doesn't even exist if Windows was installed on a legacy BIOS

It is exported from Kernel and calls NtQuerySystemEnvironmentValueEx, so it has always existed (since XP SP1)
RLWA32 49,551 Reputation points

2021-11-21T12:14:40.093+00:00

I think what you are seeing is that at some point Microsoft added the requirement that the caller of the function have the SE_SYSTEM_ENVIRONMENT_NAME privilege. Of course, I'm only guessing.

I went back to several old VMs that I have and ran my small test program. Even through Windows 10 1809 the function returned ERROR_INVALID_FUNCTION while running as standard user.
Norman Diamond 101 Reputation points

2021-11-21T15:07:22.217+00:00

'I don't know why you think this.'

I guess I misinterpreted the meaning of "ERROR_INVALID_FUNCTION".

'And the function documentation indicates that the minimum supported clients are "Windows Vista, Windows XP with SP1 [desktop apps | UWP apps]".'

I wonder if there was an IA64 version of Windows XP. The AMD64 version of Windows XP couldn't be installed if the PC booted in UEFI mode. But if the function existed then somehow "ERROR_INVALID_FUNCTION" was returned by an existing function, not by a non-existing function.

In an older version of Windows 10 and in Windows 7, I didn't need to enable SE_SYSTEM_ENVIRONMENT_NAME privilege to get "ERROR_INVALID_FUNCTION".
Norman Diamond 101 Reputation points

2021-11-21T15:09:49.913+00:00

Yes that seems to be what happened. My program doesn't run as a standard user; the user has to approve the UAC prompt. But even running as an administrator, I didn't need to enable SE_SYSTEM_ENVIRONMENT_NAME privilege to get "ERROR_INVALID_FUNCTION".
RLWA32 49,551 Reputation points

2021-11-21T15:19:45.757+00:00

Well, if the process is running as Administrator then enabling the privilege as discussed resolves the problem.

Share via

Why does GetFirmwareEnvironmentVariable exist on a BIOS-based PC?

2 additional answers

Your answer