Supported Win32 LPAC token verification before ResumeThread – Windows 11 26H2 (build 26300.9818)

Pål Bernhardsen 0 Reputation points
2026-11-03T11:25:05.4833333+00:00

Title: Supported Win32 LPAC token verification before ResumeThread – Windows 11 26H2 (build 26300.9818)

Hello Microsoft Windows Development team,

We are developing a security-sensitive Windows process-isolation controller and need to verify that a newly created child process actually has a Less Privileged AppContainer (LPAC) token before its suspended primary thread is resumed.

Target environment

  • Operating system: Windows 11 Home

Version: 26H2

OS build: 26300.9818

Architecture: x64

API: GetTokenInformation

Information class: TokenIsLessPrivilegedAppContainer

Token: Child process primary token

Process creation: CreateProcessW, CREATE_SUSPENDED, STARTUPINFOEX

Our design requires a fail-closed verification step before calling ResumeThread. Successfully setting LPAC-related process creation attributes or confirming ordinary AppContainer status is not sufficient.

The Win32 documentation lists TokenIsLessPrivilegedAppContainer, but does not appear to specify its complete class-specific output contract. The WDK documentation describes a DWORD result, where nonzero indicates LPAC, but we have not established whether this contract applies to GetTokenInformation.

We would appreciate authoritative clarification of the following:

Is GetTokenInformation(TokenIsLessPrivilegedAppContainer) officially supported for querying a newly created, suspended child process's primary token before its first ResumeThread?

What are the required output type, buffer size, alignment, valid values and ReturnLength semantics? Does the WDK DWORD description explicitly apply to this Win32 call?

Is this combination supported on Windows 11 Home 26H2, build 26300.9818, x64? Are there additional process-creation or token-state requirements?

Are PROCESS_QUERY_LIMITED_INFORMATION and TOKEN_QUERY sufficient, subject to the relevant security descriptors, or are additional rights required?

How can callers distinguish unsupported information classes, insufficient buffers, access failures and a successful result indicating that the token is not LPAC?

If this query is not supported, is there another documented user-mode mechanism that provides equivalent LPAC verification before the child's primary thread is resumed?

We have reviewed the relevant Win32 and WDK documentation and prior Microsoft Q&A discussions. We are seeking a documented, supportable API contract rather than relying on inferred buffer layouts or behavior observed on a single Windows build.

If this requires clarification from the Windows security or token API team, a referral to the appropriate team or official support channel would be appreciated.

Thank you for your assistance.

Kind regards,

AirPax Development TeamTitle: Supported Win32 LPAC token verification before ResumeThread – Windows 11 26H2 (build 26300.9818)

Hello Microsoft Windows Development team,

We are developing a security-sensitive Windows process-isolation controller and need to verify that a newly created child process actually has a Less Privileged AppContainer (LPAC) token before its suspended primary thread is resumed.

Target environment

Operating system: Windows 11 Home

Version: 26H2

OS build: 26300.9818

Architecture: x64

API: GetTokenInformation

Information class: TokenIsLessPrivilegedAppContainer

Token: Child process primary token

Process creation: CreateProcessW, CREATE_SUSPENDED, STARTUPINFOEX

Our design requires a fail-closed verification step before calling ResumeThread. Successfully setting LPAC-related process creation attributes or confirming ordinary AppContainer status is not sufficient.

The Win32 documentation lists TokenIsLessPrivilegedAppContainer, but does not appear to specify its complete class-specific output contract. The WDK documentation describes a DWORD result, where nonzero indicates LPAC, but we have not established whether this contract applies to GetTokenInformation.

We would appreciate authoritative clarification of the following:

Is GetTokenInformation(TokenIsLessPrivilegedAppContainer) officially supported for querying a newly created, suspended child process's primary token before its first ResumeThread?

What are the required output type, buffer size, alignment, valid values and ReturnLength semantics? Does the WDK DWORD description explicitly apply to this Win32 call?

Is this combination supported on Windows 11 Home 26H2, build 26300.9818, x64? Are there additional process-creation or token-state requirements?

Are PROCESS_QUERY_LIMITED_INFORMATION and TOKEN_QUERY sufficient, subject to the relevant security descriptors, or are additional rights required?

How can callers distinguish unsupported information classes, insufficient buffers, access failures and a successful result indicating that the token is not LPAC?

If this query is not supported, is there another documented user-mode mechanism that provides equivalent LPAC verification before the child's primary thread is resumed?

We have reviewed the relevant Win32 and WDK documentation and prior Microsoft Q&A discussions. We are seeking a documented, supportable API contract rather than relying on inferred buffer layouts or behavior observed on a single Windows build.

If this requires clarification from the Windows security or token API team, a referral to the appropriate team or official support channel would be appreciated.

Thank you for your assistance.

Kind regards,

AirPax Development Team

