Re: Session 0 bug in TranslateBitmapBits on Vista/Windows Server 2

Thanks for the information Ivan. Some follow-up questions:

1) We can patch the issue by doing an os.dwMajorVersion == 6 check but that
won't cover us for WS08 R2 where you've reported the issue is fixed. Check
build numbers? Recommendations? Are there any plans for a hotfix for
Vista/WS08?

2) Are there any performance considerations around session 0's use of the
tsddd.dll? Especially is there any speed degradation in bitmap manipulation
functions (using a memory DC)?

"Ivan Brugiolo [MSFT]" wrote:

In Vista/WS08 the services session is bound to the disconnected
display driver, or tsddd.dll.
This driver, as you have noticed, has color channel inverted for 32bpp.

This was changed/corrected in Win7/WS08-R2 to avoid rendering artifacts
while connecting / disconnecting sessions.

That driver, does not have any interesting capabilities (each DDI returns
success
without performing anything).
However, this does not prevent you from using GDI or GDI+ operations in
session-0
(or in any other session bound to tsddd.dll, such as disconnected FUS/TS
session)
as long as you use a memory DC with selected a DIB-section bitmap.

--

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

"CK" <ck@xxxxxxxxxxxxx> wrote in message
news:29DE169B-EAFC-4D8D-BFD6-AC439AC72D79@xxxxxxxxxxxxxxxx
Thanks Paul. I was aware of these limitations but they don't seem to apply
in
my case. There's no UI or interaction requirement for this service. It
manipulates bitmaps and I don't think GDI funtions are limited to
interactive
sessions (at least they ones we use don't fail in session 0). The process
does create a device context (HDC). The ICM functions it uses are:

OpenColorProfile
IsColorProfileValid
CreateColorTransform
CloseColorProfile
TranslateBitmapBits

All code returns from the Win API are checked and they all succeed. The
oddity is that in session 0, TranslateBitmapBits expects the bitmap as
BGRA
instead of RGBA. For no obvious reason.

CK

"Paul Baker [MVP, Windows Desktop Experie" wrote:

I have found that in a non-interactive session on Windows XP, I can use
user32 and gdi32 functions and expect them to work as usual. However, no
user can ever see or interact with the session.

Are you aware that Session 0 on Windows Vista or Windows Server 2008 is
subject to Session 0 Isolation?
http://msdn.microsoft.com/en-us/library/bb756986.aspx

I would imagine that GDI functions require a desktop to be associated
with
the current thread to work properly. And creating a desktop requires a
window station to be associated with the current process. This article
would
suggest that window stations *can* be used in Session 0, and therefore
probably, desktops. But *are* they, by default?

Launching an interactive process from Windows Service in Windows Vista
and
later:
http://blogs.msdn.com/winsdk/archive/2009/07/14/launching-an-interactive-process-from-windows-service-in-windows-vista-and-later.aspx

You could see what GetThreadDesktop and GetProcessWindowStation return.
If
you don't have both a desktop and window station, this could be the
underlying cause. And if this is the case, you might be able to create
one,
but I don't recommend it. Rather, I'd avoid doing any UI stuff in a
service.
Even if the user cannot see or interact with the session, you don't want
to
be loading video drivers, GDI, etc. if you don't need to.

Also, make sure you are checking the result and error codes of any
functions
that you are calling. It may indicate in more detail what is going on.
For
example, ERROR_ACCESS_DENIED would probably indicate a Session 0
Isolation
or related security feature whereas ERROR_INVALID_PARAMETER would
probably
indicate that you made a mistake. Sometimes the only reason a newer OS
reports an error when an older one did not is that it got stricter in
validating input, and that's not the OS's problem. You don'yt explain
what
you mean by "incorrect" results. It might help to dig into that a bit
deeper.

Paul

"CK" <ck@xxxxxxxxxxxxx> wrote in message
news:6F176514-566E-44A5-8483-02160CE21AC6@xxxxxxxxxxxxxxxx
Our application has both desktop and services components. In a shared
piece
of code we're using TranslateBitmapBits() to do translate bitmap colors
in
order to do CMYK proofing on screen. The destination profile is an sRGB
profile and the target profile is a U.S. SWOP Proofer profile.

Under Vista/Windows Server 2008 x64, when our code runs from the
desktop
application is produces correct results. When it runs from the service
application, it produces incorrect results. The code works fine under
Windows
Server 2003 and XP.

The code is calling TranslateBitmapBits using BM_xRGBQUADS for the
BMFORMAT.
While experimenting with the settings, we discovered that if we called
TranslateBitmapBits using BM_xBGRQUADS for the BMFORMAT, then the
service
application produced the desired results. Of course this broke the
desktop
application. Also, BM_xBGRQUADS does not work under Windows Server 2003
and
XP where it's expecting BM_xRGBQUADS.

The net result is if we add a check in our code that a) we're running
as a
service and b) we're running under Windows Vista/2008, and use
BM_xBGRQUADS
instead of BM_xRGBQUADS, we have a workaround.

But this seems like a bug in the latest OSs.






.

Relevant Pages
Loading