IDXGISwapchain::Present compatibility break in Fall Creators Update? RRS feed

  • Question

  • Hi,

    I have a DX11 rendering stuff which is kind of an emulator for old games.
    However, after upgrading to Fall Creators Update me (and others) badly experienced that it isn't working properly anymore.

    I myself noticed that applications using this renderer loses the window focus, and some of them jumps into minimized state because of that.
    The point is, I traced down the cause.

    Every single call to IDXGISwapchain::Present checks if the window of the swapchain is occluded or not by other windows.
    If it is, and the swapchain is in fullscreen mode then DXGI force-switches the swapchain into windowed mode. It's the way how it worked so far.

    DXGI::Present's occlusion detection algorhytm roughly does the following:
    First of all, it uses an invisible proxy window (named DXGIProxyWindow but renamed to D3DProxyWnd in FCU) for fullscreen state which is deeper in the window-z order list than the swapchain rendering window itself. Then, starting from the z-level of the proxy window, it steps upward in the z-hiearchy, window by window (max 200 steps) and checks every single window if that occludes the proxy one.

    What changed in FCU: DXGI::Present now checks if the proxy window is fully occluded by another one, and if it is, then it not only switches the swapchain into windowed mode but even 'switches away' from the application, see the following code snippet:

    5EF6A220 FF 15 F8 40 FA 5E    call        dword ptr [__imp__GetForegroundWindow@0 (5EFA40F8h)]  
    5EF6A226 3B 86 C0 00 00 00    cmp         eax,dword ptr [esi+0C0h]  
    5EF6A22C 75 23                jne         ATL::CComObject<CDXGILightweightDevice>::Release+0F931h (5EF6A251h)  
    5EF6A22E FF 15 FC 40 FA 5E    call        dword ptr [__imp__GetDesktopWindow@0 (5EFA40FCh)]                                    <----
    5EF6A234 50                   push        eax  
    5EF6A235 FF 15 00 41 FA 5E    call        dword ptr [__imp__SetForegroundWindow@4 (5EFA4100h)]                                 <---- 
    5EF6A23B 85 C0                test        eax,eax  
    5EF6A23D 75 12                jne         ATL::CComObject<CDXGILightweightDevice>::Release+0F931h (5EF6A251h)  
    5EF6A23F FF 15 40 20 FA 5E    call        dword ptr [__imp__GetLastError@0 (5EFA2040h)]  
    5EF6A245 51                   push        ecx  
    5EF6A246 68 10 B9 F3 5E       push        offset string "SetForegroundWindow failed to sw"... (5EF3B910h)                        <---- "SetForegroundWindow failed to switch away from the app"
    5EF6A24B 50                   push        eax  
    5EF6A24C E8 6F DB FD FF       call        CModule::RecordJournalImpl (5EF47DC0h)  
    5EF6A251 6A 00                push        0  
    5EF6A253 6A 00                push        0  
    5EF6A255 8B CE                mov         ecx,esi  
    5EF6A257 E8 71 C1 FE FF       call        CDXGISwapChain::ScenarioEnterOrLeaveFullscreen (5EF563CDh) 

    My problem is that in FCU DXGI usually finds that the proxy window (which has the same size and position) is fully occluded by the swapchain rendering window.
    In other words, the swapchain window is occluded by itself, so DXGI 'switches away' from my application.

    I checked out one game with which the problem is steadily reproducible: on FCU, DXGI always run into that self-occlusion problem, but never on Win Creators Update.
    I can't really understand the difference because the occlusion detection function seems to be the same for both. In spite of that, on FCU the algorhytm finds its own window when stepping up in the z-hierachy, but not on CU. Something with the z-hiearchy, and on CU the cycle exits before finds its own window, I guess.

    EDIT: I attach a debugger screenshot about the problem:

    -- (I'd gladly do, but my account isn't verified so I can't do it.) ---

    As you can see, CheckOcclusion finds 'SplinterCellUnrealWWindowsViewportWindow' as the occluding one, but this window is the rendering window of the swapchain. Spy++ clearly shows that it's only 3 levels above the DXGI proxy window 'D3DProxyWindow' in the z-hiearchy. On CU, DXGI never runs onto this path.

    My question is, is there anything I could do to avoid this case?
    If not, then PLZ Microsoft, fix it somehow because I cannot and do not want to hack or workaround this from the driving side (my code).

    • Edited by Diosg Saturday, November 4, 2017 9:32 AM
    • Moved by Hart Wang Wednesday, November 8, 2017 7:05 AM
    Friday, November 3, 2017 1:03 PM

All replies

  • Hi Diosg,

    Thank you for posting here.

    Did you get any error message?  The error would be helpful for solving issue.

    I am not sure that the windows creator update cause the issue. If it is a bug, you could post the issue on connect website, which handle bug issue on windows.

    Since your issue is related to DX11, the xboxforums supports it, you can post the issue on there. I will move the case to off-topic.

    Best Regards,


    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, November 6, 2017 2:12 AM