wdk Vista mirror driver

After making the needed changes my mirror driver is back runnning in Vista.
But it act the same as before, directx stuff (like screensavers) generate a
black screen.
In the documentation "3 lines of extra info" they mention
GCAPS2_EXCLUDELAYERED GCAPS2_INCLUDEAPIBITMAP
but no futher usage doc is available.

Tha sample mirror driver have the function DrvRenderhint() this seems to be
total undocumented.

1) Does the mirror driver on Vista have a way to capture directx ?
2) Is there any documentation available about the changes between
XP and Vista and usage of the new options ?

Ivan
Fri Oct 06 04:17:54 CDT 2006

If the machine where you have installed the mirror driver has an WDDM
(formerly known as LDDM) video card, then, you should get all the
direct-draw
and DirectX context presented through GDI.
Here is a code-path how it is seen by the in-the-box mirror driver
rdpencdd.dll.

931ff500 900215eb fe0cce70 fe52c4d0 00000000 RDPENCDD!DrvBitBlt
931ff534 9021b416 fe0cce70 fe52c4d0 fe024458 RDPENCDD!DrvCopyBits+0x2f
931ff580 9034c068 fe0968d8 fe52c4d0 fe024458 win32k!WatchdogDrvCopyBits+0x53
931ff5c8 9034fcfe 9021b3c6 931ff670 fe0cce70 win32k!OffCopyBits+0x7d
931ff67c 9034fe50 fe0cce70 fe52c4d0 00000000 win32k!SpBitBlt+0xfc
931ff6b0 9034c068 fe0cce70 fe52c4d0 fe024458 win32k!SpCopyBits+0x27
931ff6f8 9037db7f 9034fe29 fe5c2920 fe0cce70 win32k!OffCopyBits+0x7d
931ff834 9037dc3f fe05fe70 fe52c4d0 00000000 win32k!MulBitBlt+0x34d
931ff868 902e4dee fe05fe70 fe52c4d0 fe02d788 win32k!MulCopyBits+0x27
931ff928 903481d9 ff802548 fe02d788 ff87c008 win32k!NtGdiBitBlt+0x5da
931ff9a8 893be6ad 3308067e 00000000 9a7b5308 win32k!DxgkEngBltViaGDI+0x1f6
931ffb84 8938e80e 0087c008 931ffcf8 931fc462
dxgkrnl!DXGCONTEXT::Present+0xa76
931ffd38 81c4503f 00000010 0006f678 77f23b2c dxgkrnl!DxgkPresent+0x271
931ffd38 77f23b2c 00000010 0006f678 77f23b2c nt!KiFastCallEntry+0x12c
0006f65c 77bc6220 6cec59c9 0103fd6c 00e2e390 ntdll!KiFastSystemCallRet
0006f660 6cec59c9 0103fd6c 00e2e390 00e34b40 GDI32!NtGdiDdDDIPresent+0xc
0006f678 6a2dc1ad 0103fcc0 0006f68c 00f6dc18 d3d9!PresentCB+0xc6
0006f694 6a2b3118 00f6dc18 0006f88c 0103fcc0 atiumdag!cmdBufPresent+0x9d
0006f758 6cf5738a 00e34b40 0006f860 0006f964 atiumdag!d3dlhPresent+0x208
0006f874 6cf92370 00106d90 010285c0 010151a0 d3d9!DdBltLH+0x4cb
0006fb10 6cec5844 01015254 00000000 0102acb4 d3d9!DdBlt+0xdc
0006fba0 6cf02fbb 00000000 00000000 00000000
d3d9!CSwapChain::PresentMain+0xa99
0006fbd0 6cf02f4a 00000000 00000000 00000000
d3d9!CBaseDevice::PresentMain+0x78
0006fbf4 01002317 010285c0 00000000 00000000 d3d9!CBaseDevice::Present+0x59
0006fca0 01002373 00022388 00130498 0000000f
TestD3D!TstChildWnd::WindowProc+0x14e
0006fcbc 77ce2f21 00130498 0000000f 00000000
TestD3D!TstChildWnd::sWindowProc+0x22
0006fce8 77ce2ff9 01002351 00130498 0000000f USER32!InternalCallWinProc+0x23
0006fd60 77cda152 00000000 01002351 00130498
USER32!UserCallWinProcCheckWow+0x14b
0006fdbc 77cda4d6 00867d08 0000000f 00000000
USER32!DispatchClientMessage+0xda
0006fde4 77f23a66 0006fdfc 00000018 0006fe4c USER32!__fnDWORD+0x24
0006fe10 77cdb0e3 77cdb11e 0006feb0 00067542
ntdll!KiUserCallbackDispatcher+0x2e
0006fe14 77cdb11e 0006feb0 00067542 01000000
USER32!NtUserDispatchMessage+0xc
0006fe5c 77ce3066 01002351 00000000 0006ff0c
USER32!DispatchMessageWorker+0x38c
0006fe6c 010024db 0006feb0 01004390 00000001 USER32!DispatchMessageW+0xf
0006ff0c 01002874 00030460 00000000 00180d9a TestD3D!wWinMain+0x11c
0006ffa0 77e4a8f3 7ffd8000 0006ffec 77f28166
TestD3D!_wWinMainCRTStartup+0x138
0006ffac 77f28166 7ffd8000 0006df4f 00000000
kernel32!BaseThreadInitThunk+0xe
0006ffec 00000000 010028f2 7ffd8000 00000000 ntdll!_RtlUserThreadStart+0x23

