So oh hum i forgot i was encrypting my drive today with bitlocker and i updated my realtek audio drivers,and its asking me to reboot, can I reboot when bitlocker is encrypting or should i just wait till its finished and then reboot its been running all day now and its 65% done question is will it mess up the audio drivers if i don't reboot right a way??. man i can't believe i did a idiot thing like that ugh i been working to much lol.
Better wait, bitlocker should have no impact on driver installation but stopping bitlocker may render drive useless.
I waited
You can safely reboot whilst the drive is encrypting.
Safety is always relative. While rebooting while encrypting may work most of the time there are many things that could go wrong and it is best not to take the chance if it is not necessary.
Such as?Safety is always relative. While rebooting while encrypting may work most of the time there are many things that could go wrong and it is best not to take the chance if it is not necessary.
How about better safe than sorry. I have seen systems screwed up by stopping updates and checkdisk and even de-fragmentation.Such as?
Checkdisk and updates I can understand messing things up if stopped at any point during the process.
Drive Encryption shouldn't have any adverse affects :
Solved Can I shut down my PC while BitLocker is encrypting? - Windows 10 blog
BitLocker Drive Encryption in Windows 7: Frequently Asked Questions
Every time you mess with files something can go wrong, bitlocker and other encryption programs have nasty potential to render whole disk and files in it useless. One bad sector suddenly shows up and it's curtains for it.
In theory premature termination of an encryption process should cause no harm. The developers have built in safeguards that protect against such things. But in the real world things don't always work out that way.Code:j
There is a saying: Nothing is foolproof because fools are so ingenious. That is very true. And it is not just user error that is involved.
Maybe there was a bug in the software, or a device driver, or the drive. Maybe there was some unusual situation that the developers did not anticipate or could not reasonably protect against. Maybe a device driver requested that the hard drive flush it's internal buffers and the drive reported that it did. But it lied. It is known. Maybe there was a disk error that occurred at the wrong place at the wrong time with unpredictable results. Protection against power termination is particularly troublesome. There are too many unknowns and unknowables to predict the results with certainty. And the list goes on.
While making a software process foolproof is a laudable goal experienced developers know that it is not truly realizable. There are too many things that can go wrong.
While we should be grateful for safeguards we should not rely on them if it is avoidable.
