Persistent Device Handles

Hi,

Apologies if this has already been asked, but I am getting a bit confused.

I tried installing imdisk, creating a RAM drive, deleting said RAM drive then uninstalling imdisk (silently from command line).

 

First time running all is OK, if I then try and reinstall imdisk even in silent mode I get an error box show up, i've narrowed it down to the windows service installer, if I reboot inbetween installs it works fine.

 

I've read a lot of forum posts and after a bit more investigating I found out that even though I forcibly remove the drive if I issue "imdisk -l" it still shows "\device\imdisk0" in the list, and if I go on to create more virtual drives I get these virtual devices "stuck" they do indeed go away when I reboot, apparently windows can't "lock" the device in order to remove it, but I am running everything as administrator and tried several ways, i.e. the toolkit, control panel, imdisk.net, imdisk command line tool, occasionally the control panel will remove devices correctly but only occasionally and only ones that were created through the control panel applet itself.

 

I have tried this on Windows 7 x32, Windows 7 x64, Windows 8.1 x64, haven't tried on 10 yet but I presume the same will happen.

 

So firstly, Is this a known issue, is there a workaround, i.e. can I use API to remove the "stuck" device rather than reboot?

 

Secondly, is there a way, i'm already setting the environment variable and giving the installer the /y flag, to make windows installer run silently?

 

Thanks in advance!

I tried installing imdisk, creating a RAM drive, deleting said RAM drive then uninstalling imdisk (silently from command line).
 
First time running all is OK, if I then try and reinstall imdisk even in silent mode I get an error box show up, i've narrowed it down to the windows service installer, if I reboot inbetween installs it works fine.
 
I've read a lot of forum posts and after a bit more investigating I found out that even though I forcibly remove the drive if I issue "imdisk -l" it still shows "\device\imdisk0" in the list, and if I go on to create more virtual drives I get these virtual devices "stuck" they do indeed go away when I reboot, apparently windows can't "lock" the device in order to remove it, but I am running everything as administrator and tried several ways, i.e. the toolkit, control panel, imdisk.net, imdisk command line tool, occasionally the control panel will remove devices correctly but only occasionally and only ones that were created through the control panel applet itself.
 
I have tried this on Windows 7 x32, Windows 7 x64, Windows 8.1 x64, haven't tried on 10 yet but I presume the same will happen.
 
So firstly, Is this a known issue, is there a workaround, i.e. can I use API to remove the "stuck" device rather than reboot?

No, the problem is that when you forcefully remove an ImDisk device, there might be handles left to the volume from various places. The ImDisk driver removes access to the volume, removes the drive letter etc and starts to periodically check whether there are any handles open to the device. Once all of them are closed, the device is removed. It is not always easy to see exactly what handles are opened, but generally the Process Explorer tool is a good help investigating this. But there could also be unnamed device object references in other drivers that could be difficult to detect.
 
If you remove an ImDisk device with the -d switch (not forcefully removal), this problem should typically not happen.
 

Secondly, is there a way, i'm already setting the environment variable and giving the installer the /y flag, to make windows installer run silently?

It is only completely silent if it runs without errors. Otherwise error messages boxes are still displayed.

Maybe if you can share the actual commands you are using, someone could spot a mistake or suggest a "better" command. but as Olof pointed out it is possible that *something* (belonging to the Windows OS or to the program(s) you use the ramdisk for) keep the device hooked.

 

Good ol' Unlocker may be useful to find what is hooking the device (when experimenting):

http://www.emptyloop.com/unlocker/

 

Another thing that you may want to try/check is flushing the device, with something *like* Ejectmedia:

https://www.uwe-sieb...ivetools_e.html

(provided it works on IMDISK volumes )

 

Finally don't forget that there may be timing problems.

 

Wonko

Hi both - thanks for replying.

 

I simplified my steps - I ran the RAMDISKUI tool that comes with the toolkit, created a 64MB RAM disk, the only thing I changed was not to run at windows startup, pressed "unmount" and I got the all too familiar "this volume is in use by another process and cannot be locked".

 

Does the RAMDISKUI took forcefully unmount?  Process explorer, handle etc shows nothing grabbing the handle of the device, i've left the machine for a good few hours and it hasn't released the handles by itself, only after a reboot.

 

it seems pretty consistent and persistent on these pesky device handles.

 

I forgot to mention, I could create the drive, and instantly "unmount" it and it still produces the error, so it's not like anything on the drive is being opened.

 

Thanks

Edited by AWilkes, 09 July 2018 - 10:21 PM.

In Process Explorer, search for handles for the drive letter and also for the device name such as \Device\ImDisk0 or similar. You would not necessarily find anything anyway because there could be a device reference open in kernel mode by another driver and they are not always visible in Process Explorer as handles, depending on how exactly they were created. But they keep the reference counter above zero for ImDisk device objects so the ImDisk driver still cannot remove the device in that case.

 

The most simple step to try is from an elevated Command Prompt (as administrator):

imdisk -a -s 100M -m R: -p "/fs:ntfs /q /y"
imdisk -d -m R:

