xp remote desktop bluescreen or how to shoot your pc

[techsc]

- i have posted this bug report more than one year ago already -

Windows XP Pro En SP3 Remote Desktop Blue Screen Procedure:

Here comes the procedure to reproduce a severe bug in the windows xp
terminal service (RDPDD.dll):

Set up a windows xp pro host and connect then from a remote computer via
remote desktop.

1)
connect and logon (create new session) at color depth 15bit

2)
disconnect (leave the user logged on)

3)
connect and logon to the created session at color depth 16bit

4)
disconnect

5)
connect and logon to the created sesseion at color despth 15bit

-> voila, the remote desktop host system reboots!

- I can reproduce this bug on all 4 availble computers (all xp pro with sp3)
at my location.

 

[Shenan Stanley]

- i have posted this bug report more than one year ago already -

Windows XP Pro En SP3 Remote Desktop Blue Screen Procedure:

Here comes the procedure to reproduce a severe bug in the windows xp
terminal service (RDPDD.dll):

Set up a windows xp pro host and connect then from a remote
computer via remote desktop.

1)
connect and logon (create new session) at color depth 15bit

2)
disconnect (leave the user logged on)

3)
connect and logon to the created session at color depth 16bit

4)
disconnect

5)
connect and logon to the created sesseion at color despth 15bit

-> voila, the remote desktop host system reboots!

- I can reproduce this bug on all 4 availble computers (all xp pro
with sp3) at my location.

ATI video cards?

 

[techsc]

The bug is not related to any video card. I can reproduce the bsod on ati,
nvidia and even on vmware virtual machine cards. Anyone can try it.

 

[Shenan Stanley]

- i have posted this bug report more than one year ago already -

Windows XP Pro En SP3 Remote Desktop Blue Screen Procedure:

Here comes the procedure to reproduce a severe bug in the windows xp
terminal service (RDPDD.dll):

Set up a windows xp pro host and connect then from a remote
computer via remote desktop.

1)
connect and logon (create new session) at color depth 15bit

2)
disconnect (leave the user logged on)

3)
connect and logon to the created session at color depth 16bit

4)
disconnect

5)
connect and logon to the created sesseion at color despth 15bit

-> voila, the remote desktop host system reboots!

- I can reproduce this bug on all 4 availble computers (all xp pro
with sp3) at my location.

ATI video cards?

The bug is not related to any video card. I can reproduce the bsod
on ati, nvidia and even on vmware virtual machine cards. Anyone can
try it.

It's Windows XP - it's pretty much a dead horse.
A year ago - it was actually pretty much a dead horse. ;-)

Not to mention - I am unsure why anyone would do what you specify - and I am
just meaning connecting at such a low color depth, much less this change
from low to slightly higher back to low.

 

[techsc]

Your comment does not help at all.

It is a bug in Windows XP and after one year there is still no reaction or
fix available.

 

[Geoff]

It's Windows XP - it's pretty much a dead horse.
A year ago - it was actually pretty much a dead horse. ;-)

Not to mention - I am unsure why anyone would do what you specify - and I am
just meaning connecting at such a low color depth, much less this change
from low to slightly higher back to low.

Not very constructive. The fact it is reproducible across a variety of
platforms is cause enough for concern. XP is far from dead, since MS
has yet to produce a newer system in sufficient population and appeal
to supplant all the installed XP boxes, it should still be on the
table for a fix. It's a bug that should have been detected and fixed
by now. The bug is reproducible on my Dell laptops and HP desktops.

If this scenario, or something like it, can be shown to kill a machine
during the connect process without needing a valid login it would make
for a fine denial of service attack. Since the code base for RDP is
probably close to if not identical to Terminal Services it could be
used to take down a TS box. It demonstrates a potential vulnerability
that could be exploited as a DoS or, with the proper frames, a way
into a kernel driver for elevation of privilege.

To techsc: this is not a proper place for a bug report in any case.
This should be submitted to the Microsoft support team as a proper bug
report, not in the newsgroups. You won't get much action from MS by
posting here, as you have demonstrated.

 

[Shenan Stanley]

- i have posted this bug report more than one year ago already -

Windows XP Pro En SP3 Remote Desktop Blue Screen Procedure:

Here comes the procedure to reproduce a severe bug in the windows xp
terminal service (RDPDD.dll):

Set up a windows xp pro host and connect then from a remote
computer via remote desktop.

1)
connect and logon (create new session) at color depth 15bit

2)
disconnect (leave the user logged on)

3)
connect and logon to the created session at color depth 16bit

4)
disconnect

5)
connect and logon to the created sesseion at color despth 15bit

-> voila, the remote desktop host system reboots!

- I can reproduce this bug on all 4 availble computers (all xp pro
with sp3) at my location.

ATI video cards?

The bug is not related to any video card. I can reproduce the bsod

It's Windows XP - it's pretty much a dead horse.
A year ago - it was actually pretty much a dead horse. ;-)

Not to mention - I am unsure why anyone would do what you specify -
and I am just meaning connecting at such a low color depth, much
less this change from low to slightly higher back to low.

Your comment does not help at all.

It is a bug in Windows XP and after one year there is still no
reaction or fix available.

To be clearer, I wouldn't expect a reaction or a fix if I were you.

It's great that you found a problem (albeit one I doubt many people would
ever run into, nor do I immediately see any exploitable concept in it) and
fantastic that you reported it. However - you reported it (supposedly) one
year ago. That would be July 2008. Windows Vista (the supposed replacement
for Windows XP) was released to businesses in November 2006 and to the
public in January 2007. Windows XP SP3 (which did make changes to the
Remote Desktop client - at least, if not to the entire sub-system) was
released in late April/early May 2008.

I see the first report of the problem you speak of (public - possibly you?)
here:
http://forums.nvidia.com/index.php?showtopic=84939

And I never said it was not an issue - I agree it is a curiosity and could
be, in unique cases, a valid issue for some users. It would be more of a
problem (for Microsoft to put attention to) and not just an issue if (1) it
did it on Windows Vista (does it?) and/or if it did it on Windows 7 (does
it?) and/or the server OSes and/or (2) it did it whether or not you logged
into the remote Windows XP desktop (you seem to actually have to log into
the remote desktop - meaning I couldn't write a script to hit some random
machine and crash it without having a valid logon/open session.) (2) would
make it a serious flaw - exploitable. (1) would make it a current issue.

I don't disagree - if you properly reported the issue via correct channels a
year ago (as you say) - then in a supported OS (Windows XP is a supported -
for now - OS) you should get some sort of statement - at the very least.
However - I wouldn't expect one as you have presented the issue. Not saying
you *shouldn't* expect one, I'm just doubting you will get one.

The only way *I* (as a peer) could help you with a flaw such as this is to
suggest you not change the color depth in such a pattern as you have found
to be disruptive and log into remote Windows XP machines in the given
specific fashion. It's a work-around, to be sure. Choose a specific color
depth and stick with it and/or log off the remote computer when done with a
forced 'different' color depth for 'speed' reasons - I suppose.

 

[techsc]

@Geoff:

You've pointed out the real nature of the issue.

I have my reasons, why sometimes people connect with different color depth -
for performance reasons or simply by accident. However, this is not the point.

It is a real bad bug.

Please: How can I report that bug to Microsoft correctly?

Thank you
Chris

 

[Shenan Stanley]

Not very constructive. The fact it is reproducible across a variety
of platforms is cause enough for concern. XP is far from dead,
since MS has yet to produce a newer system in sufficient population
and appeal to supplant all the installed XP boxes, it should still
be on the table for a fix. It's a bug that should have been
detected and fixed by now. The bug is reproducible on my Dell
laptops and HP desktops.

If this scenario, or something like it, can be shown to kill a
machine during the connect process without needing a valid login it
would make for a fine denial of service attack. Since the code base
for RDP is probably close to if not identical to Terminal Services
it could be used to take down a TS box. It demonstrates a potential
vulnerability that could be exploited as a DoS or, with the proper
frames, a way into a kernel driver for elevation of privilege.

To techsc: this is not a proper place for a bug report in any case.
This should be submitted to the Microsoft support team as a proper
bug report, not in the newsgroups. You won't get much action from
MS by posting here, as you have demonstrated.

The response was not meant to be constructive - since I have no way to fix a
flaw in the programming of the OS - all I could have done is said "don't do
that". If you read my later response - you will see that I just don't
*expect* there to be a response from Microsoft. Maybe I will be proven
wrong - maybe there will be.

You'll also see in my other response that it does not seem to crash a system
unless you have a legitimate session already and are reconnecting completely
to that session - and then you have to disconnected and reconnect - changing
the color depth twice (the issue does not seem as limited as the OP is
making it sound - the last change could have been to a completely different
color depth than the original one.) If the OP is this person:

http://forums.nvidia.com/index.php?showtopic=84939

Then a year ago might be a bit of an exaggeration for a public report - but
what they did properly/privately is an unknown variable. ;-)

The OP (techsc) said they "posted this bug report more than one year ago
already", and yeah - perhaps I assumed (by the specific language) too
much - in that they had officially reported the problem through proper
channels. My bad. Maybe they have not and I could have suggested they do
it properly... So let's ask and be sure:

techsc,

Did you file a proper (with Microsoft - not just posted on a newsgroup
randomly) report with Microsoft documenting the issue?

 

[techsc]

Shenan:

You're still talking about how unusual - in you personal point of view - the
reported blue screen will come up.

Accept it like it is: A real bad bug in the OS. And yes, in my
infrastructure this bug leads frequently to total computer resets.

However, I halready asked in the thread:

Please: How can I report that bug to Microsoft correctly?

 

[techsc]

Shenan:

And please stick to the thread. I have posted a very simple and 100%
reproducable bsod bug. I am not the originator of any nvidia thread.

Your statement, it would be required to change the color depth several times
is wrong. However, this is also not the point.

 

[Shenan Stanley]

Shenan:

And please stick to the thread. I have posted a very simple and 100%
reproducable bsod bug. I am not the originator of any nvidia thread.

Your statement, it would be required to change the color depth
several times is wrong. However, this is also not the point.

I did stick to the thread.

I can do nothing for you. No one here really can.

Sure, the problem is reproducable - and some people (in some ways) could
cause this if they do not log off a remote machine and then reconnect to it
twice more - the second time using a different bit-rate than the first and
then disconnecting (without logging off) and connecting back the third time
at any bit-rate other than the second connection - including but not limited
to the originally connected bit-rate.

Report it to Microsoft.

Stop using Remote Desktop and switch to something else would be my actual
suggestion - TeamViewer is great, but if for commercial applications, VNC
and Single-Click gives you almost the same functionality for free, and both
without as much setup on the customer end.

I use all sorts of remote tools to connect across many different types of
internet connections all the time. I know of many help-desk setups that do
it as well and they do not encounter this issue - mostly (I think) because
they just have not seen the need to change the bit-rate and combine that
with multiple logons with the same user without logging out of the remote
machine.

 

[techsc]

Shenan,

if you have no helpful input please do not reply to such threads.

 

[Shenan Stanley]

- i have posted this bug report more than one year ago already -

Windows XP Pro En SP3 Remote Desktop Blue Screen Procedure:

Here comes the procedure to reproduce a severe bug in the windows xp
terminal service (RDPDD.dll):

Set up a windows xp pro host and connect then from a remote
computer via remote desktop.

1) connect and logon (create new session) at color depth 15bit

2) disconnect (leave the user logged on)

3) connect and logon to the created session at color depth 16bit

4) disconnect

5) connect and logon to the created sesseion at color despth 15bit

-> voila, the remote desktop host system reboots!

- I can reproduce this bug on all 4 availble computers (all xp pro
with sp3) at my location.

ATI video cards?

The bug is not related to any video card. I can reproduce the bsod

It's Windows XP - it's pretty much a dead horse.
A year ago - it was actually pretty much a dead horse. ;-)

Not to mention - I am unsure why anyone would do what you specify -
and I am just meaning connecting at such a low color depth, much
less this change from low to slightly higher back to low.

Not very constructive. The fact it is reproducible across a variety
of platforms is cause enough for concern. XP is far from dead,
since MS has yet to produce a newer system in sufficient population
and appeal to supplant all the installed XP boxes, it should still
be on the table for a fix. It's a bug that should have been
detected and fixed by now. The bug is reproducible on my Dell
laptops and HP desktops.

If this scenario, or something like it, can be shown to kill a
machine during the connect process without needing a valid login it
would make for a fine denial of service attack. Since the code base
for RDP is probably close to if not identical to Terminal Services
it could be used to take down a TS box. It demonstrates a potential
vulnerability that could be exploited as a DoS or, with the proper
frames, a way into a kernel driver for elevation of privilege.

To techsc: this is not a proper place for a bug report in any case.
This should be submitted to the Microsoft support team as a proper
bug report, not in the newsgroups. You won't get much action from
MS by posting here, as you have demonstrated.

Shenan:

You're still talking about how unusual - in you personal point of
view - the reported blue screen will come up.

Accept it like it is: A real bad bug in the OS. And yes, in my
infrastructure this bug leads frequently to total computer resets.

However, I halready asked in the thread:

Please: How can I report that bug to Microsoft correctly?

Your comment does not help at all.

It is a bug in Windows XP and after one year there is still no
reaction or fix available.

To be clearer, I wouldn't expect a reaction or a fix if I were you.

It's great that you found a problem (albeit one I doubt many people
would ever run into, nor do I immediately see any exploitable
concept in it) and fantastic that you reported it. However - you
reported it (supposedly) one year ago. That would be July 2008.
Windows Vista (the supposed replacement for Windows XP) was
released to businesses in November 2006 and to the public in
January 2007. Windows XP SP3 (which did make changes to the Remote
Desktop client - at least, if not to the entire sub-system) was
released in late April/early May 2008.

I see the first report of the problem you speak of (public -
possibly you?) here:
http://forums.nvidia.com/index.php?showtopic=84939

And I never said it was not an issue - I agree it is a curiosity
and could be, in unique cases, a valid issue for some users. It
would be more of a problem (for Microsoft to put attention to) and
not just an issue if (1) it did it on Windows Vista (does it?)
and/or if it did it on Windows 7 (does it?) and/or the server OSes
and/or (2) it did it whether or not you logged into the remote
Windows XP desktop (you seem to actually have to log into the
remote desktop - meaning I couldn't write a script to hit some
random machine and crash it without having a valid logon/open
session.) (2) would make it a serious flaw - exploitable. (1)
would make it a current issue.

I don't disagree - if you properly reported the issue via correct
channels a year ago (as you say) - then in a supported OS (Windows
XP is a supported - for now - OS) you should get some sort of
statement - at the very least. However - I wouldn't expect one as
you have presented the issue. Not saying you *shouldn't* expect
one, I'm just doubting you will get one.

The only way *I* (as a peer) could help you with a flaw such as
this is to suggest you not change the color depth in such a pattern
as you have found to be disruptive and log into remote Windows XP
machines in the given specific fashion. It's a work-around, to be
sure. Choose a specific color depth and stick with it and/or log
off the remote computer when done with a forced 'different' color
depth for 'speed' reasons - I suppose.

Shenan:

And please stick to the thread. I have posted a very simple and 100%
reproducable bsod bug. I am not the originator of any nvidia thread.

Your statement, it would be required to change the color depth
several times is wrong. However, this is also not the point.

I did stick to the thread.

I can do nothing for you. No one here really can.

Sure, the problem is reproducable - and some people (in some ways)
could cause this if they do not log off a remote machine and then
reconnect to it twice more - the second time using a different
bit-rate than the first and then disconnecting (without logging
off) and connecting back the third time at any bit-rate other than
the second connection - including but not limited to the originally
connected bit-rate.

Report it to Microsoft.

Stop using Remote Desktop and switch to something else would be my
actual suggestion - TeamViewer is great, but if for commercial
applications, VNC and Single-Click gives you almost the same
functionality for free, and both without as much setup on the
customer end.

I use all sorts of remote tools to connect across many different
types of internet connections all the time. I know of many
help-desk setups that do it as well and they do not encounter this
issue - mostly (I think) because they just have not seen the need
to change the bit-rate and combine that with multiple logons with
the same user without logging out of the remote machine.

Shenan,

if you have no helpful input please do not reply to such threads.

Letting you know that no one here can do anything about a bug in the OS (we
are volunteers, not Microsoft employees/programmers) and letting you know
you would be better served reporting the problem to tthose who can actually
do something (Microsoft) and giving you the only work-arounds possible at
this time (using third party applications such as TeamViewer and/or VNC) *I*
would say is helpful, in this case.

We disagree about the commonality of your reported problem. That's all. It
exists, no argument there - it's just going to be rare that someone comes
across it - IMO. Maybe you have a case where it is not rare to change
bit-rates (disconnect/reconnect twice) without logging off the remote
computer. I'm not saying the issue doesn't exist, in fact I cannot say this
any better than I did a while back in this conversation, "To be clearer, I
wouldn't expect a reaction or a fix if I were you."

I'm just being truthful with you.

I think you should report it, but I think you should be realistic about it
and not expect much of a response out of something that will be likely
considered a rare occurence caused by a very unique set of events a user
must perform. It's just honesty with the possible work-arounds thrown in.

Also - I suggest giving examples when you report the issue - examples of
when this could be common practice and perhaps visual examples of this
happening. Along the latter lines (because - again - I cannot personally
see where the simple work-around of always connecting at the same bit-rate
and/or logging off when done isn't a possible and easy work-around - or
actually not the norm) maybe I can help...

I've made a few videos - some demonstrating the issue at hand, some
demonstrating when the issue is *not* an issue. I carried out further tests
and documented them here to assist you in your report to Microsoft, if you
are going to make one.

I cannot fathom contributing more than that to help you present your case -
but - here's what I got...

I tested this combination -- Windows Vista SP2 remotely connecting to
Windows XP SP3 (NLA enabled):

15 --> 16 --> 15 = Reboot of Remote Client (with video.)

Since this caused a reboot and is the one you are concerned with, I decided
to log off the remote machine between each change...

15 --> logoff --> 16 --> logoff --> 15 --> logoff = No Problem (with
video.)

But there are so many more combinations to try - here are some I did try and
the results.
(I logged off the remote computer at the end of each '3 change test' - not
each change - just at the end of each combination of three.)

15 --> 24 --> 15 = Reboot of Remote Client (with video.)

15 --> 32 --> 15 = Reboot of Remote Client (with video.)

15 --> 256 --> 15 = No Problem (with video.)

16 --> 15 --> 16 = No Problem (no video.)
24 --> 15 --> 24 = No Problem (no video.)
24 --> 16 --> 24 = No Problem (no video.)
16 --> 24 --> 16 = No Problem (no video.)
32 --> 15 --> 32 = No Problem (no video.)
32 --> 16 --> 32 = No Problem (no video.)
16 --> 32 --> 16 = No Problem (no video.)
32 --> 24 --> 32 = No Problem (no video.)
24 --> 32 --> 24 = No Problem (no video.)
256 --> 15 --> 256 = No Problem (no video.)
256 --> 16 --> 256 = No Problem (no video.)
16 --> 256 --> 16 = No Problem (no video.)
32 --> 256 --> 32 = No Problem (no video.)
256 --> 32 --> 256 = No Problem (no video.)
256 --> 24 --> 256 = No Problem (no video.)
24 --> 256 --> 24 = No Problem (no video.)

Although not all the possible combinations, I think you can understand me
not doing all the work *you* might need to do to make *your* case to
Microsoft that this needs to be fixed.

I did prove myself incorrect - only the three bit-rate changes (15 -->
16 --> 15, 15 --> 24 --> 15 and 15 --> 32 --> 15) without remote logoff -
seems to give the reaction of rebooting the remote Windows XP SPx machine in
a repeatable fashion.

Unfortunately (for your case) - that only makes the work-arounds that much
easier to suggest. ;-)

- Don't switch between bit-rates when connecting to a machine with an active
session
- Use something with more benefit than remote desktop gives.
- Log off the remote machine between sessions when possible.
- Don't use 15-bit at all.

I actually did get the remote client to reboot once by just continuously
changing bit-rates. It took about 22-23 changes though - none of which were
15-bit. So I guess with enough changes in bit-rate without logging off the
remote client, it could cause a reboot at random.

I wanted to see if it still did this if the reverse was done - so connecting
to Vista from Windows XP. I tried a few of the ones that definitely caused
issues in Windows XP - and a few others. None of them seemed to produce the
problem reflected in the test above remoting into Windows XP. So it seems
the issue was resolved in future versions of Windows (beyond Windows XP.)

I do wonder if Windows 2003 shows the same issues... But I will leave that
to you.

Do some searches, do some research, put in some effort into a report with
many details and let us know what happens.

Hope that helps.

 

[Tom]

Hello

May I suggest you to test a more recent build of Rdpdd.dll (23-Jan-2009).
In my eyes, this problem could be related to this issue:

http://support.microsoft.com/kb/963038/en-us

Kind Regards
Tom

 

[Shenan Stanley]

- i have posted this bug report more than one year ago already -

Windows XP Pro En SP3 Remote Desktop Blue Screen Procedure:

Here comes the procedure to reproduce a severe bug in the windows xp
terminal service (RDPDD.dll):

Set up a windows xp pro host and connect then from a remote
computer via remote desktop.

1) connect and logon (create new session) at color depth 15bit

2) disconnect (leave the user logged on)

3) connect and logon to the created session at color depth 16bit

4) disconnect

5) connect and logon to the created sesseion at color despth 15bit

-> voila, the remote desktop host system reboots!

- I can reproduce this bug on all 4 availble computers (all xp pro
with sp3) at my location.

ATI video cards?

The bug is not related to any video card. I can reproduce the bsod

It's Windows XP - it's pretty much a dead horse.
A year ago - it was actually pretty much a dead horse. ;-)

Not to mention - I am unsure why anyone would do what you specify -
and I am just meaning connecting at such a low color depth, much
less this change from low to slightly higher back to low.

Not very constructive. The fact it is reproducible across a variety
of platforms is cause enough for concern. XP is far from dead,
since MS has yet to produce a newer system in sufficient population
and appeal to supplant all the installed XP boxes, it should still
be on the table for a fix. It's a bug that should have been
detected and fixed by now. The bug is reproducible on my Dell
laptops and HP desktops.

If this scenario, or something like it, can be shown to kill a
machine during the connect process without needing a valid login it
would make for a fine denial of service attack. Since the code base
for RDP is probably close to if not identical to Terminal Services
it could be used to take down a TS box. It demonstrates a potential
vulnerability that could be exploited as a DoS or, with the proper
frames, a way into a kernel driver for elevation of privilege.

To techsc: this is not a proper place for a bug report in any case.
This should be submitted to the Microsoft support team as a proper
bug report, not in the newsgroups. You won't get much action from
MS by posting here, as you have demonstrated.

Shenan:

You're still talking about how unusual - in you personal point of
view - the reported blue screen will come up.

Accept it like it is: A real bad bug in the OS. And yes, in my
infrastructure this bug leads frequently to total computer resets.

However, I halready asked in the thread:

Please: How can I report that bug to Microsoft correctly?

Your comment does not help at all.

It is a bug in Windows XP and after one year there is still no
reaction or fix available.

To be clearer, I wouldn't expect a reaction or a fix if I were you.

It's great that you found a problem (albeit one I doubt many people
would ever run into, nor do I immediately see any exploitable
concept in it) and fantastic that you reported it. However - you
reported it (supposedly) one year ago. That would be July 2008.
Windows Vista (the supposed replacement for Windows XP) was
released to businesses in November 2006 and to the public in
January 2007. Windows XP SP3 (which did make changes to the Remote
Desktop client - at least, if not to the entire sub-system) was
released in late April/early May 2008.

I see the first report of the problem you speak of (public -
possibly you?) here:
http://forums.nvidia.com/index.php?showtopic=84939

And I never said it was not an issue - I agree it is a curiosity
and could be, in unique cases, a valid issue for some users. It
would be more of a problem (for Microsoft to put attention to) and
not just an issue if (1) it did it on Windows Vista (does it?)
and/or if it did it on Windows 7 (does it?) and/or the server OSes
and/or (2) it did it whether or not you logged into the remote
Windows XP desktop (you seem to actually have to log into the
remote desktop - meaning I couldn't write a script to hit some
random machine and crash it without having a valid logon/open
session.) (2) would make it a serious flaw - exploitable. (1)
would make it a current issue.

I don't disagree - if you properly reported the issue via correct
channels a year ago (as you say) - then in a supported OS (Windows
XP is a supported - for now - OS) you should get some sort of
statement - at the very least. However - I wouldn't expect one as
you have presented the issue. Not saying you *shouldn't* expect
one, I'm just doubting you will get one.

The only way *I* (as a peer) could help you with a flaw such as
this is to suggest you not change the color depth in such a pattern
as you have found to be disruptive and log into remote Windows XP
machines in the given specific fashion. It's a work-around, to be
sure. Choose a specific color depth and stick with it and/or log
off the remote computer when done with a forced 'different' color
depth for 'speed' reasons - I suppose.

Shenan:

And please stick to the thread. I have posted a very simple and 100%
reproducable bsod bug. I am not the originator of any nvidia thread.

Your statement, it would be required to change the color depth
several times is wrong. However, this is also not the point.

I did stick to the thread.

I can do nothing for you. No one here really can.

Sure, the problem is reproducable - and some people (in some ways)
could cause this if they do not log off a remote machine and then
reconnect to it twice more - the second time using a different
bit-rate than the first and then disconnecting (without logging
off) and connecting back the third time at any bit-rate other than
the second connection - including but not limited to the originally
connected bit-rate.

Report it to Microsoft.

Stop using Remote Desktop and switch to something else would be my
actual suggestion - TeamViewer is great, but if for commercial
applications, VNC and Single-Click gives you almost the same
functionality for free, and both without as much setup on the
customer end.

I use all sorts of remote tools to connect across many different
types of internet connections all the time. I know of many
help-desk setups that do it as well and they do not encounter this
issue - mostly (I think) because they just have not seen the need
to change the bit-rate and combine that with multiple logons with
the same user without logging out of the remote machine.

Shenan,

if you have no helpful input please do not reply to such threads.

Letting you know that no one here can do anything about a bug in
the OS (we are volunteers, not Microsoft employees/programmers) and
letting you know you would be better served reporting the problem
to tthose who can actually do something (Microsoft) and giving you
the only work-arounds possible at this time (using third party
applications such as TeamViewer and/or VNC) *I* would say is
helpful, in this case.

We disagree about the commonality of your reported problem. That's
all. It exists, no argument there - it's just going to be rare
that someone comes across it - IMO. Maybe you have a case where it
is not rare to change bit-rates (disconnect/reconnect twice)
without logging off the remote computer. I'm not saying the issue
doesn't exist, in fact I cannot say this any better than I did a
while back in this conversation, "To be clearer, I wouldn't expect
a reaction or a fix if I were you."

I'm just being truthful with you.

I think you should report it, but I think you should be realistic
about it and not expect much of a response out of something that
will be likely considered a rare occurence caused by a very unique
set of events a user must perform. It's just honesty with the
possible work-arounds thrown in.

Also - I suggest giving examples when you report the issue -
examples of when this could be common practice and perhaps visual
examples of this happening. Along the latter lines (because -
again - I cannot personally see where the simple work-around of
always connecting at the same bit-rate and/or logging off when done
isn't a possible and easy work-around - or actually not the norm)
maybe I can help...

I've made a few videos - some demonstrating the issue at hand, some
demonstrating when the issue is *not* an issue. I carried out
further tests and documented them here to assist you in your report
to Microsoft, if you are going to make one.

I cannot fathom contributing more than that to help you present
your case - but - here's what I got...

I tested this combination -- Windows Vista SP2 remotely connecting
to Windows XP SP3 (NLA enabled):

15 --> 16 --> 15 = Reboot of Remote Client (with video.)

Since this caused a reboot and is the one you are concerned with, I
decided to log off the remote machine between each change...

15 --> logoff --> 16 --> logoff --> 15 --> logoff = No Problem
(with video.)

But there are so many more combinations to try - here are some I
did try and the results.
(I logged off the remote computer at the end of each '3 change
test' - not each change - just at the end of each combination of
three.)

15 --> 24 --> 15 = Reboot of Remote Client (with video.)

15 --> 32 --> 15 = Reboot of Remote Client (with video.)

15 --> 256 --> 15 = No Problem (with video.)

16 --> 15 --> 16 = No Problem (no video.)
24 --> 15 --> 24 = No Problem (no video.)
24 --> 16 --> 24 = No Problem (no video.)
16 --> 24 --> 16 = No Problem (no video.)
32 --> 15 --> 32 = No Problem (no video.)
32 --> 16 --> 32 = No Problem (no video.)
16 --> 32 --> 16 = No Problem (no video.)
32 --> 24 --> 32 = No Problem (no video.)
24 --> 32 --> 24 = No Problem (no video.)
256 --> 15 --> 256 = No Problem (no video.)
256 --> 16 --> 256 = No Problem (no video.)
16 --> 256 --> 16 = No Problem (no video.)
32 --> 256 --> 32 = No Problem (no video.)
256 --> 32 --> 256 = No Problem (no video.)
256 --> 24 --> 256 = No Problem (no video.)
24 --> 256 --> 24 = No Problem (no video.)

Although not all the possible combinations, I think you can
understand me not doing all the work *you* might need to do to make
*your* case to Microsoft that this needs to be fixed.

I did prove myself incorrect - only the three bit-rate changes (15
--> 16 --> 15, 15 --> 24 --> 15 and 15 --> 32 --> 15) without
remote logoff - seems to give the reaction of rebooting the remote
Windows XP SPx machine in a repeatable fashion.

Unfortunately (for your case) - that only makes the work-arounds
that much easier to suggest. ;-)

- Don't switch between bit-rates when connecting to a machine with
an active session
- Use something with more benefit than remote desktop gives.
- Log off the remote machine between sessions when possible.
- Don't use 15-bit at all.

I actually did get the remote client to reboot once by just
continuously changing bit-rates. It took about 22-23 changes
though - none of which were 15-bit. So I guess with enough changes
in bit-rate without logging off the remote client, it could cause a
reboot at random.

I wanted to see if it still did this if the reverse was done - so
connecting to Vista from Windows XP. I tried a few of the ones
that definitely caused issues in Windows XP - and a few others.
None of them seemed to produce the problem reflected in the test
above remoting into Windows XP. So it seems the issue was resolved
in future versions of Windows (beyond Windows XP.)

I do wonder if Windows 2003 shows the same issues... But I will
leave that to you.

Do some searches, do some research, put in some effort into a
report with many details and let us know what happens.

Hope that helps.

May I suggest you to test a more recent build of Rdpdd.dll
(23-Jan-2009). In my eyes, this problem could be related to this
issue:

http://support.microsoft.com/kb/963038/en-us

I agree with the suggestion, although the issue does not give the error(s)
mentioned in the KB article.

Taking the screenshot out of the recorded examples I gave, you can see the
bluescreen states:

PAGE_FAULT_IN_NONPAGED_AREA
STOP: 0x00000050 (0xBC62FFF0, 0x00000000, 0xBF85B6B7,0x00000000)
win32k.sys - Address BF85B6B7 base at BF800000

The KB Article (http://support.microsoft.com/kb/963038/) refers to this
error:
STOP: 0x1000008E (Parameter1, Parameter2, Parameter3, Parameter4) in
RDPDD.dll
KERNEL_MODE_EXCEPTION_NOT_HANDLED_M

Screenshot of BlueScreen on Remote Machine:
http://picasaweb.google.com/lh/photo/YJ-Oxnn7HJOFcc-4_5AOkA?feat=directlink

But - what the heck? It's the best possibility yet and all the work is done
except for this last part. So I tried it and recorded the results.

Resultant Video (showing the application of the fix, reboot and test
results...):
http://www.youtube.com/watch?v=cWEkACbLYIE

The fix seemed to work perfectly. Good find, Tom.

If you have Windows XP SP3 and your RDPDD.DLL file version is 5.1.2600.5749
or later - you should not have the issue that the OP is reporting.

The videos, pictures and KB article should get you everything you need -
since you can get the fix by reading the KB article, etc. Apply that hotfix
to all affected machines.

If you just want the hotfix...
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=963038

Do the obvious (in case it is not obvious, select the proper language, put
in a valid email address twice, type the characters you see. When you get
the email, follow the directions.)

Hopefully that will fix the problem for the OP and is well documented and
commented about enough to allow those who put effort into it and search will
find the answer they seek. I would ask that the OP comes back and lets us
know if this resolves the issue for them - but it should - given the video
evidence. ;-) Would be nice closure, however.

 

[Nathan]

I think this is the Hotfix you are looking for:
http://support.microsoft.com/kb/963038

As a side note, I work in an large domian with several thousand users and do
Tier 2 and 3level support. I regulary remote into my PC from many different
machines to run utilites and make changes in AD (ie add and remove packaged
software, group membership etc). Most machines are of different
configuration with differet resolutions and color depth settings. I can see
this being a problem in this enviorment.

- i have posted this bug report more than one year ago already -

Windows XP Pro En SP3 Remote Desktop Blue Screen Procedure:

Here comes the procedure to reproduce a severe bug in the windows xp
terminal service (RDPDD.dll):

Set up a windows xp pro host and connect then from a remote
computer via remote desktop.

1) connect and logon (create new session) at color depth 15bit

2) disconnect (leave the user logged on)

3) connect and logon to the created session at color depth 16bit

4) disconnect

5) connect and logon to the created sesseion at color despth 15bit

-> voila, the remote desktop host system reboots!

- I can reproduce this bug on all 4 availble computers (all xp pro
with sp3) at my location.

 

[Shenan Stanley]

<snip>

I think this is the Hotfix you are looking for:
http://support.microsoft.com/kb/963038

As a side note, I work in an large domian with several thousand
users and do Tier 2 and 3level support. I regulary remote into my
PC from many different machines to run utilites and make changes in
AD (ie add and remove packaged software, group membership etc).
Most machines are of different configuration with differet
resolutions and color depth settings. I can see this being a
problem in this enviorment.

But why? You don't have to remote into a single machine with 15-bit, then
16-bit then 15-bit for any reason I can see - without logging off the remote
session somewhere in there especially.

I regularly remote into a lot of machines - machines whose configurations
vary greatly - and have not seen the need to connect to a single remote
machine with 15-bit color, disconnect without logging off, come back later
and connect with 16-bit color, disconnect again without logging off and
finally - come back later and log in with 15-bit color...

In any case - 10 days ago, I responded to this thread with this:

I agree with the suggestion, although the issue does not give the
error(s) mentioned in the KB article.

Taking the screenshot out of the recorded examples I gave, you can
see the bluescreen states:

PAGE_FAULT_IN_NONPAGED_AREA
STOP: 0x00000050 (0xBC62FFF0, 0x00000000, 0xBF85B6B7,0x00000000)
win32k.sys - Address BF85B6B7 base at BF800000

The KB Article (http://support.microsoft.com/kb/963038/) refers to
this error:
STOP: 0x1000008E (Parameter1, Parameter2, Parameter3, Parameter4) in
RDPDD.dll
KERNEL_MODE_EXCEPTION_NOT_HANDLED_M

Screenshot of BlueScreen on Remote Machine:
http://picasaweb.google.com/lh/photo/YJ-Oxnn7HJOFcc-4_5AOkA?feat=directlink

But - what the heck? It's the best possibility yet and all the
work is done except for this last part. So I tried it and recorded
the results.

Resultant Video (showing the application of the fix, reboot and test
results...):

The fix seemed to work perfectly. Good find, Tom.

If you have Windows XP SP3 and your RDPDD.DLL file version is
5.1.2600.5749 or later - you should not have the issue that the OP
is reporting.

The videos, pictures and KB article should get you everything you
need - since you can get the fix by reading the KB article, etc.
Apply that hotfix to all affected machines.

If you just want the hotfix...
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=963038

Do the obvious (in case it is not obvious, select the proper
language, put in a valid email address twice, type the characters
you see. When you get the email, follow the directions.)

Hopefully that will fix the problem for the OP and is well
documented and commented about enough to allow those who put effort
into it and search will find the answer they seek. I would ask
that the OP comes back and lets us know if this resolves the issue
for them - but it should - given the video evidence. ;-) Would be
nice closure, however.

Proving that the newer version of files this fix puts out there does remedy
the situation.

 

[Jared Davison]

HOTFIX SOLUTION:

http://support.microsoft.com/kb/963038/en-us

This is a patch to RDPDD.DLL.

Thanks for posting this article as it helped me solve the problem. I had
this problem you describe above, and changing the bit depth of rdp client
connections causing Blue Screens on the xp remote desktop server side. I
called Microsoft Support and after spending quite a lot of time with them,
they believed me and investigated and found a hotfix on their site that i was
unable to find myself. This process took about 3-4 weeks to get the solution
from when i first contacted them.

I have tried the hotfix on my systems and it appears to work and haven't had
any further blue screens so far when changing bit depth.

I have since tried to find the link above in google using keywords but it
didn't come up for me so that could explain why we have struggled to find the
solution.

Hope this helps you too.

Kind regards

Jared Davison

 

[tyamadajp]

Regarding commonnality, this issue is a showstopper for anyone planning to
do a desktop virtualization.

I'm currently running XP on VMware platform and this issue is driving me
crazy. I connect to this virtualized XP from various locations, and once I
forget to configure color depth of RDP connection, it's a death sentence for
my desktop - next time I run a "correctly" configured RDP session, it result
in BSoD.

So while I do agree Microsoft probably won't fix this as XP is now nearly
unsupported, I expect this issue to rise again if desktop virtualization
became mainstream while XP is still alive.