This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
My SB (i5, 256gb, 8gb, GeforceGPU) keeps crashing/freezing during sleep which causes it to shut down. According to the windows reliability monitor it has been happening every day multiple time.
I though I was going crazy because I clearly remember not turning it off before putting it to sleep. I recently had my original SB replaced with a new one which fixed most of the issues from blue screens to flickering that would not go away. But this new one still has the Hello Camera issue where it wont turn on during startup and this new problem that has popped up.
Is this caused by a hardware defect? I really don't want to drive 23km to the other side of my city to get another replacement at a Microsoft store if the issues aren't resolved. Here's an image on the report. As you can see, there are 17 critical events today not to mention all the other days as well. Thanks.
If anyone has a solution that isn't a complete factory reset or system reinstall (I've tried them before) that would be great.
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
Thank you for sharing your observations webdev90201.
I have completed the DISM repair process and verified no Device Driver issues. I can confirm my SB still crashes during Sleep.
What is peculiar (to me) is that my SB seems to sleep and resume properly when not plugged in to the charger (hibernate is disabled) but consistently crashes when plugged in during sleep.
The 4/19 updates did not solve the crashing while in sleep for me either. I too, am on my second Surface Book. I have the i5/256/dGPU model. After applying the updates, I reset my power settings back to defaults with the hope that connected standby and hibernation would all work in harmony. I shut the lid with Chrome and Outlook open when I left work this evening and a couple of hours later turned it on to find it had once again crashed during sleep. I just ran sfc /scannow and am back to having corrupt files since the 4/19 update (all of which had been previously fixed - see my history below).
For a
brief *not so brief* history, I originally pre-ordered my Surface Book, so I got my machine on day one. After a month, I returned it due to many reliability issues (hinge stuck on one side, black screen during resume, hot bag, camera issues). After
the first big set of updates I decided to give it another go and I instead went to Best Buy to purchase another i5/256/dGPU model in late December. Most of the initial issues were indeed resolved and I thought things were going pretty well. I still had a few
issues with the black screen where the keyboard would light up, but no screen. Sometimes shutting the lid, or detaching would solve it. Sometimes I would have to reset it. I gave up on the Windows Hello Camera in order to focus on narrowing the chance of failure.
When the February updates came, I applied them and that's when things got way worse for me. I had constant crashing during sleep. I posted about it on Thurrott's blog. Many others were also saying the 2/17 update was creating new problems for them. I ended up spending the following weekend doing a full reset and re-installing all of my apps so that I could be sure I had a fresh system. During that process, I noticed a few things. After a full factory reset and installing all of the updates (no 3rd party software installed), the sfc /scannow and DISM found problems. Unusual for a new build, I thought. Others have stated that the builds on some Surface Books were corrupt. I'm not sure if it was the initial build or one of the updates, but that's not a good way to start off. Following instructions here, I was successful with the DISM reset, but that had already put a dark cloud over the whole install. I decided to start over yet again, only this time create my own Windows 10 flash drive and download the ISO from Microsoft. I once again did a full reset with this build. Unfortunately, the results were the same. I ran the updates and then had to do a DISM reset and fix corruption.
After my seemingly working fresh install with all the updates, including 2/17 and default sleep settings, it did seem that things were working well (granted I had no software installed). I then started adding programs, one by one and trying sleep / hibernate. I couldn't get it to fail. Then, I installed iTunes. I know (my kids have iPod Touches). That's when the first crash during sleep happened. Researching the DCOM error found that iTunes was definitely the first issue. Since then, however, its been whackamole with DCOM errors as I've added software. I have done the DCOM permissions fix and stopped them from reoccurring, but its been hit or miss. Probably one in ten times, I find it's crashed again. Usually, I will only have Chrome and a couple of apps open. I use Visual Studio all day long, but I always close it when I know I will be away for a while, because I can't trust this machine.
From my own experiences and from reading what other's are saying, here is my take. I think there is a fundamental flaw with the way Windows legacy apps behave with the hand-off between connected standby and hibernation that was possibly introduced or intensified by the changes made in the 2/17 update. The DCOM errors are not new, you can find similar reports of even the same app ids back in Windows 8 and 8.1, but they weren't causing a system crashes until they started happening during the connected standby mode on a Skylake machine. The reason it is not consistent may be related to which apps were running, or services (e.g. video in a browser (even if not playing) which inadvertently causes a DCOM error on the Intel 520 driver, but only after the hand-off from sleep to hibernate occurs. Most of the attention has been on the more obvious errors, such as the hot bagging and the black screen, but I think there is a much bigger underlying problem here that is complicated and sporadic enough that it's not getting a lot of attention.
The April 19 updates also corrupted some files which are not repairable. Will run DISM again.
C:\windows\system32>sfc /scannow
Beginning system scan. This process will take some time.
Beginning verification phase of system scan.
Verification 100% complete.
Windows Resource Protection found corrupt files but was unable to fix some
of them. Details are included in the CBS.Log windir\Logs\CBS\CBS.log. For
example C:\Windows\Logs\CBS\CBS.log. Note that logging is currently not
supported in offline servicing scenarios.
This will be my next step, too (SFC and DISM). Time to go download a current windows image ...
Same here. Confirming that the sleep crash still exists (though, none of the notes said anything about fixing this problem anyways).
The April 19 updates also corrupted some files which are not repairable. Will run DISM again.
C:\windows\system32>sfc /scannow
Beginning system scan. This process will take some time.
Beginning verification phase of system scan.
Verification 100% complete.
Windows Resource Protection found corrupt files but was unable to fix some
of them. Details are included in the CBS.Log windir\Logs\CBS\CBS.log. For
example C:\Windows\Logs\CBS\CBS.log. Note that logging is currently not
supported in offline servicing scenarios.
