7 Replies Latest reply on Jan 20, 2010 7:58 PM by SafeBoot

    McAfee End Point/Safe Boot

      Can anyone please provide examples of why the computer may experience a Hard Drive Failure after installing McAfee End Point/Safe Boot encryption software. SafeBoot Administrator v5.1.3.0 Build 52000 (513-0025) I am aware that this s/w will scan the Hard Drive for bad sectors and may uncover these bad sectors.
      I have latest version of the End Point/Safe Boot software and have updated the BIOS for compatibility. PointSec and PGP (all other encrypting s/w) has been uninstalled and x64 OS is not being used; however, I may have overlooked other software that may cause conflicts. I am using an Image LoadSet on Dell Computers.
      Generically speaking, what other conditions may lead to a potential Hard Drive Failure?
      Thank You in advance in anticipation of some helpful clues. happy
        • 1. RE: McAfee End Point/Safe Boot
          whats the reason you think you have a hard drive failure? Do you have hard errors, bad sectors etc?
          • 2. HDD Failure
            I have had about a dozen Hard Drive Failures out of 10,000 McAfee End Point/Safe Boot pushed over the network. Some of the Errors include: Error reading disk sector 0XE0020007 ..... Error: e0040008- unable to locate boot code image while synchronizing ..... oXE0020022 unknown safeboot error ..... SafeBoot installation exposed imperfections in the drive and caused a severe slow down. Dell Diagnostics revealed the drive was bad.
            Although, nothing the product does will break the physical hard disk, these Hard Drive Failures seem to appear after installing the application. This may be due to the encryption s/w revealing the bad sectors as part of the scan.
            Thanks
            • 3. RE: HDD Failure
              EEPC doesnt scan the drive for bad sectors, but of course it reads and writes each one, so, if you've got a bad drive (but just haven't noticed yet) doing something like writing each sector will point it out for sure.
              • 4. RE: HDD Failure
                Something we've considered by haven't implemented is running chkdsk before we run the installer package. Not a full fix or repair, just a quick check, and if problems are reported (a non-zero errorlevel returned), we return an error to our console and can check up on it at a later date.

                I might not have all my facts right on this either, but I *think* some vendors are now writing some hard disk health data to WMI - maybe someone else can elaborate, but you might be able to read this to get an idea of health as well.

                Of course, this only helps with future deployments and not the existing ones. I'd be interested to hear how you make out.
                • 5. RE: HDD Failure
                  You can get the S.M.A.R.T data from WMI, strangely I'm writing a VBS class to do exactly that at the moment. I'll post it here if anyone's interested. It's simple to get the disk state (good or failed), but getting the actual metrics is a little more complex.

                  The interesting thing about S.M.A.R.T data, is it doesn't seem to be too useful - Google did an excellent report on it:

                  research.google.com/archive/disk_failures.pdf

                  If I remember rightly over half the drives that they had fail didn't report anything bad in their S.M.A.R.T feedback.

                  In my (admittedly limited) experience, every time chkdsk has thrown significant bad block errors, that drive has never survived a reboot, but I agree that file system errors (which would not affect the encrypt/decrypt anyway) will get trapped using your methodology.

                  The bad-block remap that's done internally on the drives should catch everything that comes up in day-to-day use. Once that system runs out of space it's pretty much game-over for the drive.
                  • 6. Re: RE: HDD Failure
                    SeanKeeley

                    We're experiencing a roughly 0.5% failure rate on encrypted drives. I believe, however, that chkdsk is largely useless on modern HDD. Because modern drives silently remap bad sectors, Windows never even knows about them -- the only time you get a bad sector reported to/by Windows is when all the hidden spare sectors have been exhausted. This is the reason why, as the previous post states, once you get a bad sector, the drive is basically finished!

                     

                    Once you understand this silent sector remapping, the failure after initial encryption makes sense. Rewriting all the sectors on the drive (something that may never happen in the life of a normal hard drive) can use up all or most of the spare sectors if the drive is marginal. The problem is, of course, that no one knows (other than possibly S.M.A.R.T.) that the drive is about to fail.

                     

                    For the same reason, decrypting a failing hard drive can make it worse, since it also rewrites every sector. For this reason, I attempt to use WinTech to copy files off a failing HDD whenever possible, decrypting only as a last resort.

                     

                    As an aside, the SpinRite 6 recovery tool does work on an encrypted HDD since it is a sector level recovery tool that doesn't care about the actual data format. Although I've tried it on a few HDDs, they were in too bad shape to make any judgement. SpinRite may be useful, however, to test the current state of a drive. It also displays the S.M.A.R.T. data.

                    • 7. Re: RE: HDD Failure

                      This is an old thread, but inbetween the last posts there was a lot of info published on my blog, and some monitoring tools.

                       

                      http://simonhunt.wordpress.com/programming/s-m-a-r-t-or-not-so-smart/

                       

                      and

                       

                      http://simonhunt.wordpress.com/2009/08/21/new-s-m-a-r-t-monitor-tool/