xp remote desktop bluescreen or how to shoot your pc

Discussion in 'Windows XP Work Remotely' started by techsc, Jul 5, 2009.

  1. techsc

    techsc Guest

    - 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.
     
    techsc, Jul 5, 2009
    #1
    1. Advertisements

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


    ATI video cards?

    --
    Shenan Stanley
    MS-MVP
    --
    How To Ask Questions The Smart Way
    http://www.catb.org/~esr/faqs/smart-questions.html
     
    Shenan Stanley, Jul 5, 2009
    #2
    1. Advertisements

  3. techsc

    techsc Guest

    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:

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

    >
    > ATI video cards?
    >
    > --
    > Shenan Stanley
    > MS-MVP
    > --
    > How To Ask Questions The Smart Way
    > http://www.catb.org/~esr/faqs/smart-questions.html
    >
    >
    >
     
    techsc, Jul 5, 2009
    #3
  4. 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.


    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.

    --
    Shenan Stanley
    MS-MVP
    --
    How To Ask Questions The Smart Way
    http://www.catb.org/~esr/faqs/smart-questions.html
     
    Shenan Stanley, Jul 6, 2009
    #4
  5. techsc

    techsc Guest

    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:

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

    >
    > 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.
    >
    > --
    > Shenan Stanley
    > MS-MVP
    > --
    > How To Ask Questions The Smart Way
    > http://www.catb.org/~esr/faqs/smart-questions.html
    >
    >
    >
     
    techsc, Jul 6, 2009
    #5
  6. techsc

    Geoff Guest

    On Sun, 5 Jul 2009 18:24:07 -0500, "Shenan Stanley"
    <> wrote:

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

    >
    >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.
     
    Geoff, Jul 6, 2009
    #6
  7. 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.


    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.


    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 Stanley
    MS-MVP
    --
    How To Ask Questions The Smart Way
    http://www.catb.org/~esr/faqs/smart-questions.html
     
    Shenan Stanley, Jul 6, 2009
    #7
  8. techsc

    techsc Guest

    @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

    "Geoff" wrote:

    > On Sun, 5 Jul 2009 18:24:07 -0500, "Shenan Stanley"
    > <> wrote:
    >
    > >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.

    > >
    > >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.
    >
     
    techsc, Jul 6, 2009
    #8
  9. 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.


    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?

    --
    Shenan Stanley
    MS-MVP
    --
    How To Ask Questions The Smart Way
    http://www.catb.org/~esr/faqs/smart-questions.html
     
    Shenan Stanley, Jul 6, 2009
    #9
  10. techsc

    techsc Guest

    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?

    "Shenan Stanley" wrote:

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

    >
    > 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?
    >
    > --
    > Shenan Stanley
    > MS-MVP
    > --
    > How To Ask Questions The Smart Way
    > http://www.catb.org/~esr/faqs/smart-questions.html
    >
    >
    >
     
    techsc, Jul 15, 2009
    #10
  11. techsc

    techsc Guest

    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.

    "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?
    >
    > "Shenan Stanley" wrote:
    >
    > > 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.

    > >
    > > 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?
    > >
    > > --
    > > Shenan Stanley
    > > MS-MVP
    > > --
    > > How To Ask Questions The Smart Way
    > > http://www.catb.org/~esr/faqs/smart-questions.html
    > >
    > >
    > >
     
    techsc, Jul 15, 2009
    #11
  12. 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.


    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 Stanley
    MS-MVP
    --
    How To Ask Questions The Smart Way
    http://www.catb.org/~esr/faqs/smart-questions.html
     
    Shenan Stanley, Jul 19, 2009
    #12
  13. techsc

    techsc Guest

    Shenan,

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

    "Shenan Stanley" wrote:

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

    >
    > 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 Stanley
    > MS-MVP
    > --
    > How To Ask Questions The Smart Way
    > http://www.catb.org/~esr/faqs/smart-questions.html
    >
    >
    >
     
    techsc, Jul 19, 2009
    #13
  14. 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.


    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.

    --
    Shenan Stanley
    MS-MVP
    --
    How To Ask Questions The Smart Way
    http://www.catb.org/~esr/faqs/smart-questions.html
     
    Shenan Stanley, Jul 20, 2009
    #14
  15. techsc

    Tom Guest

    Tom, Jul 21, 2009
    #15
  16. 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
     
    Shenan Stanley, Jul 21, 2009
    #16
  17. techsc

    Nathan Guest

    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.

    "Shenan Stanley" wrote:

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

    >
    > 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.
    >
    > --
    > Shenan Stanley
    > MS-MVP
    > --
    > How To Ask Questions The Smart Way
    > http://www.catb.org/~esr/faqs/smart-questions.html
    >
    >
    >
     
    Nathan, Jul 31, 2009
    #17
  18. <snip>

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

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


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

    --
    Shenan Stanley
    MS-MVP
    --
    How To Ask Questions The Smart Way
    http://www.catb.org/~esr/faqs/smart-questions.html
     
    Shenan Stanley, Jul 31, 2009
    #18
  19. 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
     
    Jared Davison, Sep 10, 2009
    #19
  20. techsc

    tyamadajp Guest

    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.

    > 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."
    >
     
    tyamadajp, Nov 12, 2009
    #20
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Angela
    Replies:
    0
    Views:
    995
    Angela
    Jun 25, 2004
  2. Otto Porter

    Remote Desktop to Remote Desktop

    Otto Porter, Aug 15, 2004, in forum: Windows XP Work Remotely
    Replies:
    4
    Views:
    289
    Bill Sanderson
    Aug 15, 2004
  3. Dave Williamson

    Remote Desktop uses remote PC name if logged in via remote first

    Dave Williamson, Oct 5, 2004, in forum: Windows XP Work Remotely
    Replies:
    0
    Views:
    508
    Dave Williamson
    Oct 5, 2004
  4. BRW
    Replies:
    5
    Views:
    287
    Guest
    Jul 21, 2005
  5. techsc

    xp remote desktop bluescreen or how to shoot your pc

    techsc, Jun 3, 2008, in forum: Windows XP Work Remotely
    Replies:
    4
    Views:
    631
    Protec
    Jun 11, 2008
Loading...

Share This Page