Bitlocked partition "Inaccessible" after unlocking

[gpf]

Running Everything on my new laptop with a bitlocked partition, I have the same problem as this person: https://social.technet.microsoft.com/Fo ... rosecurity

You will see my reply in that thread which explains the problem:

Thanks so much for posting this Bert - you solved the exact same problem on my laptop today! It's been driving me crazy for a long time. I unlock the internal bitlocked partition and the padlock icon changes colour and turns into an 'unlocked' padlock, but there is no drive info (used/free space) and double-clicking the drive produces 'Inaccessible' error.

This morning with the drive in it's unlocked but inaccessible state I stopped the Everything (from voidtools) Windows Service and then refreshed the File Explorer screen (F5). Immediately the used/free space appeared and I can access the drive. Starting the Everything service once the drive was fully unlocked has no effect on the drive. I have used "Everything" for many years as it's the fastest most reliable and customisable file search tool out there (I love this search tool to the moon and back!). This won't stop me using it because it's just so useful, but I may have to create a batch file to stop the service, unlock the drive and then start the service. Before that though I'll contact voidtools and see if they can fix the bug.

Before making today's discovery that Everything is locking the drive, I've been gaining access to the drive daily by locking it after unlocking, and then unlocking it a second time. This ALWAYS works, but is a timewaster.

Are there any settings that can be changed in Options to solve this problem or can the bug be fixed? I am running Windows 10 Pro 1809 OS Build 17763.475

Thanks
Gary

[void]

Thanks for the bug report Gary.

I unlock the internal bitlocked partition and the padlock icon changes colour and turns into an 'unlocked' padlock, but there is no drive info (used/free space) and double-clicking the drive produces 'Inaccessible' error.

I haven't had any luck reproducing the issue here on Windows 10 x64 1809 build 17763.557.

Could you please send some debug information:

• Restart your PC so the bitlocker drive is locked.
• Exit Everything completely (In Everything, from the File menu click Exit)
• Stop the Everything Service.
• Create a shortcut on your Desktop to your Everything.exe with the -svc -debug command line options:
  Everything.exe -svc -debug
• Run this shortcut as an administrator.
• You should see a console open which shows some information about the Everything service.
• Launch Everything to show an Everything search window (ie: run Everything.exe).
• Attempt to unlock your bitlocker volume.
• What is shown in the service console after unlocking appears to fail? could you please send this to support@voidtools.com

[gpf]

Thanks for your reply and request to debug.

I did exactly as instructed and the disk opened fine! I rebooted and tried again but both times it went straight through. I wonder if this is because the Windows Service was stopped? I had the Everything window up at the time, just as requested.

After another reboot I tried opening the bitlocked drive with the Everything service & application running and got the usual unlocked but unaccessible error - attached. The strange thing is it nearly always works after that error when I lock the drive (manage-bde -lock j: -forcedismount) and then try unlocking it a second time (not touching Everything).

If there's any other testing I can do, please let me know.

Regards
Gary

[NotNull]

I don't want to interfere with the debugging going on, but my "IT-uition" tells me that this is caused by Everything being installed on your D-drive, instead of the C-drive.

[void]

Thanks for the info Gary, could you please try running the Everything service with debug logging:

• You can delete the Everything shortcut on your Desktop from earlier.
• Stop the Everything Service.
• Open the Registry editor.
• Navigate to:
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Everything
• Change ImagePath from:
  "C:\Program Files\Everything\Everything.exe" -svc
  to:
  "C:\Program Files\Everything\Everything.exe" -svc -debug-log
  where C:\Program Files\Everything\Everything.exe is the path to your Everything.exe
• Restart your PC to lock your bitlocker volume and start the Everything service with debug logging enabled.
• Attempt to unlock your bitlocker volume.
• After unlocking the volume fails, could you please send your C:\Windows\Temp\Everything Service Debug Log.txt to support@voidtools.com

Note: Enabling Service Debug Logging can write a lot of data to C:\Windows\Temp\Everything Service Debug Log.txt.

Please disable Service Debug Logging when finished debugging:

• Stop the Everything Service.
• Open the Registry editor.
• Navigate to:
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Everything
• Change ImagePath from:
  "C:\Program Files\Everything\Everything.exe" -svc -debug-log
  to:
  "C:\Program Files\Everything\Everything.exe" -svc
  where C:\Program Files\Everything\Everything.exe is the path to your Everything.exe
• Restart the Everything Service.

[therube]

"IT-uition" tells me that this is caused by Everything being installed on your D-drive, instead of the C-drive.

How or why should that matter?
(IMO, it wouldn't, shouldn't. I don't install. My "system" drive [where /Windows/ is] is E:. I've only ever had Everything [extracted] on C:.)

[NotNull]

How or why should that matter?

No idea and no reasonable explanation. That's why it's called intuition