For the other flags:
GCAPS2_EXCLUDELAYERED
A mirror driver can set this flag if it choose to not see
the sprites as they are processed by the GDI Sprite Manager.

GCAPS2_INCLUDEAPIBITMAP and DrvRenderHint
has to be both implemented if a mirror driver wishes to see
the draweing operations happening on selected Eng-Managed bitmaps.

The fundamental problem of any display driver is off-screen rendering
in Memory DCs instead of Compatible DCs.
If an application chooses to pre-render it's content in an off-screen DIB,
then, the display driver can only see the final result, and not any
intermediate
drawing operation.
The system in Vista uses pervasively layered windows and
other intermediate DIBs. Then the problem of getting, for example, the
actual text
in DrvTextOut was unsolvable, since the driver would have seen only
the final blit to the primary surface in DrvBitBlt.
To compensate for that, NtGdi notifies the mirror driver that
certain SURFOBJs are special (NtGdi calls DrvRenderHint to tell that),
and, later, on, NtGdi "informs" the mirror driver that certain draweing
operations
have been performed on the above mentioned SURFOBJs, in addition to the
traditional STYPE_DEVICE and STYPE_DEVBITMAP surfaces.

I'm not sure at this point what will be eventually documented in the
DDK for mirror drivers, but, this should give you an idea

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Rudi De Vos" <ultravnc@nospam.nospam> wrote in message
news:4BA39D9C-694C-49A3-9C25-AD28AF123023@microsoft.com...
> After making the needed changes my mirror driver is back runnning in
> Vista.
> But it act the same as before, directx stuff (like screensavers) generate
> a
> black screen.
> In the documentation "3 lines of extra info" they mention
> GCAPS2_EXCLUDELAYERED GCAPS2_INCLUDEAPIBITMAP
> but no futher usage doc is available.
>
> Tha sample mirror driver have the function DrvRenderhint() this seems to
> be
> total undocumented.
>
> 1) Does the mirror driver on Vista have a way to capture directx ?
> 2) Is there any documentation available about the changes between
> XP and Vista and usage of the new options ?
>
>
>
>

ultravnc
Fri Oct 06 05:17:01 CDT 2006

Thanks for the fast answer.

I'm using a LDDM. If sample screendrivers are using directx it seems not to
work with my code. While screensaver is active, mirror debug output display
nothing...
(not even the drv functions are called)
I will cross check it with the provided sample,but at first sight, the only
difference seems to be that i have not implemented DrvCreateDeviceBitmap
,DrvDeleteDeviceBitmap...

Has the DDI_DRIVER_VERSION an impact on the behavior ?

I'm using EngCreateDeviceSurface/EngModifySurface for DrvEnableSurface
perhaps i need to use EngCreateBitmap

A little hint to share, Using Vista mirror driver, don't expect that Dest
Surface
(Like for DrvTextout) exist like for XP. This is often NULL. Fail to check
give a hard to debug BSOD.

"Ivan Brugiolo [MSFT]" wrote:

> If the machine where you have installed the mirror driver has an WDDM
> (formerly known as LDDM) video card, then, you should get all the
> direct-draw
> and DirectX context presented through GDI.
> Here is a code-path how it is seen by the in-the-box mirror driver
> rdpencdd.dll.
>
> 931ff500 900215eb fe0cce70 fe52c4d0 00000000 RDPENCDD!DrvBitBlt
> 931ff534 9021b416 fe0cce70 fe52c4d0 fe024458 RDPENCDD!DrvCopyBits+0x2f
> 931ff580 9034c068 fe0968d8 fe52c4d0 fe024458 win32k!WatchdogDrvCopyBits+0x53
> 931ff5c8 9034fcfe 9021b3c6 931ff670 fe0cce70 win32k!OffCopyBits+0x7d
> 931ff67c 9034fe50 fe0cce70 fe52c4d0 00000000 win32k!SpBitBlt+0xfc
> 931ff6b0 9034c068 fe0cce70 fe52c4d0 fe024458 win32k!SpCopyBits+0x27
> 931ff6f8 9037db7f 9034fe29 fe5c2920 fe0cce70 win32k!OffCopyBits+0x7d
> 931ff834 9037dc3f fe05fe70 fe52c4d0 00000000 win32k!MulBitBlt+0x34d
> 931ff868 902e4dee fe05fe70 fe52c4d0 fe02d788 win32k!MulCopyBits+0x27
> 931ff928 903481d9 ff802548 fe02d788 ff87c008 win32k!NtGdiBitBlt+0x5da
> 931ff9a8 893be6ad 3308067e 00000000 9a7b5308 win32k!DxgkEngBltViaGDI+0x1f6
> 931ffb84 8938e80e 0087c008 931ffcf8 931fc462
> dxgkrnl!DXGCONTEXT::Present+0xa76
> 931ffd38 81c4503f 00000010 0006f678 77f23b2c dxgkrnl!DxgkPresent+0x271
> 931ffd38 77f23b2c 00000010 0006f678 77f23b2c nt!KiFastCallEntry+0x12c
> 0006f65c 77bc6220 6cec59c9 0103fd6c 00e2e390 ntdll!KiFastSystemCallRet
> 0006f660 6cec59c9 0103fd6c 00e2e390 00e34b40 GDI32!NtGdiDdDDIPresent+0xc
> 0006f678 6a2dc1ad 0103fcc0 0006f68c 00f6dc18 d3d9!PresentCB+0xc6
> 0006f694 6a2b3118 00f6dc18 0006f88c 0103fcc0 atiumdag!cmdBufPresent+0x9d
> 0006f758 6cf5738a 00e34b40 0006f860 0006f964 atiumdag!d3dlhPresent+0x208
> 0006f874 6cf92370 00106d90 010285c0 010151a0 d3d9!DdBltLH+0x4cb
> 0006fb10 6cec5844 01015254 00000000 0102acb4 d3d9!DdBlt+0xdc
> 0006fba0 6cf02fbb 00000000 00000000 00000000
> d3d9!CSwapChain::PresentMain+0xa99
> 0006fbd0 6cf02f4a 00000000 00000000 00000000
> d3d9!CBaseDevice::PresentMain+0x78
> 0006fbf4 01002317 010285c0 00000000 00000000 d3d9!CBaseDevice::Present+0x59
> 0006fca0 01002373 00022388 00130498 0000000f
> TestD3D!TstChildWnd::WindowProc+0x14e
> 0006fcbc 77ce2f21 00130498 0000000f 00000000
> TestD3D!TstChildWnd::sWindowProc+0x22
> 0006fce8 77ce2ff9 01002351 00130498 0000000f USER32!InternalCallWinProc+0x23
> 0006fd60 77cda152 00000000 01002351 00130498
> USER32!UserCallWinProcCheckWow+0x14b
> 0006fdbc 77cda4d6 00867d08 0000000f 00000000
> USER32!DispatchClientMessage+0xda
> 0006fde4 77f23a66 0006fdfc 00000018 0006fe4c USER32!__fnDWORD+0x24
> 0006fe10 77cdb0e3 77cdb11e 0006feb0 00067542
> ntdll!KiUserCallbackDispatcher+0x2e
> 0006fe14 77cdb11e 0006feb0 00067542 01000000
> USER32!NtUserDispatchMessage+0xc
> 0006fe5c 77ce3066 01002351 00000000 0006ff0c
> USER32!DispatchMessageWorker+0x38c
> 0006fe6c 010024db 0006feb0 01004390 00000001 USER32!DispatchMessageW+0xf
> 0006ff0c 01002874 00030460 00000000 00180d9a TestD3D!wWinMain+0x11c
> 0006ffa0 77e4a8f3 7ffd8000 0006ffec 77f28166
> TestD3D!_wWinMainCRTStartup+0x138
> 0006ffac 77f28166 7ffd8000 0006df4f 00000000
> kernel32!BaseThreadInitThunk+0xe
> 0006ffec 00000000 010028f2 7ffd8000 00000000 ntdll!_RtlUserThreadStart+0x23
>
> For the other flags:
> GCAPS2_EXCLUDELAYERED
> A mirror driver can set this flag if it choose to not see
> the sprites as they are processed by the GDI Sprite Manager.
>
> GCAPS2_INCLUDEAPIBITMAP and DrvRenderHint
> has to be both implemented if a mirror driver wishes to see
> the draweing operations happening on selected Eng-Managed bitmaps.
>
> The fundamental problem of any display driver is off-screen rendering
> in Memory DCs instead of Compatible DCs.
> If an application chooses to pre-render it's content in an off-screen DIB,
> then, the display driver can only see the final result, and not any
> intermediate
> drawing operation.
> The system in Vista uses pervasively layered windows and
> other intermediate DIBs. Then the problem of getting, for example, the
> actual text
> in DrvTextOut was unsolvable, since the driver would have seen only
> the final blit to the primary surface in DrvBitBlt.
> To compensate for that, NtGdi notifies the mirror driver that
> certain SURFOBJs are special (NtGdi calls DrvRenderHint to tell that),
> and, later, on, NtGdi "informs" the mirror driver that certain draweing
> operations
> have been performed on the above mentioned SURFOBJs, in addition to the
> traditional STYPE_DEVICE and STYPE_DEVBITMAP surfaces.
>
> I'm not sure at this point what will be eventually documented in the
> DDK for mirror drivers, but, this should give you an idea
>
> --
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
> Use of any included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
>
> "Rudi De Vos" <ultravnc@nospam.nospam> wrote in message
> news:4BA39D9C-694C-49A3-9C25-AD28AF123023@microsoft.com...
> > After making the needed changes my mirror driver is back runnning in
> > Vista.
> > But it act the same as before, directx stuff (like screensavers) generate
> > a
> > black screen.
> > In the documentation "3 lines of extra info" they mention
> > GCAPS2_EXCLUDELAYERED GCAPS2_INCLUDEAPIBITMAP
> > but no futher usage doc is available.
> >
> > Tha sample mirror driver have the function DrvRenderhint() this seems to
> > be
> > total undocumented.
> >
> > 1) Does the mirror driver on Vista have a way to capture directx ?
> > 2) Is there any documentation available about the changes between
> > XP and Vista and usage of the new options ?
> >
> >
> >
> >
>
>
>

Ivan
Fri Oct 06 11:56:43 CDT 2006

Maybe the DX ScreenSaver creates a full screen render-target,
instead of a windowed render-target.

Can you set a breakpoint in win32k!DxgkEngBltViaGDI when
the mirror driver is loaded ? This would tell if the mirror driver is
supposed to be called to begin with.

For the last comment, I'm afraid you are referring to
SURFOBJ::dhpdev, and not to SURFOBJ itself.
If it's the case, then, your driver is probably called with a Sprite as the
destination.
This should really not happen. Can you provide at least a callstack of the
issue ?

BTW, this is the callstack for rdpencdd (mirror driver) with the 3d screen
saver

1: kd> kb 100
ChildEBP RetAddr Args to Child
910f65d0 8dc2348d ff9f78c8 ff882e70 00000000 RDPENCDD_8dc20000!DrvBitBlt
910f6610 8de4bc84 ff9f78c8 ff882e70 fdc5e528
RDPENCDD_8dc20000!DrvCopyBits+0x55
910f665c 8df096e4 fdcdb8d8 ff882e70 fdc5e528 win32k!WatchdogDrvCopyBits+0x53
910f66a4 8df8c659 8de4bc31 ff9c87d0 ff9f78c8 win32k!OffCopyBits+0x7d
910f67e0 8df8c719 fdc42640 ff882e70 00000000 win32k!MulBitBlt+0x34d
910f6814 8def2a63 fdc42640 ff882e70 00000000 win32k!MulCopyBits+0x27
910f68f4 8defa1d7 fdc42630 ff881598 ff900a48 win32k!NtGdiBitBlt+0x59c
910f69a0 8886525f 910f6bc4 00000000 94e766e8 win32k!DxgkEngBltViaGDI+0x2bf
910f6ba4 88866563 00881598 910f6d18 9187e9ed
dxgkrnl!DXGCONTEXT::Present+0x9c0
910f6d58 8184630a 00000010 0007c538 774fbac4 dxgkrnl!DxgkPresent+0x271
910f6d58 774fbac4 00000010 0007c538 774fbac4 nt!KiFastCallEntry+0x12a
0007c51c 76ae75bc 6ef0415e 01091fbc 011a5fc8 ntdll!KiFastSystemCallRet
0007c520 6ef0415e 01091fbc 011a5fc8 02b25e30 GDI32!NtGdiDdDDIPresent+0xc
0007c538 6d41358b 01091f00 0007c550 02b25e30 d3d9!PresentCB+0xc8
0007c660 6d413926 011aee10 00000000 00bc63b4
atiumdag!d3dlhOpenResource+0x38b
0007c748 6ef52bd5 011aee10 0007c860 01075e40 atiumdag!d3dlhPresent+0x376
0007c87c 6ef47ac1 01092c80 00000000 01078534 d3d9!DdBltLH+0x56a
0007c914 6ef48d42 00000000 00000000 00000000
d3d9!CSwapChain::PresentMain+0xb09
0007c944 6ef48cd1 00000000 00000000 00000000
d3d9!CBaseDevice::PresentMain+0x78
0007c968 00cbdfe4 01075e40 00000000 00000000 d3d9!CBaseDevice::Present+0x59
0007c994 00cbfee3 00cdfeec 0007c9e4 00000000
ssText3d!CD3DScreensaver::Render3DEnvironment+0x132
0007c9c8 00cbff51 000d1ad9 00000000 0007c9e4
ssText3d!CD3DScreensaver::DoSaver+0xaf
0007c9dc 00cb418f 00ca1660 00000002 00000000
ssText3d!CD3DScreensaver::Run+0x1e
0007f7e0 00cb51da 00ca0000 00000000 000d1ad9 ssText3d!WinMain+0x5e
0007f870 76b62219 7ffd3000 0007f8bc 774d46e8 ssText3d!__mainCRTStartup+0x140
0007f87c 774d46e8 7ffd3000 00078aef 00000000
kernel32!BaseThreadInitThunk+0xe
0007f8bc 00000000 00cb5350 7ffd3000 00000000 ntdll!_RtlUserThreadStart+0x23

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Rudi De Vos" <ultravnc@nospam.nospam> wrote in message
news:223C5589-B6A4-4BCA-ACB9-13C0E262857F@microsoft.com...
> Thanks for the fast answer.
>
> I'm using a LDDM. If sample screendrivers are using directx it seems not
> to
> work with my code. While screensaver is active, mirror debug output
> display
> nothing...
> (not even the drv functions are called)
> I will cross check it with the provided sample,but at first sight, the
> only
> difference seems to be that i have not implemented DrvCreateDeviceBitmap
> ,DrvDeleteDeviceBitmap...
>
> Has the DDI_DRIVER_VERSION an impact on the behavior ?
>
> I'm using EngCreateDeviceSurface/EngModifySurface for DrvEnableSurface
> perhaps i need to use EngCreateBitmap
>
> A little hint to share, Using Vista mirror driver, don't expect that Dest
> Surface
> (Like for DrvTextout) exist like for XP. This is often NULL. Fail to
> check
> give a hard to debug BSOD.
>
> "Ivan Brugiolo [MSFT]" wrote:
>
>> If the machine where you have installed the mirror driver has an WDDM
>> (formerly known as LDDM) video card, then, you should get all the
>> direct-draw
>> and DirectX context presented through GDI.
>> Here is a code-path how it is seen by the in-the-box mirror driver
>> rdpencdd.dll.
>>
>> 931ff500 900215eb fe0cce70 fe52c4d0 00000000 RDPENCDD!DrvBitBlt
>> 931ff534 9021b416 fe0cce70 fe52c4d0 fe024458 RDPENCDD!DrvCopyBits+0x2f
>> 931ff580 9034c068 fe0968d8 fe52c4d0 fe024458
>> win32k!WatchdogDrvCopyBits+0x53
>> 931ff5c8 9034fcfe 9021b3c6 931ff670 fe0cce70 win32k!OffCopyBits+0x7d
>> 931ff67c 9034fe50 fe0cce70 fe52c4d0 00000000 win32k!SpBitBlt+0xfc
>> 931ff6b0 9034c068 fe0cce70 fe52c4d0 fe024458 win32k!SpCopyBits+0x27
>> 931ff6f8 9037db7f 9034fe29 fe5c2920 fe0cce70 win32k!OffCopyBits+0x7d
>> 931ff834 9037dc3f fe05fe70 fe52c4d0 00000000 win32k!MulBitBlt+0x34d
>> 931ff868 902e4dee fe05fe70 fe52c4d0 fe02d788 win32k!MulCopyBits+0x27
>> 931ff928 903481d9 ff802548 fe02d788 ff87c008 win32k!NtGdiBitBlt+0x5da
>> 931ff9a8 893be6ad 3308067e 00000000 9a7b5308
>> win32k!DxgkEngBltViaGDI+0x1f6
>> 931ffb84 8938e80e 0087c008 931ffcf8 931fc462
>> dxgkrnl!DXGCONTEXT::Present+0xa76
>> 931ffd38 81c4503f 00000010 0006f678 77f23b2c dxgkrnl!DxgkPresent+0x271
>> 931ffd38 77f23b2c 00000010 0006f678 77f23b2c nt!KiFastCallEntry+0x12c
>> 0006f65c 77bc6220 6cec59c9 0103fd6c 00e2e390 ntdll!KiFastSystemCallRet
>> 0006f660 6cec59c9 0103fd6c 00e2e390 00e34b40 GDI32!NtGdiDdDDIPresent+0xc
>> 0006f678 6a2dc1ad 0103fcc0 0006f68c 00f6dc18 d3d9!PresentCB+0xc6
>> 0006f694 6a2b3118 00f6dc18 0006f88c 0103fcc0 atiumdag!cmdBufPresent+0x9d
>> 0006f758 6cf5738a 00e34b40 0006f860 0006f964 atiumdag!d3dlhPresent+0x208
>> 0006f874 6cf92370 00106d90 010285c0 010151a0 d3d9!DdBltLH+0x4cb
>> 0006fb10 6cec5844 01015254 00000000 0102acb4 d3d9!DdBlt+0xdc
>> 0006fba0 6cf02fbb 00000000 00000000 00000000
>> d3d9!CSwapChain::PresentMain+0xa99
>> 0006fbd0 6cf02f4a 00000000 00000000 00000000
>> d3d9!CBaseDevice::PresentMain+0x78
>> 0006fbf4 01002317 010285c0 00000000 00000000
>> d3d9!CBaseDevice::Present+0x59
>> 0006fca0 01002373 00022388 00130498 0000000f
>> TestD3D!TstChildWnd::WindowProc+0x14e
>> 0006fcbc 77ce2f21 00130498 0000000f 00000000
>> TestD3D!TstChildWnd::sWindowProc+0x22
>> 0006fce8 77ce2ff9 01002351 00130498 0000000f
>> USER32!InternalCallWinProc+0x23
>> 0006fd60 77cda152 00000000 01002351 00130498
>> USER32!UserCallWinProcCheckWow+0x14b
>> 0006fdbc 77cda4d6 00867d08 0000000f 00000000
>> USER32!DispatchClientMessage+0xda
>> 0006fde4 77f23a66 0006fdfc 00000018 0006fe4c USER32!__fnDWORD+0x24
>> 0006fe10 77cdb0e3 77cdb11e 0006feb0 00067542
>> ntdll!KiUserCallbackDispatcher+0x2e
>> 0006fe14 77cdb11e 0006feb0 00067542 01000000
>> USER32!NtUserDispatchMessage+0xc
>> 0006fe5c 77ce3066 01002351 00000000 0006ff0c
>> USER32!DispatchMessageWorker+0x38c
>> 0006fe6c 010024db 0006feb0 01004390 00000001 USER32!DispatchMessageW+0xf
>> 0006ff0c 01002874 00030460 00000000 00180d9a TestD3D!wWinMain+0x11c
>> 0006ffa0 77e4a8f3 7ffd8000 0006ffec 77f28166
>> TestD3D!_wWinMainCRTStartup+0x138
>> 0006ffac 77f28166 7ffd8000 0006df4f 00000000
>> kernel32!BaseThreadInitThunk+0xe
>> 0006ffec 00000000 010028f2 7ffd8000 00000000
>> ntdll!_RtlUserThreadStart+0x23
>>
>> For the other flags:
>> GCAPS2_EXCLUDELAYERED
>> A mirror driver can set this flag if it choose to not see
>> the sprites as they are processed by the GDI Sprite Manager.
>>
>> GCAPS2_INCLUDEAPIBITMAP and DrvRenderHint
>> has to be both implemented if a mirror driver wishes to see
>> the draweing operations happening on selected Eng-Managed bitmaps.
>>
>> The fundamental problem of any display driver is off-screen rendering
>> in Memory DCs instead of Compatible DCs.
>> If an application chooses to pre-render it's content in an off-screen
>> DIB,
>> then, the display driver can only see the final result, and not any
>> intermediate
>> drawing operation.
>> The system in Vista uses pervasively layered windows and
>> other intermediate DIBs. Then the problem of getting, for example, the
>> actual text
>> in DrvTextOut was unsolvable, since the driver would have seen only
>> the final blit to the primary surface in DrvBitBlt.
>> To compensate for that, NtGdi notifies the mirror driver that
>> certain SURFOBJs are special (NtGdi calls DrvRenderHint to tell that),
>> and, later, on, NtGdi "informs" the mirror driver that certain draweing
>> operations
>> have been performed on the above mentioned SURFOBJs, in addition to the
>> traditional STYPE_DEVICE and STYPE_DEVBITMAP surfaces.
>>
>> I'm not sure at this point what will be eventually documented in the
>> DDK for mirror drivers, but, this should give you an idea
>>
>> --
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> Use of any included script samples are subject to the terms specified at
>> http://www.microsoft.com/info/cpyright.htm
>>
>>
>> "Rudi De Vos" <ultravnc@nospam.nospam> wrote in message
>> news:4BA39D9C-694C-49A3-9C25-AD28AF123023@microsoft.com...
>> > After making the needed changes my mirror driver is back runnning in
>> > Vista.
>> > But it act the same as before, directx stuff (like screensavers)
>> > generate
>> > a
>> > black screen.
>> > In the documentation "3 lines of extra info" they mention
>> > GCAPS2_EXCLUDELAYERED GCAPS2_INCLUDEAPIBITMAP
>> > but no futher usage doc is available.
>> >
>> > Tha sample mirror driver have the function DrvRenderhint() this seems
>> > to
>> > be
>> > total undocumented.
>> >
>> > 1) Does the mirror driver on Vista have a way to capture directx ?
>> > 2) Is there any documentation available about the changes between
>> > XP and Vista and usage of the new options ?
>> >
>> >
>> >
>> >
>>
>>
>>

