This problem is not seen on Vista 32 or any XP platform.

I'm working on a system with a dual-head grayscale graphics card, XPDM
drivers only. Certain actions will cause the screen to start flashing, and
the only way to stop the flashing is CTRL-ALT-DEL to bring up the secure
desktop. Any change in the display configuration causes the flashing; also
opening the remote desktop client.

There is no error reported, but the system event log shows several entries:
"The Desktop Window Manager was unable to start because a composited theme is
not in use."

Disabling the Desktop Window Manager (UxSms) service prevents the flashing
screen, but causes other issues -- desktop background disappears when opening
Media Player, won't reappear until you open the desktop background control
panel.

This (flashing) problem does not appear in 32-bit Vista and the UxSms
service does not have to be disabled.
--
Michael Wheeler

While the screen is flashing, can you check if dwm.exe is in a loop
with a thread stuck in d3d9.dll in a call to ChangeDisplaySettings ?

Last time I debugged this one, the problem was caused by root-enumerated
videoprt.sys children not being able to change the display-set uniqueness.
This was causing the DirectDraw code in d3d9.dll to belive that
it had to query the display-device-configuration till the display-set change
and it had reached a stable-state.

To fix this, can you call DwmEnableComposition(FALSE) before
you manipulate the root-enuemrated video-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


"Michael Wheeler" <MichaelWheeler@discussions.microsoft.com> wrote in
message news:5B22D46B-0C31-4D0D-8664-4B6891DC3E8C@microsoft.com...

What I see is a bunch of calls to IOCTL_VIDEO_GET_CHILD_STATE, followed by
IOCTL_VIDEO_QUERY_NUM_AVAIL_MODES, followed by IOCTL_VIDEO_QUERY_AVAIL_MODES,
and then back to IOCTL_VIDEO_GET_CHILD_STATE. So this sounds similar to what
you are describing.
Can I call DwmEnableComposition from within a video miniport driver?
--
Michael Wheeler


"Ivan Brugiolo [MSFT]" wrote:

You will have to do that before the user-mode
application calls ChangeDisplaySettingsEx.

Or, for a manual stable repro, try `net stop UxSms` before
you enable your external monitor.

--

--
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


"Michael Wheeler" <MichaelWheeler@discussions.microsoft.com> wrote in
message news:4D971951-457A-4DE2-929C-2355DF3C1459@microsoft.com...

Ah. Well, here's the problem -- we write the video driver, and have no
control over the user applications. Since we don't see the problem in 32-bit
Vista, I'm inclined to think it's a bug in Vista 64 -- that there are
applications, such as Media Player, desk.cpl, and the remote desktop client,
that should be making the call to DwmEnableComposition.
--
Michael Wheeler


"Ivan Brugiolo [MSFT]" wrote:

It is an issue with several pieces in the Vista OS, and it is not x64
specific.
Probably in the machine when you experience the problem
you have something different (maybe an XPDM driver is already installed,
maybe the desktop composition has a different start-up timing).

You can either escalate the issue to the CSS of your country,
or, you can create a control-panel extension for the display driver,
that forces the user to disable composion ahead of enabling the display.
Surely it does not cover a random app callin ChangeDisplaySettingsEx,
but, it should give you something viable.

--

--
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


"Michael Wheeler" <MichaelWheeler@discussions.microsoft.com> wrote in
message news:ED17CC5D-C614-47D1-B43A-2453B31EB114@microsoft.com...