Windows development | Windows API - Win32
0 comments

1 answer

Sort by: Newest
Most helpful Newest Oldest
  1. Harry Nguyen (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff Moderator
    2026-11-04T02:20:17.6833333+00:00

    Hi @Pål Bernhardsen ,
    Thank you for your patience while I reviewed the available Microsoft documentation. I went through your questions separately, as some aspects are documented by the public Win32 APIs, while others do not currently have the same level of class-specific detail. 

    1. Process and token access requirements 

    For OpenProcessToken, the documentation states that the process handle must have PROCESS_QUERY_LIMITED_INFORMATION. The requested token access is then evaluated against the token's DACL. The documentation also notes additional security-context considerations, such as SE_DEBUG_NAME when checking a process started by a different account. 

    For GetTokenInformation, TOKEN_QUERY is required for all TOKEN_INFORMATION_CLASS values except TokenSource, which requires TOKEN_QUERY_SOURCE.  

    Therefore, PROCESS_QUERY_LIMITED_INFORMATION and TOKEN_QUERY are the documented access requirements for these respective operations, subject to the applicable DACL and security context. 

    2. Querying while the primary thread is suspended 

    The documentation states that a thread created with CREATE_SUSPENDED does not begin execution until ResumeThread is called. This allows work to be performed before the suspended thread begins executing.  

    However, while these documents establish the suspended-thread behavior, I could not find an explicit public documentation statement covering GetTokenInformation(TokenIsLessPrivilegedAppContainer) on the child process's primary token specifically before the first ResumeThread. 

    3. TokenIsLessPrivilegedAppContainer output contract 

    The Win32 TOKEN_INFORMATION_CLASS documentation states that GetTokenInformation uses values from this enumeration and includes TokenIsLessPrivilegedAppContainer. However, while TokenIsAppContainer explicitly states that the buffer receives a DWORD whose nonzero value indicates an AppContainer token, the Win32 entry for TokenIsLessPrivilegedAppContainer describes LPAC but does not define the corresponding output buffer type, size, alignment, or value interpretation. 

    The WDK version provides additional information: it states that TokenIsLessPrivilegedAppContainer returns a DWORD value that is nonzero when the token is for an LPAC. However, that documentation introduces TOKEN_INFORMATION_CLASS in the context of SeQueryInformationToken and ZwQueryInformationToken.  

    I could not find a public Microsoft document that explicitly establishes this WDK class-specific DWORD description as the documented Win32 GetTokenInformation contract. Therefore, for a security-sensitive implementation, I would avoid treating that correspondence as an explicit Win32 API guarantee. 

    The general GetTokenInformation contract does document the buffer mechanics: TokenInformationLength specifies the supplied buffer size, ReturnLength receives the required number of bytes, and the function returns zero on failure, with GetLastError providing extended error information. 

    What the public Win32 documentation does not currently define for this specific information class is the exact output layout, alignment, valid values, successful ReturnLength semantics, or class-specific error mapping. 

    4. LPAC process creation 

    Microsoft does document how to launch an LPAC. The Launch an AppContainer documentation shows an LPAC being configured through STARTUPINFOEX, PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES, and the additional PROC_THREAD_ATTRIBUTE_ALL_APPLICATION_PACKAGES_POLICY attribute with PROCESS_CREATION_ALL_APPLICATION_PACKAGES_OPT_OUT. It then uses that startup information when creating the process.  

    This provides a documented LPAC creation path. However, I did not find documentation presenting successful creation through these attributes as an independent post-creation verification of the resulting primary token, which is the additional guarantee your fail-closed design requires. 

    5. Areas not clearly established by the public documentation 

    For the remaining parts of your scenario, I could not find sufficiently explicit information in the currently published Microsoft documentation to confirm: 

    • the complete class-specific Win32 output contract for TokenIsLessPrivilegedAppContainer; 
    • whether the WDK DWORD description is explicitly the contract for Win32 GetTokenInformation; 
    • class-specific alignment and successful ReturnLength semantics; 
    • class-specific error mapping that would distinguish an unsupported information class from the other relevant failure conditions; 
    • a build-specific guarantee for Windows 11 Home 26H2, build 26300.9818, x64; 
    • or another documented user-mode API providing equivalent independent LPAC verification before the first ResumeThread. 

    Given that this verification forms part of a security-sensitive, fail-closed design, I would be cautious about relying on undocumented buffer assumptions or behavior observed only on a particular Windows build. 

    For authoritative confirmation of the class-specific API contract and build-specific guarantees that are not explicitly covered by the public documentation, I recommend contacting Microsoft Developer Support. The Windows SDK technical support channel would be better positioned to provide or route an authoritative clarification for this scenario.  

    If you found this helpful, you can refer to this guidance to confirm it and help others with similar questions. 

    Thank you.

    Was this answer helpful?

    1 person found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.