Files unable to decrypt when removing Dell Encryption
I am trying to decrypt a system, while troubleshooting another issue. I've found that 0 out of 3 systems that I've tried to decrypt have finished successfully - the decryption service is still running after weeks, months.
Here's some errors from the logs.... (from various systems, all have similar errors)
[05.16.17 08:11:54] SDE Decrypt Service - DecryptSweep_CheckDecryptFile(): Error calling DeviceIoControl(CREDCEF_ChkPathEncr) for file "C:\System Volume Information\{2c601cfa-303d-11e7-9dfa-e4a471bd4977}{3808876b-c176-4e48-b7ae-04046e6cc752}", win32Err = 5
[05.16.17 08:11:30] SDE Decrypt Service - DecryptSweep_CheckDecryptFile(): Error calling DeviceIoControl(CREDCEF_ChkPathEncr) for file "C:\pagefile.sys", win32Err = 32
That was my thought exactly, but it was easier said then done.
- I tried clearing recycle bin to no avail - no files where in it.
- I tried disk cleanup, even though it said 8bytes in recycle bin
- I in-hid the OS folder C:\$Recycle.Bin - I could see the files, but access denied
- Boot into safe mode - try to delete files it let me delete them, but they just moved to another folder - - Access denied.
- Booted into Linux live (Ubunto), it was unable to mount the windows partition
- Disabled "Fast Boot" in Power Settings of Windows 10 (it uses Hybrid-sleep)
- Booted back into Ubunto, deleted the files, reboot...
- Success - Decrypt agent is no longer running and the folder in programdata cleaned itself up.
Perhaps "Fast boot" was the issue all along, and the reason why rebooting didn't allow access to those files? Will this be fixed in the future version of the client?
win32Err=32 is similar to error 5. The process cannot access the file because it is being used by another process.
win32Err=998 references an "Invalid access to memory location." error which I believe to us is being caused by the file path being over 255 characters.
First thing we should confirm that your SDE exclusions are up to date. Below is an updated list we recently published.
Second we can add the below registry value. This will help up the amount of file sizes the agent can decrypt during OS startup. This is safe enough to throw in place on any machine you need to decrypt. This key should help with the 5 and 32 win32err codes.
HKEY_LOCAL_MACHINE\SOFTWARE\Credant\DecryptAgent\
MaxBytesReboot=REG_DWORD:0
Finally the 998 codes. From the logs they look to be temporary files that should be able to be safely deleted. I understand that is a manual process but there is a fix for it in the 8.15 release of DDP|E which should be available on dell.com soon.
Dell-StephenO
Technical Team Lead - Software International Product Support
We have an open case with ProSupport to investigate a reproducible bug we found. Systems failing to boot when they are completely powered down, but once they fail to boot once they will boot just fine. It's definitely something with the Encryption client.
So, I had to decrypt a few systems to get users up and running, and discovered that they would never finish decrypting. I actually stumbled onto this several weeks prior while troubleshooting an unrelated issue - I had to decrypt a user and then when I went to re-install DDP on their system WEEKS after, it said it was still decrypting.
I am booting into safe mode on one affected system to attempt manually deleting the TMP files that it's stuck on. They were locked by SYSTEM and I could not delete them. Will report back...
It's hard to make suggestions when I don't know your environment but from the top level best practices standpoint you have excluded what I would recommend.
Are you having any application conflicts? Usually when we have those that's when we add exclusions and usually those are based around security products. Generally we want to whitelist those directories and if applicable whitelist our software files\folders from the security vendors product.
Dell-StephenO
Technical Team Lead - Software International Product Support
We are looking into methods to help us better decrypt these hard-to-access files. Fast Boot was a great call, as the hybrid restart that it forces would cause issues with how we hold files in memory on reboot to decrypt.
Changes to this space are coming in future versions, let me know if you would like to chat on this more via DM and we can talk potential strategies around this if needed.
SgtTomK
14 Posts
10342
0
Posted August 3rd, 2017 10:00
Dale,
That was my thought exactly, but it was easier said then done.
- I tried clearing recycle bin to no avail - no files where in it.
- I tried disk cleanup, even though it said 8bytes in recycle bin
- I in-hid the OS folder C:\$Recycle.Bin - I could see the files, but access denied
- Boot into safe mode - try to delete files it let me delete them, but they just moved to another folder - - Access denied.
- Booted into Linux live (Ubunto), it was unable to mount the windows partition
- Disabled "Fast Boot" in Power Settings of Windows 10 (it uses Hybrid-sleep)
- Booted back into Ubunto, deleted the files, reboot...
- Success - Decrypt agent is no longer running and the folder in programdata cleaned itself up.
Perhaps "Fast boot" was the issue all along, and the reason why rebooting didn't allow access to those files? Will this be fixed in the future version of the client?
Thanks,
-Tom