[Bug 10525] HLSW 2 crashes at start

http://bugs.winehq.org/show_bug.cgi?id=10525

Anastasius Focht  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #9 from Anastasius Focht   2008-03-22 17:23:16 ---
Hello,

FindResourceExW is not to blame here.
The real problem is that the client is causing a page fault in resource
enumeration callback proc while enumerating through RT_MENU resources.

At the point of the page fault, the app has several chained SEH's installed,
mainly C++ exception handlers.
By comparing SEH chains I found the problem (and obvious solution).
In Windows there sits a system installed SEH between the app SEH which is
installed on resource enum callback entry and the next app SEH installed by app
function which calls EnumResourceNamesW.

wine SEH chain (fictive names for illustration):

<rogue_code_here>
app_SEH_res_enum_callback (C++ handler)
app_SEH_blah1 (C++ handler)
app_SEH_blah2 (C++ handler)
...

windows SEH chain (fictive names for illustration):

<rogue_code_here>
app_SEH_res_enum_callback (C++ handler)
sys_SEH_res_enum (page fault handler)
app_SEH_blah1 (C++ handler)
app_SEH_blah2 (C++ handler)
...

This is probably a precaution of windows to safeguard against rogue app code
while calling client supplied resource enum callbacks.
The solution is to add SEH for page faults to all resource enum functions which
call app supplied callbacks.

Pseudo code example:

--- snip dlls/kernel32/resource.c ---
BOOL WINAPI EnumResourceNamesW( ...)
{
..
    __TRY
    {
        /* resource enumeration loop */
        for( ...)
        {
            /* call client enum proc (callback) which might cause page fault */
            ret = pfn( args);  
        }
    }
    __EXCEPT_PAGE_FAULT
    {
        status = STATUS_ACCESS_VIOLATION;
        ret = FALSE;
    }
    __ENDTRY
..
    if (status != STATUS_SUCCESS) SetLastError( RtlNtStatusToDosError(status)
);
    return ret;
}
--- snip dlls/kernel32/resource.c ---

Although guarding only EnumResourceNamesW() seems to let the app's login screen
come up, I suggest to add SEH's to all resource enumeration functions which
call client supplied callbacks.
To verify this behaviour, you could write test cases which supply page fault
causing callbacks when calling each resource enum API.
Ideally, the SEH of EnumResourceXXX caller should never see page faults ;-)

Regards