ultravnc
Sat Oct 07 10:54:01 CDT 2006

Indeed, i installed the directx SDK and tried the samples.
Using Window mode all is perfect displayed, fullscreen -> black
I guess this is the normal behaviour, and for our application (ultravnc)
full screen directx for the screensavers would only consume to mutch network
bandwidth.


DrvTextout( IN SURFOBJ *psoDest..)
{
...
mirrorsurf= (MIRRORSURF *) psoDst->dhsurf
if (mirrorsurf==NULL) return FALSE; <<<------Added
..
}
The psoDest exist, but the dhsurf reffer to NULL.
Adding the extra check does not make it slower and all is working. It was
bad programming by not checking it on w2k/XP...Special for drivers.

(dhsurf == NULL) happen when using clasic theme and right click on background
It's not only drvtextout, but also other functions have the same issue.

Thanks for the help, i should have tested it in window mode.
screenshot
http://sc.uvnc.com/demo.jpg

callstack: I never has done it before, if it could be usefull for you i need
some info
or page refferences for generating it.

Greeting
Rudi

Ivan
Mon Oct 09 10:43:47 CDT 2006

# further comment on SURFOBJ in a mirror driver.

The check should be something like.

if (STYPE_DEVBITMAP == pSo->iType ||
STYPE_DEVICE == pSo->iType) {
// do some kind of network encoding
return TRUE;
} else if (NULL == pSo->dhSurf && STYPE_BITMAP == pSo->iType) {
// this is an Eng-Managed surface, punt-to-eng
return EngXXX(pSo);
} else {
return FALSE;
}

