Uploaded image for project: 'Core ReactOS'
  1. Core ReactOS
  2. CORE-18221

Display mode switch problem in VMWare after my recent win32k improvements

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Untriaged
    • Priority: Major
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: Win32SS
    • Labels:
      None
    • Environment:

      VMWare Workstation 16.2.3 with VMWare SVGA II driver installed.

      Description

      This problem happens after applying https://github.com/reactos/reactos/pull/4519, which contains addition of DirectDraw management during changing display mode. After trying to apply a new mode, exception with page fault is happening (see dxg.log):

      WARNING:  LDEVOBJ_bUnloadImage at /win32ss/gdi/eng/ldevobj.c:290 is UNIMPLEMENTED!
      (/win32ss/gdi/eng/pdevobj.c:348) DxDdEnableDirectDraw(ppdev E16FCB58)
      
      Entered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fault)
      Memory at 0x00000000 could not be accessed
      kdb:> bt
      Eip:
      <00000000>
      Frames:
      <win32k.sys:18a4b (win32ss/gdi/eng/pdevobj.c:615 (PDEVOBJ_Create))>
      <win32k.sys:14012 (win32ss/gdi/eng/mdevobj.c:113 (MDEVOBJ_Create))>
      <win32k.sys:191db (win32ss/gdi/eng/pdevobj.c:951 (PDEVOBJ_lChangeDisplaySettings))>
      <win32k.sys:98f25 (win32ss/user/ntuser/winsta.c:264 (co_IntInitializeDesktopGraphics))>
      <win32k.sys:46e07 (win32ss/user/ntuser/guicheck.c:27 (co_AddGuiApp))>
      <win32k.sys:46e7b (win32ss/user/ntuser/guicheck.c:61 (co_IntGraphicsCheck))>
      <win32k.sys:87348 (win32ss/user/ntuser/windc.c:44 (DceCreateDisplayDC))>
      <win32k.sys:87415 (win32ss/user/ntuser/windc.c:94 (DceAllocDCE))>
      <win32k.sys:87c2f (win32ss/user/ntuser/windc.c:488 (UserGetDCEx))>
      <win32k.sys:88816 (win32ss/user/ntuser/windc.c:985 (NtUserGetDCEx))>
      <win32k.sys:88934 (win32ss/user/ntuser/windc.c:1016 (NtUserGetDC))>
      <ntoskrnl.exe:3fe5 (:0 (KiSystemCallTrampoline))>
      <ntoskrnl.exe:14fcfd (ntoskrnl/ke/i386/traphdlr.c:1840 (KiSystemServiceHandler))>
      <ntoskrnl.exe:3e2f (:0 (KiFastCallEntry))>
      <ntdll.dll:10181>
      <user32.dll:44951>
      <user32.dll:4853e>
      <msgina.dll:3e01>
      <kernel32.dll:1c97b>
      

      As visible, it immediately fails due to uninitialized buffer when it tries to call the 1st DXG function (DxDdEnableDirectDraw). It happens because DirectX graphics driver (dxg.sys), from which these functions are called, is not loaded in memory. Ideally, it should be always loaded in memory, like in Windows. So to fix this, we need to load it at the system startup and keep it loaded until the user shutdowns the system. Therefore, if it will be always loaded, it will be always available. If it will be always available, then we will not have any problems when try to use it and call any functions from there.
      I investigated how it's done in Windows. At first, it's managed by win32k!DxDdStartupDxGraphics functions, which loads dxg.sys in memory. It is called from one of the win32k startup routines named InitializeGreCSRSS(). This function also does initialization of font table, stock fonts and something else. In its turn, it is called from NtUserInitialize(), the main initialization routine of win32k's ntuser subsystem. Also important note is, it passes gpepCSRSS (global csrss EPROCESS handle) in the last Proc parameter of DxDdStartupDxGraphics(). All other parameters are NULL/zero.
      I have implemented only DXG part of InitalizeGreCSRSS(). I didn't implement other parts (those initialize fonts stuff an so on), because 1) I'm not sure hot to implement it properly (which functions I should call, I don't know our equivalents of MS functions those I saw in WinDBG unassemble of InitializeGreCSRSS()). 2) That stuff is out of the purpose of this ticket and my fix for it.
      Attaching my analysis results here as well, together with a patch containing my fix: dx_startup_analysis.txt dxg_init.patch. Will open a PR soon.
      As result, after my changes, dxg.sys is properly loaded at startup, and is always loaded in memory. So there is no problem using it anymore, and the bug does no longer happen.

      P.S.: Build tested: 0.4.15-dev-4675-g1a41e62.

        Attachments

        1. dx_startup_analysis.txt
          10 kB
        2. dxg_init.patch
          2 kB
        3. dxg.log
          37 kB

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              Oleg Dubinskij Oleg Dubinskiy
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: