xp remote desktop bluescreen or how to shoot your pc
techsc
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
ATI video cards?
--
Shenan Stanley
MS-MVP
--
How To Ask Questions The Smart Way
http://www.catb.org/~esr/faqs/smart-questions.html
techsc
The bug is not related to any video card. I can reproduce the bsod on ati,
nvidia and even on vmware virtual machine cards. Anyone can try it.
Shenan Stanley
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.
techsc
It is a bug in Windows XP and after one year there is still no reaction or
fix available.
Geoff
Not very constructive. The fact it is reproducible across a variety of
platforms is cause enough for concern. XP is far from dead, since MS
has yet to produce a newer system in sufficient population and appeal
to supplant all the installed XP boxes, it should still be on the
table for a fix. It's a bug that should have been detected and fixed
by now. The bug is reproducible on my Dell laptops and HP desktops.
If this scenario, or something like it, can be shown to kill a machine
during the connect process without needing a valid login it would make
for a fine denial of service attack. Since the code base for RDP is
probably close to if not identical to Terminal Services it could be
used to take down a TS box. It demonstrates a potential vulnerability
that could be exploited as a DoS or, with the proper frames, a way
into a kernel driver for elevation of privilege.
To techsc: this is not a proper place for a bug report in any case.
This should be submitted to the Microsoft support team as a proper bug
report, not in the newsgroups. You won't get much action from MS by
posting here, as you have demonstrated.
Shenan Stanley
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.
techsc
@Geoff:
You've pointed out the real nature of the issue.
I have my reasons, why sometimes people connect with different color depth -
for performance reasons or simply by accident. However, this is not the point.
It is a real bad bug.
Please: How can I report that bug to Microsoft correctly?
Thank you
Chris
Shenan Stanley
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?
techsc
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
And please stick to the thread. I have posted a very simple and 100%
reproducable bsod bug. I am not the originator of any nvidia thread.
Your statement, it would be required to change the color depth several times
is wrong. However, this is also not the point.
Shenan Stanley
> Shenan:
>
> And please stick to the thread. I have posted a very simple and 100%
> reproducable bsod bug. I am not the originator of any nvidia thread.
>
> Your statement, it would be required to change the color depth
> several times is wrong. However, this is also not the point.
I did stick to the thread.
I can do nothing for you. No one here really can.
Sure, the problem is reproducable - and some people (in some ways) could
cause this if they do not log off a remote machine and then reconnect to it
twice more - the second time using a different bit-rate than the first and
then disconnecting (without logging off) and connecting back the third time
at any bit-rate other than the second connection - including but not limited
to the originally connected bit-rate.
Report it to Microsoft.
Stop using Remote Desktop and switch to something else would be my actual
suggestion - TeamViewer is great, but if for commercial applications, VNC
and Single-Click gives you almost the same functionality for free, and both
without as much setup on the customer end.
I use all sorts of remote tools to connect across many different types of
internet connections all the time. I know of many help-desk setups that do
it as well and they do not encounter this issue - mostly (I think) because
they just have not seen the need to change the bit-rate and combine that
with multiple logons with the same user without logging out of the remote
machine.
techsc
if you have no helpful input please do not reply to such threads.
Bill Kearney
Call Microsoft and report that you have a problem. Carping about it on
newsgroups is a waste of bandwidth. As is taking issue with people trying
to help.
In other words, STFU.
"techsc" <tec...@discussions.microsoft.com> wrote in message
news:8AD0464B-8FE0-4924...@microsoft.com...
Shenan Stanley
> - i have posted this bug report more than one year ago already -
>
> Windows XP Pro En SP3 Remote Desktop Blue Screen Procedure:
>
> Here comes the procedure to reproduce a severe bug in the windows xp
> terminal service (RDPDD.dll):
>
> Set up a windows xp pro host and connect then from a remote
> computer via remote desktop.
>
> 1) connect and logon (create new session) at color depth 15bit
>
> 2) disconnect (leave the user logged on)
>
> 3) connect and logon to the created session at color depth 16bit
>
> 4) disconnect
>
> 5) connect and logon to the created sesseion at color despth 15bit
>
> -> voila, the remote desktop host system reboots!
>
> - I can reproduce this bug on all 4 availble computers (all xp pro
> with sp3) at my location.
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.
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.
Tom
May I suggest you to test a more recent build of Rdpdd.dll (23-Jan-2009).
In my eyes, this problem could be related to this issue:
http://support.microsoft.com/kb/963038/en-us
Kind Regards
Tom
Shenan Stanley
I agree with the suggestion, although the issue does not give the error(s)
mentioned in the KB article.
Taking the screenshot out of the recorded examples I gave, you can see the
bluescreen states:
PAGE_FAULT_IN_NONPAGED_AREA
STOP: 0x00000050 (0xBC62FFF0, 0x00000000, 0xBF85B6B7,0x00000000)
win32k.sys - Address BF85B6B7 base at BF800000
The KB Article (http://support.microsoft.com/kb/963038/) refers to this
error:
STOP: 0x1000008E (Parameter1, Parameter2, Parameter3, Parameter4) in
RDPDD.dll
KERNEL_MODE_EXCEPTION_NOT_HANDLED_M
Screenshot of BlueScreen on Remote Machine:
http://picasaweb.google.com/lh/photo/YJ-Oxnn7HJOFcc-4_5AOkA?feat=directlink
But - what the heck? It's the best possibility yet and all the work is done
except for this last part. So I tried it and recorded the results.
Resultant Video (showing the application of the fix, reboot and test
results...):
http://www.youtube.com/watch?v=cWEkACbLYIE
The fix seemed to work perfectly. Good find, Tom.
If you have Windows XP SP3 and your RDPDD.DLL file version is 5.1.2600.5749
or later - you should not have the issue that the OP is reporting.
The videos, pictures and KB article should get you everything you need -
since you can get the fix by reading the KB article, etc. Apply that hotfix
to all affected machines.
If you just want the hotfix...
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=963038
Do the obvious (in case it is not obvious, select the proper language, put
in a valid email address twice, type the characters you see. When you get
the email, follow the directions.)
Hopefully that will fix the problem for the OP and is well documented and
commented about enough to allow those who put effort into it and search will
find the answer they seek. I would ask that the OP comes back and lets us
know if this resolves the issue for them - but it should - given the video
evidence. ;-) Would be nice closure, however.
Nathan
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
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:
Proving that the newer version of files this fix puts out there does remedy
the situation.
Davison@discussions.microsoft.com Jared Davison
http://support.microsoft.com/kb/963038/en-us
This is a patch to RDPDD.DLL.
Thanks for posting this article as it helped me solve the problem. I had
this problem you describe above, and changing the bit depth of rdp client
connections causing Blue Screens on the xp remote desktop server side. I
called Microsoft Support and after spending quite a lot of time with them,
they believed me and investigated and found a hotfix on their site that i was
unable to find myself. This process took about 3-4 weeks to get the solution
from when i first contacted them.
I have tried the hotfix on my systems and it appears to work and haven't had
any further blue screens so far when changing bit depth.
I have since tried to find the link above in google using keywords but it
didn't come up for me so that could explain why we have struggled to find the
solution.
Hope this helps you too.
Kind regards
Jared Davison
tyamadajp
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.
Shenan Stanley
<snipped>
http://groups.google.com/group/microsoft.public.windowsxp.work_remotely/browse_frm/thread/8c4ca8fdb2e87ba5/
tyamadajp wrote:
> 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.
You mean unless you apply the patch given in the thread, right?
It's not like the fix wasn't posted in the very conversation you were
responding to. See below - the hotfix repaired the error completely.
Here is the relevant section of the conversation with a link to the fix...
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
** Although now I would also suggest getting the Remote Desktop Client 7.0
in addition. **
With the above - you should not be struggling anymore.
fujilives
worked
fine, then I'd connect from another machine (presumably at a different
resolution and/or bitdepth) and it would crash the computer I was remoting
into.
This happened several times in the exact same way, and it took quite a bit of
digging to find a solution.
I think it took me longer to find the hotfix since the errors were a little
different, and taking place in a different sys/dll/file than most.
My errors consisted of:
0x0000008E or 0x00000050 (had both)
Both were taking place in win32k.sys, according to the BSOD.
Anyhow, after installing the newest video card drivers and downloading the
hotfix in the youtube video above, my problem was resolved. Thanks a lot for
this article, as I don't think I would have solved this without both the
article
and the video.
cjbu...@gmail.com
This problem is very easy to reproduce:
rdesktop from workstation into pc1.
remote desktop from rdesktop'd pc1 into pc2.
rdesktop from workstation into pc2.
etc etc
You don't have to go to the trouble to disconnect, you just have to steal the connection. I'll often have a bunch of rdp sessions open while I'm moving data or scripts around, and when I want to get into a machine, I don't look to see if I'm already in it from somewhere else, I just fire off a fresh session.
It's a hugely serious problem that was rebooting several production systems with high visibility each time they went down. And it cropped up only when I started using a newer version of rdesktop which is apparently defaulting to different color depth than the old version. Of course I had no idea the issue was with color depth until reading this thread. In 4 years this problem hasn't reared its head until last month when my workstation was upgraded from CentOS to RHEL6.
Thanks again for the detailed explanation of the problem and for the location of the hot fix.
I have to chime in that the person who pooh-poohed the problem was unhelpful to the o.p. and others, even anti-helpful. Instructing somebody that their problem isn't really a problem is just plain wrongheaded.
Regards,
Chris
Christian Lively
> It's a few years old now, but thank you to the contributors in this thread! I couldn't find a solution at support.microsoft.com because I was always searching for win32k.sys as part of my search string.
>
>
>
> This problem is very easy to reproduce:
>
> rdesktop from workstation into pc1.
>
> remote desktop from rdesktop'd pc1 into pc2.
>
> rdesktop from workstation into pc2.
>
> etc etc
>
>
>
> You don't have to go to the trouble to disconnect, you just have to steal the connection. I'll often have a bunch of rdp sessions open while I'm moving data or scripts around, and when I want to get into a machine, I don't look to see if I'm already in it from somewhere else, I just fire off a fresh session.
>