Earlier this year I was working with a customer to troubleshoot 7B BSOD related to Microsoft Cumulative Updates. In this customer’s case the problem was because their third party patch tool was applying both the DELTA and FULL updates simultaneously. With some extensive time on the phone with Microsoft we figured this out but then we had a difficult time identifying which systems were about to BSOD. The BSOD would occur reliably on systems which had applied both the DELTA and FULL update and were pending restart. So as part of troubleshooting this we discovered that the CU status is stored in xml files in the c:\windows\servicing\sessions folder. These XMLs contain the targetState and the current (lastSuccessfulState).
Here’s an example of a FULL update for Adobe Flash Update (KB4048951) which is staged and requires a restart to reach the target state.
<?xml version="1.0" encoding="UTF-8"?>
<Session retry="true" pendingFollower="false" lastSuccessfulState="Staged" currentPhase="1" options="33555248" client="WindowsUpdateAgent" id="30631874_880604853" version="8.0"><Tasks><Phase seq="1"><package options="0" id="Package_for_KB4048951~31bf3856ad364e35~amd64~~10.0.1.0" targetState="Installed" name="KB4048951"/></Phase></Tasks></Session>
Its important to note that most updates are applied via dism and sessions.
Here’s another example of a DELTA update for MS CU KB4048954. Its easily identified as a delta because of the name containing Wrapper and its identified as a CU because of the name “RollupFix”.
<?xml version="1.0" encoding="UTF-8"?>
<Session retry="true" pendingFollower="false" lastSuccessfulState="Staged" currentPhase="1" options="33555248" client="WindowsUpdateAgent" id="30631872_3497762345" version="8.0"><Tasks><Phase seq="1"><package options="0" id="Package_for_RollupFix_Wrapper~31bf3856ad364e35~amd64~~15063.726.1.7" targetState="Installed" name="KB4048954"/></Phase></Tasks>
Both of the update examples are in a stage where they will be installed upon the next restart.
Now if there were session files in this folder for BOTH the WRAPPER (delta) and the FULL for the same CU then we would have a problem, particularly if they were both Staged both had a targetState of Installed. So we have a manual problem identification process. To remediate we were instructed by the MS support to delete both the session files to prevent the BSOD on restart. This did work for us and then we reapplied either the DELTA or the FULL and not both simultaneously. Now this customer has nearly 150,000 SCCM Clients so we were not about to manually review XMLs and delete the necessary ones on all systems. SCT wrote-up a solution for this with plenty of contribution from the customer as well. See Part 2 coming soon.