This should create and format a 100 MB RAM disk and then (not forcefully) remove it afterwards. If nothing "grabs" a handle to any newly created volume this should typically work correctly and not show any devices when you list ImDisk device using imdisk -l afterwards.

I simplified my steps - I ran the RAMDISKUI tool that comes with the toolkit, created a 64MB RAM disk, the only thing I changed was not to run at windows startup, pressed "unmount" and I got the all too familiar "this volume is in use by another process and cannot be locked".
 
Does the RAMDISKUI took forcefully unmount?  Process explorer, handle etc shows nothing grabbing the handle of the device, i've left the machine for a good few hours and it hasn't released the handles by itself, only after a reboot.

 

If you click "OK" on the dialog box displayed by RamDiskUI, yes, the volume will be forcefully dismounted. Otherwise, there is no dismount attempt.

OK, it appears to work from the command line.

 

BUT, why does the control panel applet and the RamDiskUI tool both say they cannot "lock" the volume when trying to unmount the created drive?

 

I know if I click "OK" it will try and forcibly unmount, but why should it need to?  Do I need to do anything to allow it to "lock" the volume?  I am running the UI tool as Administrator, UAC is off.

 

If I don't forcefully unmount then the drive is still there, however, I can issue "imdisk -d -m R:" to remove it from the command line, but the GUI won't, the CPL makes its own mind up if it wants to remove it or not, sometimes it will sometimes it gives a lock error.

 

I think my initial problem was the capital "D" in the command line, but it seems that the GUI tools also have issues with unmounting, I can kind of understand the CPL if it isn't in "Administrator" mode but I thought CPL were in Administrator mode.  My other issue was because the RamDiskUI tool will only forcibly remove the volume rather than cleanly - perhaps a bug or I am doing something wrong?

 

Thanks

My other issue was because the RamDiskUI tool will only forcibly remove the volume rather than cleanly

There is no "clean" way to dismount a volume if the latter cannot be locked. And a volume cannot be locked if there are open handles on it.
With ImDisk (Toolkit or not), you have a warning. All the other tools that dismount a volume with just one click (for instance TrueCrypt/VeraCrypt) are merely ignoring open handles, because displaying a warning is less "user-friendly".

An open handle is not necessarily an open file. It can also be a process that monitors the volume, such as an open window of Explorer or an antivirus.

OK, but why will imdisk unmount with the "-d" command but the UI tool will not?

 

Why can imdisk lock the volume to unmount it (it says it locks successfully on the command line) but the UI tool cannot?

 

I tried your thoughts, no explorer window opened, no AV present, fresh install of Windows 7, installed the TK, ran the RAMDisk UI, created then unmount, same message "cannot lock volume" when asked if I want to forcibly unmount i press no, go to command prompt, and type "imdisk -d -m R:" and it successfully locks and removes the disk.

 

Thanks

I just did a test on Windows 7 SP1 x64. RamDiskUI can create a ramdisk and then immediately dismount it without warning message about the lock.

By the way, did you close the properties window of the newly created volume? This window is created by the "shell", but here the shell is Explorer... And once Explorer has a handle on a volume, even closing all its windows does not always close the handles.
Any service can also do that, and even drivers, as Olof said. It is impossible to know.

The ImDisk driver was initially designed for older systems, that is, more predictable systems. The Toolkit rather aims recent systems and this is why you have an option "Do not show this warning again".

Strange,  yes I noticed the explorer properties window and closed it, but that is the only thing that would have a handle on it, I can reproduce quite consistent with the lock message.  My particular test machine is Win 7 x32 SP1 Professional, I downloaded the latest version from SF.

 

So far the command line is working out, just wish the UI would behave the same.

just wish the UI would behave the same.

The same than what? In command line, you have a confirmation with neither -d nor -D.
And you can still remove the confirmation of the GUI if it disturbs you.

The GUI keeps no open handle on the volume. Otherwise, the lock would never succeed on my test machine.

Windows adapts its list of drivers and services depending on the hardware. So we can never have exactly the same configuration. Even with virtual machines, it is almost impossible.
This means that something in your configuration, a driver or a service, keeps a handle on the volume when the GUI is used. But it does not means that the culprit is the GUI.


But finally, is this really important? If all the files on the volume are closed, and the volume can still not be locked, it will remain only a few bytes somewhere, nothing that could slow down your system.
Moreover, I have seen several times an imdisk device kept in the list because it was dismounted without being locked, and disapear after some minutes or hours.

Well, command line or not the device is created with Windows API calls, the only apparent difference is that the UI tool opens the properties window, so it must be that, so the UI is indeed the culprit, but no, it doesn't matter, as long as I know there is a bug in the UI tool then I can avoid it.

 

It doesn't slow the system down, all it really does is prevent the driver being re-installed if there are stuck handles floating around.

 

The confirmation doesn't "disturb" me, I just wondered why the UI tool said it couldn't lock the volume when the command line tool manages fine.

 

I presume that for the drive properties to be displayed the UI tool has to invoke this, so it could be that the UI tool still has the handle open of this dialog even after I close it perhaps?

 

Anyway, if nothing else this post serves as a placeholder for others who may have this issue, and can't find any useful information about it online.

 

Thanks