[gpf]

Good morning. I did as requested and have sent you the log file. Strangely the bitlocked drive opened immediately today though, so the log doesn't appear to have captured anything. Nothing else has changed on my laptop that I'm aware of.

Regards
Gary

[Adam1001]

Hello,

I'm also having a similar problem where Everything.exe prevents removal of USB drive encrypted with bitlocker and also causes an error when opening the drive. I found that everything.exe is the problem by going to the event viewer, here is the logged event:

The application \Device\HarddiskVolume14\Program Files\Everything\Everything.exe with process id 12260 stopped the removal or ejection for the device USB\VID_0BC2&PID_231A

the error I receive when double clicking the drive icon after unlocking it is:
E:\ is not accessible
The parameter is incorrect.

everything_e_not_accessible.png (2.85 KiB) Viewed 29583 times

1- after this error occurs, if i try to eject the usb drive i get the error message:
This device is currently in use. Close any programs or window that might be using the device, and try again.

2- if i close everything, i can normally eject the drive and view the files.
3- if i start everything again it scans all the drives and including the bitlocker encrypted drive
4- if i try to eject the drive it ejects normally
5- if i remove the drive and plug it again, the same error (E:\ is not accessible) occurs again......

I'm using windows 10 1093 x64

[void]

Thanks for the info.

It sounds like Everything is not receiving the device removal request.

I'm having trouble reproducing the issue. Could you please provide some more information?

Are you running Everything as an administrator or as a standard user with the Everything Service installed?
To check, please run Everything in debug mode.
At the top of the debug console should be the following two lines:
IsAdmin=x (1 for running as admin, 0 for standard user)
Service=x (1 for Everything Service installed and running, 0 for no Everything Service)

Are you using an external USB drive?

Does the latest nightly build fix the issue?

It sounds like Everything is stopping this device unlocking correctly.

I would love to solve this issue. To do so, I would need to see some debug logs..
Could you please:
Make sure the bitlocker drive is locked.
Make sure Everything is not running.
Start Everything.exe with -debug-log command line option:
Everything.exe -debug-log
Produce the "The parameter is incorrect" error message.
Exit Everything.
Please zip and send your %TEMP%\Everything Debug Log.txt to support@voidtools.com

[Adam1001]

Hello void,

Thank you for the reply, Give me a day or two and I will try to reproduce the problem in a virtual machine. I will upload the whole virtual machine + logs if needed.

Unfortunately the external hard disk which i had the problem with isn't mine so it's not available. but i will encrypt an external hard disk i have and do the tests on it.

[aev]

Hi void, all,

I was also having the exact same problem. It took me 3 hours of troubleshooting to determine that Everything was the culprit -- almost went crazy!

It is definitely being caused by the Everything Service. I got rid of the problem by going into the General settings and unselected Everything Service, but was able to maintain the previous functionality by then enabling "Run as administrator":

everythingbug.png (45.35 KiB) Viewed 29559 times

The inconvenience with this approach is that every time your computer starts, you get a Windows User Account Control dialog box to let Everything run. However, if you only rarely reboot your computer and don't shut down the Everything program, then this is only a minor inconvenience.

For void's bug fixing purposes, let me report the following:

• I can report is that the problem definitively arose somewhere within versions 1.4.1.895, 1.4.1.924, 1.4.1.928, 1.4.1.932 or 1.4.1.935.
  I know this because until recently I had version 1.4.1.877 installed without the problem -- I only just installed the latest version (v1.4.1.935) two days ago, skipping all the intermediate versions I listed above, and today discovered this problem upon inserting an external hard-drive with BitLocker.