One more comment:
When you have a DrvXXX operation that takes one
destination SURFOBJ, then, you should never get a STYPE_BITMAP surface.
But, when you have a DrvXXX operation that takes TWO surfaces
(eg: DrvCopyBits, DrvBitBlt) then, you are expected to receive at least one
device managed SURFOBJ, but, the other SURFOBJ
can legitimately be a STYPE_BITMAP.

This would make sense with the fact that you said
it never occurred in DrvTextOut, that is a single destination operation,
but, you received that in some other DrvXXX call.
I would recomend to extra check those cases, because returning FALSE
from them would not be the correct thing to do.

# callstack
If you are using the kernel debugger (as any kernel mode developer should),
the callstack of a bugcheck can be generated by issuing the `kb` command.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Rudi De Vos" <ultravnc@nospam.nospam> wrote in message
news:DF7A45DC-4301-4A4C-A6AA-95D65E1D419B@microsoft.com...
> Indeed, i installed the directx SDK and tried the samples.
> Using Window mode all is perfect displayed, fullscreen -> black
> I guess this is the normal behaviour, and for our application (ultravnc)
> full screen directx for the screensavers would only consume to mutch
> network
> bandwidth.
>
>
> DrvTextout( IN SURFOBJ *psoDest..)
> {
> ...
> mirrorsurf= (MIRRORSURF *) psoDst->dhsurf
> if (mirrorsurf==NULL) return FALSE; <<<------Added
> ..
> }
> The psoDest exist, but the dhsurf reffer to NULL.
> Adding the extra check does not make it slower and all is working. It was
> bad programming by not checking it on w2k/XP...Special for drivers.
>
> (dhsurf == NULL) happen when using clasic theme and right click on
> background
> It's not only drvtextout, but also other functions have the same issue.
>
> Thanks for the help, i should have tested it in window mode.
> screenshot
> http://sc.uvnc.com/demo.jpg
>
> callstack: I never has done it before, if it could be usefull for you i
> need
> some info
> or page refferences for generating it.
>
> Greeting
> Rudi

