Without knowing which patches were pushed, this is only a guess:
http://sihmar.com/fix windows 10 update kb4022725 kb4022715 download stuck blue screen and more/
http://news.softpedia.com/news/easy fix for windows 10 cumulative update kb4013429 issues 514030.shtml
Please note that these articles are not from Ivanti/Shavlik so please implement any instructions at your own risk.
Do you have a list of patches pushed?
Can you confirm when the scan occurred and when the deployment was scheduled for?
What version of the content did you use? Help > Refresh File will give you this information.
Exactly which OS is this happening to?
I've seen a few of these pop up this cycle too. A few of them I've been able to recover from going back to the last known good configuration.
I'm seeing it on machines running Windows 10x64 Enterprise 1607
I THINK, and I have no proof to back this up because I'm still waiting for the dead machines to get back to me, but it looks like its when applying the MS17-06-W10, MS17-06-AFP, OR the MS17-06-SLV.
From my shavlik console I can see those are "executing" but the machines don't come back for them to do a post scan so I can't tell if they're erroring out.
If there's any logs on my server that could help, let me know and I'll pull them. Once I get one of the dead machines in my hands I hope to find more info.
The logs from the target C:\Windows\ProPatches\Logs would let us know which patches were installing.
Ok, Once I get the machine and can get into it I'll try and grab those.
For us, to fix the Inaccessible boot device problem is the same as the previous one where you have to back out the patch. If you have this problem, follow the fix provided by Microsoft: https://docs.microsoft.com/en-us/windows-server/administration/windows-server-update-services/deploy/monthly-delta-update-isv-support-without-WSUS
Remove any package in Pending state by running the command: dism.exe /image:<drive letter for windows directory> /remove-package /packagename:<package name>
It seems that perhaps the previous Shavlik xml caused this issue, which should hopefully be fixed now by updated detection logic. Check the xml releases here: https://protect7.shavlik.com/
Yes, I have 4 Surface Pros that have gone down. So, this was a Shavlik issue?
We have the same issue. 6/16 PMImport resolves the issue. Shavlik Detection Rule screwed up and installed both full and delta cumulative patches. The new detection rules installs only one.
The Tues 6/13/2017 11:07 PM XML 18.104.22.16835 release, had a detection issue that may have allowed a full and delta patch to be pushed to two specific Windows 10 builds. The issue was identified and resolved on 6/14 just after noon Central Time US. The specific build that resolves the detection issue is: Wed 6/14/2017 12:56 PM XML 22.214.171.12443. You can verify your XML build under Help About and can force content updates using the Help Refresh Files option to ensure you have the latest content pushed out in your environment. If you are using distribution servers that leverage: sync core engines and definitions, or All engines, definitions, and patches, and do not automatically sync as content updates, it is recommended that you force a sync to ensure all content is up-to-date throughout your environment.
Specific builds affected:
Windows 10 1703 Build 15063.296
Windows 10 1607 Build 14393.1198
In March, when Microsoft introduced the Delta patch for the Windows 10 cumulative update, it quickly became known that there was an incompatibility introduced when the Delta and Full update were applied at the same time. We have checks in place on our backend processes to watch for this. However, a case came up which allowed this to slip by. We have reinforced that validation and also have put a Dependent Action in place that should prevent this scenario from happening again in the future. (For those of you unfamiliar with Dependent Actions, these operate at the execution level and allow us to handle dependencies at execute time.)
With that being said, this particular “inaccessible boot device” error can be caused in a number of ways. There are threads in the Microsoft community going back to 2015 relating to this error, which was well before the Delta
patch was introduced. (Here’s an example) If you see this error, it does not necessarily mean it was caused by the Delta and Full cumulative update being applied at the same time. If you encounter this error, and are uncertain of the root cause, you can contact our support who will help sort it out.
Manager of Product Management, Security
Cheers. This saved my guys a couple of rebuilds. We had a couple of machines which blue screened after a round of updates.
Luckily for us, the machines were only desktops and weren't encrypted so it was relatively quick.
I was wondering though. We do have users who have Surface Pro machines which are encrypted and the HDDs are not accessible. Quick question, how would we repair these machines?
Problem is the machines are not made to be serviceable and would require a specialist to open the machines to remove the HDDs. Which would have to be put in a machine with an M2 connector, (if the storage wasn't soldered to the board) and then decrypted.
Unfortunately we had the same issue with a few encrypted Surface's. If you saved the bitlocker key then you are able to unlcock and do the steps necessary to get the device working again. For us some of them were not saved and we had to do a complete rebuild using the USB recovery process. From now on, we are making sure that any surface with bitlocker enabled gets the key saved on the network.