我在Windows UAC的上下文中使用"提升"(即以管理员身份运行(。
检查进程是否被提升的标准方法似乎是使用OpenProcess来获取该进程的句柄，然后使用OpenProcessToken来获得该进程的访问令牌，然后使用具有TokenElevation或TokenElelectionType类的GetTokenInformation()，最后检查结果信息。
但是，OpenProcessToken要求进程句柄具有PROCESS_QUERY_INFORMATION权限，因此具有讽刺意味的是，如果检查进程没有提升，而被检查的进程是(根据我的测试，在这种情况下尝试使用OpenProcess会导致拒绝访问错误(，则无法执行此检查。
人们可以认为这意味着流程被提升，但这并不完全正确，因为我认为这种结果的另一种可能性只是流程是由另一个用户启动的。
在许多情况下，尝试所需的操作、查找拒绝访问错误并从那里开始可能会更容易，但在一个特定的情况下，我需要启动一个外部应用程序，并且我希望以管理员身份启动它，这取决于第三个进程是否以管理员身份运行。由于在这种情况下"；只是在尝试我想做的事"；比起简单地调用一两个函数，我更感兴趣的是，对于一个未提升的进程来说，可能有一种更直接的方法来检查另一个进程是否被提升(包括当它被提升时，非常有趣(。
如果目标流程的所有者是检查流程的同一帐户，那么您可以在没有任何特殊权限的情况下检查流程的提升。
但是，如果目标进程的所有者是检查提升的进程的不同帐户，则检查进程将需要启用特权SE_DEBUG_NAME。为了启用此权限，通常需要提升进程。
感谢RbMm(和Hantalyte间接(，我已经意识到OpenProcessToken的Microsoft文档断言所提供的句柄必须具有PROCESS_QUERY_INFORMATION访问权限是不正确的，因为它实际上只要求句柄具有PROCESS_QUERY_LIMITED_INFORMATION(我已经通过自己的测试证实了这一点(。
只要两个进程都是从同一个帐户启动的，就可以在权限为PROCESS_QUERY_LIMITED_INFORMATION的非提升进程中获得提升进程的句柄，这意味着可以使用我提出的问题中的过程来检查其他进程的提升，尽管由于文档错误，该过程不起作用。
正如Hantalyte/RbMm所指出的，如果被检查的进程由不同的帐户所有，则检查进程需要启用SE_DEBUG_NAME权限。
希望MS文档能尽快得到更正。
更新：修正PR已合并。
更新2:更正现已生效：https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-openprocesstoken