Best practice when installing Windows updates
Posted by , Last modified by James Suen on 10 Mar 2015
We’ve all been there. Tuesday hits and Microsoft releases a slew of new Windows updates. After spending time downloading them, they sit there waiting for your approval. After a while you think, “All right. Might as well.” You click accept and the install starts. The PC then asks for a reset to finish. You accept and watch as the PC turns off and back on.
Then the screen loads up and boom –the dreaded Blue Screen of Death (BSoD).
Wait, what? You just downloaded an update.
What happened? Who is responsible for this?
The easy answer for some people is to blame RollBack Rx or Drive Vaccine. Why? Because our software is designed to instantly get people out of disasters. In their minds, this counts as a disaster and therefore the software should be able to get out of it. Fairly enough, our software does allow the user to load up an older snapshot with RollBack Rx, or load into the “LGK” (Last Good Known) image on Drive Vaccine, erasing the mistake most of the time. But there have been some updates where even RollBack Rx and Drive Vaccine weren’t able to get out. The reason is Windows was so heavily altered that it effectively removed, blocked, or deleted our subconsole system. RollBack Rx and Drive Vaccine are good – very good – but there’s nothing that can withstand deep rooted changes of the entire OS.
In response to this our software by default now only downloads Windows updates, but does not install them. It opens the door for the user to proceed, but it’s up to each individual whether or not to step in right away, or wait for the all clear by our team (announced in this forum thread here: http://bit.ly/113jHvh).
When something went wrong with our software
That’s not to put all the blame on Microsoft, as there have been moments where our software was at fault. It doesn’t happen often, but there’s a surefire way to know when something went wrong with our software and when it did not. Simply enough if it was our software that was at fault, the subconsole system will simply be removed entirely.
In this case the best course of action would be to go to support.horizondatasys.com and Submit a Ticket. If possible, once back into the machine, navigate to Program Files --> Shield and attach these four files to the ticket (preferably merged into one zip file): 128.dat, shield.dat, subconsole.log, setup.log.
In the ticket description box please define what OS you’re using, what build number of RollBack Rx or Drive Vaccine you’re running (which can be found by navigating to the About menu), and define the steps you took before the issue occurred. The more information provided the better. A technician will review the ticket and respond within 48 business hours.
When the software is not at fault
Let’s say the BSoD happened.
You reset the PC, press the ‘HOME’ key and boot into the subconsole menu for either RollBack Rx or Drive Vaccine. If you can enter into this subconsole after a Windows update, then our software is still in tact. Even if a snapshot cannot be loaded, or the “LGK” in Drive Vaccine cannot load, then this is due to the Windows update itself and not the software being ineffective.
This is why the software team here at Horizon DataSys cannot stress enough how important it is to follow our Windows updates thread here on our community forum. From there all announcements are made first in regards to updates.
We also share our information through our Facebook page (www.facebook.com/horizondatasys) and our Twitter @HorizonDataSys.
Information is power!