Re: xp remote desktop bluescreen or how to shoot your pc

techsc wrote:
- 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 wrote:
ATI video cards?

techsc wrote:
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 wrote:
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.

Geoff wrote:
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.

techsc wrote:
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 wrote:
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.

Shenan Stanley wrote:
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 wrote:
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 wrote:
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 wrote:
Shenan,

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

Shenan Stanley wrote:
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.)
http://www.youtube.com/watch?v=q_Pt_V8Z_O8

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.)
http://www.youtube.com/watch?v=FELnZQ0qiQA

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.)
http://www.youtube.com/watch?v=c-46Sz42-_Y

15 --> 32 --> 15 = Reboot of Remote Client (with video.)
http://www.youtube.com/watch?v=Ba6IHU3oiyo

15 --> 256 --> 15 = No Problem (with video.)
http://www.youtube.com/watch?v=i4jJBvwkkEg

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 wrote:
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.

--
Shenan Stanley
MS-MVP
--
How To Ask Questions The Smart Way
http://www.catb.org/~esr/faqs/smart-questions.html


.

Relevant Pages

  • Re: xp remote desktop bluescreen or how to shoot your pc
    ... Windows XP Pro En SP3 Remote Desktop Blue Screen Procedure: ... Here comes the procedure to reproduce a severe bug in the windows xp ... this is not a proper place for a bug report in any case. ...
    (microsoft.public.windowsxp.work_remotely)
  • Re: xp remote desktop bluescreen or how to shoot your pc
    ... Windows XP Pro En SP3 Remote Desktop Blue Screen Procedure: ... Here comes the procedure to reproduce a severe bug in the windows xp ... this is not a proper place for a bug report in any case. ...
    (microsoft.public.windowsxp.work_remotely)
  • SecurityFocus Microsoft Newsletter #228
    ... RaidenHTTPD Remote File Disclosure Vulnerability ... Microsoft Outlook Web Access Login Form Remote URI Redirecti... ... Microsoft Windows Hyperlink Object Library Buffer Overflow V... ...
    (Focus-Microsoft)
  • SecurityFocus Microsoft Newsletter #212
    ... MICROSOFT VULNERABILITY SUMMARY ... ARJ Software UNARJ Remote Directory Traversal Vulnerability ... Microsoft Windows XP WAV File Handler Denial Of Service Vuln... ...
    (Focus-Microsoft)
  • SecurityFocus Microsoft Newsletter #229
    ... Windows NTFS Alternate Data Streams ... MICROSOFT VULNERABILITY SUMMARY ... VBulletin Forumdisplay.PHP Remote Command Execution Vulnerab... ... AWStats Debug Remote Information Disclosure Vulnerability ...
    (Focus-Microsoft)
Loading