Maxim
Wed Oct 11 00:47:17 CDT 2006

> If the machine where you have installed the mirror driver has an WDDM
> (formerly known as LDDM)

Sorry, but am I wrong that WDDM means - only pre-Vista style display driver,
while LDDM means - new Vista-style?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Ivan
Wed Oct 11 11:56:50 CDT 2006

For the longest time, the Vista display dirver model was called LDDM,
while the WindowsXP display driver model was called XPDM.
Then, somebody changed LDDM in WDDM.

WDDM == LDDM == Vista model
[AKA, no display DLL, a user mode component loaded by d3d9.dll
and a kernel mode miniport used by dxgkrnl.sys]

XPDM
[Display Driver DLL with DX support plus miniport].

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:OAHWiiP7GHA.2248@TK2MSFTNGP04.phx.gbl...
>> If the machine where you have installed the mirror driver has an WDDM
>> (formerly known as LDDM)
>
> Sorry, but am I wrong that WDDM means - only pre-Vista style display
> driver,
> while LDDM means - new Vista-style?
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>

Maxim
Wed Oct 11 15:40:54 CDT 2006

> WDDM == LDDM == Vista model
> [AKA, no display DLL, a user mode component loaded by d3d9.dll
> and a kernel mode miniport used by dxgkrnl.sys]

How is good old GDI mapped to this? Is Desktop Composition involved in this? Is
this mapping layer in win32k or somewhere else?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Ivan
Wed Oct 11 18:02:13 CDT 2006

There is a system provided display driver, called cdd.dll, that is in
charge all the times that desktop composition in NOT active.
cdd.dll is a Punt-to-Eng display driver, and, furthermore, it performs
synchronization with video memory with a custom interface with dxgkrnl.sys.
When there is desktop composition active, then,
there is no display driver whatsoever, and, the GDI applications are
redirected
to eng-managed bitmaps.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:%23hmh1VX7GHA.4568@TK2MSFTNGP02.phx.gbl...
>> WDDM == LDDM == Vista model
>> [AKA, no display DLL, a user mode component loaded by d3d9.dll
>> and a kernel mode miniport used by dxgkrnl.sys]
>
> How is good old GDI mapped to this? Is Desktop Composition involved in
> this? Is
> this mapping layer in win32k or somewhere else?
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>

Maxim
Wed Oct 11 18:13:22 CDT 2006

> There is a system provided display driver, called cdd.dll, that is in
> charge all the times that desktop composition in NOT active.
> cdd.dll is a Punt-to-Eng display driver, and, furthermore, it performs
> synchronization with video memory with a custom interface with dxgkrnl.sys.

So, cdd.dll is an old pre-Vista video driver, which is 100% universal wrapper
(conceptually) around the WDDM drivers and is based on DDraw/D3D facilities of
the underlying hardware and the WDDM driver? is it so?

> When there is desktop composition active, then,
> there is no display driver whatsoever, and, the GDI applications are
> redirected
> to eng-managed bitmaps.

