I have done some tests with that function in Windows 10.

1. Call RtlGetExtendedContextLength, allocate a buffer with the returned length.

2. Pass that buffer as CONTEXT_EX to RtlInitializeExtendedContext which also returns CONTEXT in the first parameter.

Not necessarily, the actual context data location maybe ahead of the first parameter buffer to provide alignment (there is a test for that in dlls/ntdll/exception.c:test_extended_context()).

3. Use that CONTEXT_EX buffer to RtlLocateLegacyContext. Now check the returned CONTEXT structure pointer with the 2nd step one.

Yes, sure, and there is also the test for that. But I am not sure how all that can give any clue how RtlLocateLegacyContext is defined somewhere. The patch that you introduce should not result in binary difference in the compiled code. It is not possible to test what pointer type the (undocumented) function returns, only to look that up if the function prototype is publicly available.

Also there is a hint in the function name "RtlLocateLegacyContext" itself. CONTEXT_EX holds the offsets of "Legacy" context (in wdm.h). And by doing the pointer arithmetic "context_ex + context_ex->Legacy.Offset", RtlLocateLegacyContext should return a CONTEXT pointer.

You can't guess declared pointer type from test, only test the values. That information is simply not there in the machine code and thus not testable.

I agreed with your logic and it's true. But if one wants to get the WoW-ed CONTEXT, he/she already has to set the appropriate CONTEXT pointer structure type as return value.It depends on the flag in RtlGetExtendedContextLength function.

Or that program willing to use this sort of function is a debugger and simply got that structure from somewhere. The debugger might be x64, while the debugged program might be x86 and that context has nothing to do with 'CONTEXT' defined in the headers for debugger.

I think if there is an intention to use this context management API it is strictly preferable to use kernel32 functions (like InitContext, LocateXStateFeature etc.) instead of these undocumented ntdll functions.