• I have two different external HDDs encrypted with BitLocker, and both experience the same problem. One HDD is a 2019 Seagate Backup Plus Slim 1TB drive (model #STHN1000402), the other HDD is a 2013 Seagate Backup Plus Portable Drive (model #SRD00F1).
• Both HDDs work perfectly fine in other computers, and when the Everything program was not running (although I suppose the Everything Service would have still been running in the background, as I never ended the service)
• I am using laptop, specifically a Lenovo Thinkpad X1 Carbon

[void]

I know this because until recently I had version 1.4.1.877 installed without the problem

Very useful, thank you.

Could you please try Everything 1.4.1.959.

This version removes the aggressive inclusion of NTFS volumes without volume information.

[NotNull]

Off topic:

@void:
So at 01:49 (my local time) @aev posted his findings and 42 minutes later you:

- have read the entire message
- interpreted it, analyzed it and pinpointed the possible culprit
- started your code editor
- loaded the current Everything build
- "did some coding stuff"
- Saved it as a new build
- Compiled it twice (64- and 32-bit)
- Tested it
- Uploaded it to the voidtools webserver (over a slow connection)
- Updated the Nightly build webpage with the new build, including description
- Wrote a message back to @aev.
......

I have only one thing to say: WHAT TOOK YOU SO LONG !?!?!

[aev]

@void:

I re-enabled the Everything Service in the settings, etc., then installed the v1.4.1.959 nightly build as per your instructions, and... problem solved!

I have not been able to replicate the problem again, including after rebooting, using different drives, etc. Great work!

As for:

I have only one thing to say: WHAT TOOK YOU SO LONG !?!?!

ROTFL ! But seriously, what an incredible turnaround time!!

[void]

That's good to hear.

It was just a matter of running windiff on the Everything Service and NTFS volume code between version 877 and 935.
Not too much has changed in the NTFS volume code.
Version 903 added aggressive NTFS volume inclusion. 959 reverts this change.
This change may lead to some issues with NTFS volumes not being included (Particularly with Veracrypt/Truecrypt)

[aev]

Hi void,

This change may lead to some issues with NTFS volumes not being included (Particularly with Veracrypt/Truecrypt)

Speaking of which, I have another HDD using NTFS with a Trucrypt volume (a very old Seagate FreeAgent Go drive). And I just tried it out -- I was able to successfully mount and dismount the Truecrypt volume without issue. FYI!

[Adam1001]

Hello void,

Sorry for the late reply, I haven't managed to save some time until today.

I have just done some tests inside a virtual machine and I managed to replicate the issue:
1- create a vmware virtual machine with windows 10 all updates
2- add an extra scsi virtual hard disk, make it 1GB because you will need to encrypt it
3- add another extra scsi virtual hard disk, make it 1GB because you will need to encrypt it
6- encrypt both drives then create some files on each of them.
4- install everythig, default options
5- in Everything settings enable: Automatically include new removable volumes
6- unlock both drives
7.1- use everything to search for files on both drives to ensue that everything indexed both drives
7.2- while everything is showing search results from one of the drives, eject that virtual drive
8- now windows will show a notification asking to unlock the drive ( why is windows asking to notifying to unlock the drive?!!)
9- unlock the drive and the error message will appear.....
10- if it doesn't appear, do the search step, then lock both drives and unlock one of them
11- if drives weren't indexed by everything, then use the (force rebuild) button while both drives are unlocked. repeat the steps starting at 7.1

it's not a must to use 2 drives. the problem showed with only 1
I noticed that the problem appears sometimes only after (force rebuild) is performed

now for the new release, i tested it and it solved 99 percent of the problem. but still the problem appears if you :
1- force rebuild
2- search for files on the encrypted drive
3- while search results are in the list, eject the encrypted drive
4- the error will appear but the drive will be normally ejected

5- unlcok the drive, it will unlock without a problem

[void]

Thanks for the info, Adam.

I've setup two scsi drives on Windows 10 under vmware.

7.2- while everything is showing search results from one of the drives, eject that virtual drive

Does the issue only occur when an encrypted file is visible?
eg: if you search for: !
Does the issue occur?

8- now windows will show a notification asking to unlock the drive ( why is windows asking to notifying to unlock the drive?!!)

I get this too.
Appears to pop up even when Everything is not running.

9- unlock the drive and the error message will appear.....

I've yet to see this error message.

Please try the latest nightly build Everything 1.4.1.960.
This version fixes an issue with Everything holding onto volume handles after RegisterDeviceNotification fails.

[Adam1001]

Hello void,

I tested the latest nightly build and the error didn't appear at all
no problems with ejecting drives
no problems when locking and unlocking
no problems with encrypted removable and fixed drives

Everything is a great tool and I think it should be part of windows.

[Adam1001]

Hello void,

I'm sorry i forgot to answer your question regarding

Does the issue only occur when an encrypted file is visible?

yes it only happened with bitlocker encrypted drives, I never noticed the problem with non-encrypted drives. I don't know if the problem happens with drives encrypted with other methods.

[Chip]

I had the same annoying issue (Everything version 1.4.1.935 x64, Windows 10 Pro build 1909): no access to a BitLocker-encrypted external USB hard disk drive after entering the BitLocker password. The problem is solved with beta version 1.4.1.965 x64.

In my case, the issue was only happening with an external USB HDD, not with another external USB SSD also encrypted with BitLocker.

It took me a long time to figure that the issue came from Everything... I suspect this is happening to quite a few users, it would be good to have a release with the fix.

By the way: thanks a lot for this GREAT piece of software! I use it all the time, it is truly excellent.

[void]

Thanks for the feedback.

Everything 1.4.1.965

[Chip]

In my case, the issue was only happening with an external USB HDD, not with another external USB SSD also encrypted with BitLocker.

Let me correct this bit, as it could be misleading: the SSD is actually formated in exFAT, so it is not indexed by Everything.

[Chip]

Thank you for the release of v 1.4.1.965 ten days ago!