Am I correct that, with desktop composition, win32k remembers the bitmap for
each window (kinda like CS_SAVEBITS), that GetDC and BeginPaint return a DC
which references this internal bitmap (and not the screen DC with customized
CLIPOBJ and coordinate origin, as it was in pre-Vista Windows since 16-bit
3.0), and that then this bitmap is rendered to the real screen by desktop
composition engine itself? is it so?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Ivan
Wed Oct 11 20:52:51 CDT 2006

> So, cdd.dll is an old pre-Vista video driver, which is 100% universal
> wrapper
> (conceptually) around the WDDM drivers and is based on DDraw/D3D
> facilities of
> the underlying hardware and the WDDM driver? is it so?
>
Yes. The only point is that it uses a custom interface against dxgkrnl.sys
that causes dxgkrnl!DXGCONTEXT::SubmitPresent to be called.

> Am I correct that, with desktop composition, win32k remembers the bitmap
> for
> each window (kinda like CS_SAVEBITS), that GetDC and BeginPaint return a
> DC
> which references this internal bitmap (and not the screen DC with
> customized
> CLIPOBJ and coordinate origin, as it was in pre-Vista Windows since 16-bit
> 3.0), and that then this bitmap is rendered to the real screen by desktop
> composition engine itself? is it so?
>
Partially yes.
NtUser was anyway saving the bitmap for each window privided that the
window was created as layered and/or redirected. Immagine that in
compose desktop mode each window is layered by the system.

The CS_SAVEBITS flag was only used for parts of the window
(for example, you had a pop-up menu in a CS_SAVEBITS window. In this case,
NtUser was saving the bits of the window, popping-up the menu, and restoring
the bits of the window without asking the window to redraw).
CS_SAVEBITS was a temporary trick bound to the specific operation,
and, it was optional, in the sense that NtUser could choose
to always ask the window to redraw.

GetDC and /or GetWindowDC can reference the redirection bitmap
instead of the primary surface of the display driver, in redirection mode.

The final bitmap that builds up a window is presented to the screen
after it has become a IDirect3DSurface9/IDirect3dTexture9,
as part of the render pass for the screen.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:OrbLBrY7GHA.3644@TK2MSFTNGP03.phx.gbl...
>> There is a system provided display driver, called cdd.dll, that is in
>> charge all the times that desktop composition in NOT active.
>> cdd.dll is a Punt-to-Eng display driver, and, furthermore, it performs
>> synchronization with video memory with a custom interface with
>> dxgkrnl.sys.
>
> So, cdd.dll is an old pre-Vista video driver, which is 100% universal
> wrapper
> (conceptually) around the WDDM drivers and is based on DDraw/D3D
> facilities of
> the underlying hardware and the WDDM driver? is it so?
>
>> When there is desktop composition active, then,
>> there is no display driver whatsoever, and, the GDI applications are
>> redirected
>> to eng-managed bitmaps.
>
> Am I correct that, with desktop composition, win32k remembers the bitmap
> for
> each window (kinda like CS_SAVEBITS), that GetDC and BeginPaint return a
> DC
> which references this internal bitmap (and not the screen DC with
> customized
> CLIPOBJ and coordinate origin, as it was in pre-Vista Windows since 16-bit
> 3.0), and that then this bitmap is rendered to the real screen by desktop
> composition engine itself? is it so?
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>

Maxim
Wed Oct 11 21:00:21 CDT 2006

> NtUser was anyway saving the bitmap for each window privided that the
> window was created as layered and/or redirected. Immagine that in
> compose desktop mode each window is layered by the system.

Thanks for the answer. Looks like I must refresh my USER32 knowledge about
layered and redirected windows. In what OS version did they appear?

> CS_SAVEBITS was a temporary trick bound to the specific operation,
> and, it was optional, in the sense that NtUser could choose
> to always ask the window to redraw.

Oh, I see. I remember that Windows 3.0 had a SaveScreenBitmap in the video
driver to this very purpose. Was it connected with CS_SAVEBITS?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Ivan
Thu Oct 12 11:28:25 CDT 2006

> Looks like I must refresh my USER32 knowledge about
> layered and redirected windows. In what OS version did they appear?

Layered windows appeared in Windows 2000.

> Oh, I see. I remember that Windows 3.0 had a SaveScreenBitmap in the video
> driver to this very purpose. Was it connected with CS_SAVEBITS?

Yes, it was connected, in the sense that a CS_SAVEBITS window
could cause NtUser to ask NtGdi to ask the display driver to save the area
underneath the Pop-Up menu.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:uGYmUIa7GHA.4568@TK2MSFTNGP02.phx.gbl...
>> NtUser was anyway saving the bitmap for each window privided that the
>> window was created as layered and/or redirected. Immagine that in
>> compose desktop mode each window is layered by the system.
>
> Thanks for the answer. Looks like I must refresh my USER32 knowledge about
> layered and redirected windows. In what OS version did they appear?
>
>> CS_SAVEBITS was a temporary trick bound to the specific operation,
>> and, it was optional, in the sense that NtUser could choose
>> to always ask the window to redraw.
>
> Oh, I see. I remember that Windows 3.0 had a SaveScreenBitmap in the video
> driver to this very purpose. Was it connected with CS_SAVEBITS?
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>