S3 Sleep Causes Bluescreen on Any Connection After Wake

[CollinChaffin]

Opening a new issue since the one I had been commenting in was an old issue (#205) and for some reason closed without a resolution and this may or may not be related. I have now after exhaustive testing been able to reproduce this bug 100% of the time. This was tested now on seven different systems, both physical and virtual all on the latest rdpwrapper version available (1.61) and both x86 and x64 of both Ultimate and Enterprise Windows 7. I did not proceed in taking the time to stage any later OS test systems and after this became clear that it was easily 100% reproducible frankly I did not feel it was worth the effort.

I will begin with stating that the limited ability for me as the end-user to debug log the wrapper has proved very unhelpful, as this wrapper clearly is doing in-memory patching at init time and then NOT AGAIN. This testing IMO has proven that therein is also part of the root cause.

Take any x64 win7 (of ANY flavor), patch with rdpwrapper 1.61, reboot. Make initial connection(s), repeat, heck make a few connections all from the same test host using different accounts - you will not see any failure. Then, regardless of disconnecting any connections (because it simply disconnects upon sleep), place the host into S3 sleep (must first set the bios to S3 sleep to RAM - this is usually the default on newer systems). Wait a few seconds and awake the system. Make a single connection and just after you see the screen of the host (re)lock indicating it has accepted the login (but before you see the RDP window paint an initial screen) you will then generate a hard bluescreen 0F crash on the host.

Back to the logging - I was hoping this logging mechanism logged something upon connections, but on my systems all it ever seems to log is the startup init params, and the log of it doing the initial in-memory patching. Since I am very confident in the WHAT part of what is happening in this crash, it dose not however surprise me that nothing is logged since the whole problem revolves around the wrapper unfortunately NOT re-patching in RAM when the RDP drivers are obviously being reloaded after a S3 sleep wakeup.

I have the same systems with sleep turned off now, and have made dozens and dozens of connections using mult accounts and no crash on any as long as the S3 sleep does not occur at least once. Once it does even once - all bets are off expect a bluescreen. Hopefully this can be fixed to somehow either change the in-memory patching and maybe an area was just missed that will take care of this, or perhaps this is more serious and requires a whole different approach (like going back to physically patching dlls with each version). Hopefully not the latter.

Hope all this testing and detailed writeups have helped. Again I have dedicated substantial time in exhaustively testing on multiple systems and this really is a pretty severe bug that is hard-crashing any system with the wrapper that uses the sleep function and at the very, very least there should be big red writing on the readme warning folks not to even use this wrapper if you use S3 sleep or risk OS corruption from the constant crashing (which has now happened to 2 of my HTPCs over time).

Let me know if I can help in any other way. I would be more than happy to alpha test any proposed fixed versions!

[binarymaster]

We need to know which driver/library causing the BSoD, please provide a screenshot/photo.

[CollinChaffin]

So sorry for the delay. Here is a screenshot of the bluescreen, the minidump view showing the module (a built-in MS one you will recognize), and I even went as far as to export the dump into a readable format which is also below. Again this is VERY easy to reproduce 100% of the time. I have only been able to test this issue on WIN7 but if I get time to free up perhaps I can test it on later WIN8-10 as well in virtual. Based on it crashing the way it is, I cannot believe any OS will handle the reinit after wake of the same RDP 8.x assemblies since they are really the same across the OS' for v8).

Bluescreen pic:

Minidump Screenshot:

Minidump Details:

==================================================
Dump File         : 072917-15319-01.dmp
Crash Time        : 7/29/2017 2:31:48 PM
Bug Check String  : UNEXPECTED_KERNEL_MODE_TRAP
Bug Check Code    : 0x1000007f
Parameter 1       : 0x0000000d
Parameter 2       : 0x00000000
Parameter 3       : 0x00000000
Parameter 4       : 0x00000000
Caused By Driver  : Wdf01000.sys
Caused By Address : Wdf01000.sys+862d
File Description  : Kernel Mode Driver Framework Runtime
Product Name      : Microsoft® Windows® Operating System
Company           : Microsoft Corporation
File Version      : 1.11.9200.16384 (win8_rtm.120725-1247)
Processor         : 32-bit
Crash Address     : Wdf01000.sys+8afb
Stack Address 1   : Wdf01000.sys+862d
Stack Address 2   : Wdf01000.sys+f96d
Stack Address 3   : Wdf01000.sys+1744a
Processors Count  : 2
Major Version     : 15
Minor Version     : 7601
Dump File Size    : 164,271
Dump File Time    : 7/29/2017 2:33:35 PM
==================================================

[edddiiie]

Hi binarymaster and Collin. I was reading what Collin was describing and came here to support his theory. I had an old PC with Win 7 64 bits so I decided to test the wrapper for the first time on this machine. It worked fine all day yesterday and today I set the hard drive to sleep after 15 minutes, I wanted to see how my PC handled wake on LAN initially but got the bsod. First couple of times I ignored it but then I noticed a pattern that it only happened after the PC goes to sleep and I try to log in using RDT. I thought I'd look up if anyone else was having the same issue and here it is.

I did few more test and sure enough was reproducible as described above. I continued testing to be sure to the point that the system was corrupted and could not recover. Now I attempting to repaid the PC and if no luck will do a clean install.

Thanks Collin for writing up two post about this issue and binarymaster good job with this project. I think this post should remain open on the to do list in case you have free time. It may even be related to other little bugs that are not publicly known, addressing the cause will make the code more stable.