What is stopping me from UnMounting an ImDisk virtual drive?

What is the best way to determine what is preventing ImDisk from Unmounting an ImDisk drive?
Sometimes I have to force an unmount and it loses all changes made to the virtual disk, but I have closed all apps (even anti-virus and explorer and run ImDisk -d -u 1 from the command line).

What is the best way to determine what is preventing ImDisk from Unmounting an ImDisk drive?
Sometimes I have to force an unmount and it loses all changes made to the virtual disk, but I have closed all apps (even anti-virus and explorer and run ImDisk -d -u 1 from the command line).

I would recommend either command line tool handle.exe or the GUI Process Explorer, both from sysinternals. Search for both ImDisk and for example R: (or whatever drive letter you use). That would show you what has open references to an ImDisk drive.

I should also mention that there is another problem, with somewhat related results, that happens if the user does not have administrative privileges. A non-administrator is not allowed to dismount the filesystem on a non-removable disk in Windows. Not even if the disk is completely unused by others. ImDisk allows users to dismount virtual disks though, so if you "force dismount" by skipping the filesystem dismount step and go directly to the ImDisk remove step, it works anyway.

Thanks for the reply, but process explorer just shows ImDisksvc. Handle does not list the drive letter of the mounted drive in any of it's outputs AFAICanSee.
As a test I have a file open in Notepad so that ImDisk cannot unmount the drive. But even when I close Notepad, I still cannot use ImDisk to unmount the drive though.
P.S. I am running as Administrator on Win7/32bit PC. I have Symantec AV running but I have 'disabled' it on systray. I suspect that the AV is the problem even if it is disabled, but how to prove it???
Any more thoughts?

Thanks for the reply, but process explorer just shows ImDisksvc. Handle does not list the drive letter of the mounted drive in any of it's outputs AFAICanSee.

Did you use the search button in Process Explorer? With handle tool, you can try:
handle -a | find "ImDisk"
or
handle -a | find "R:" (replace R: with your actual drive letter)

As a test I have a file open in Notepad so that ImDisk cannot unmount the drive. But even when I close Notepad, I still cannot use ImDisk to unmount the drive though.
Any more thoughts?

Are you sure you are running as a (true) administrator? Such as right-clicked on Command Prompt icon and selected "Run as administrator"?

I can find imdisk with handle.exe, but not any reference to J: (the mounted drive) even if I have a file open in Notepad++.


C:>handle -a | find /I "imdisk"
D78: File (RWD) DeviceImDisk0
1648: File (RWD) DeviceImDisk0

Yes, I am full admin (I enabled the user administrator account).

@steve,

Try All Programs -> accessories -> right click on "Windows Explorer" and then run as administrator. Then right click on the drive and try unmounting. (I know, this is GUI instead of command line, but it's just a start point).

Another simple portable tool to help you find what is "using" that drive is "OpenedFilesView", from Nirsoft.net . Use it also with right click -> "run as administrator".

I can find imdisk with handle.exe, but not any reference to J: (the mounted drive) even if I have a file open in Notepad++.

J: and DeviceImDisk0 is in this case exactly the same thing. J: is just a drive letter, a kind of symbolic link that is used to reroute I/O to the actual device. The way handle.exe translates device names back to drive letter is not 100% "safe", so sometimes, like in this case, you get the raw device name in the output instead of an associated drive letter.

C:>handle -a | find /I "imdisk"
D78: File (RWD) DeviceImDisk0
1648: File (RWD) DeviceImDisk0

So, this is with Notepad++ open? When you close it you don't see any references to DeviceImDisk0 anymore?

Another simple portable tool to help you find what is "using" that drive is "OpenedFilesView", from Nirsoft.net . Use it also with right click -> "run as administrator".

That is a really good program to view open handles for a file. But I suspect it does not solve the most probable cause of the problem described in this thread.

If an ImDisk device object itself, or anything on it, is referenced directly by another driver without a handle created, that would not show in any handle tables in the kernel which makes it invisible to applications that shows open handles to files (and other kernel objects). The only thing that shows at that time, is the reference counter on the device or file objects being above zero. Not even ImDisk itself has any practical chance of knowing what actually referenced the object it owns.

This can sometimes be caused by faulty filesystem drivers or filesystem filter drivers, such as filter drivers installed by antivirus software and similar. Such drivers are sometimes left behind even when antivirus software has been removed. Therefore, this could be somewhat difficult to resolve.

That is a really good program to view open handles for a file. But I suspect it does not solve the most probable cause of the problem described in this thread.

I don't know the exact problem in steve's case. I just know that when I have found that I cannot unmount an IMDISK drive with the normal usual method, I used OpenedFilesView and it has helped me. Instead of blindly forcing the unmount, I usually try to find out what is "bothering".

Well, if it is not useful for steve for this particular case, at least it may be useful for some other cases.

I don't know the exact problem in steve's case. I just know that when I have found that I cannot unmount an IMDISK drive with the normal usual method, I used OpenedFilesView and it has helped me. Instead of blindly forcing the unmount, I usually try to find out what is "bothering".

Well, if it is not useful for steve for this particular case, at least it may be useful for some other cases.

Yes, absolutely! I just wanted to point out that it probably would not help in this particular case. But I agree that in most cases it does, so thanks for mentioning it anyway!

A clue - I left the 1.44MB IMA image file mounted as drive J:. When I shutdown Windows, I got a message saying that a floppy disk was still present in the drive (Symantec AV!). It seems that Symantec AV is the culprit, but disabling it does not solve the problem. Unfortunately I cannot change the settings to not scan floppies or uninstall it as it is my work system!

What about disabling services associated with Symantec AV

or even going to device manager and disabling any floppies.

It is the mounted ImDisk device that is the 'floppy' - not sure if I can disable the service. I cannot kill it cos it just starts again (due to AV self protection).

A clue - I left the 1.44MB IMA image file mounted as drive J:. When I shutdown Windows, I got a message saying that a floppy disk was still present in the drive (Symantec AV!). It seems that Symantec AV is the culprit, but disabling it does not solve the problem. Unfortunately I cannot change the settings to not scan floppies or uninstall it as it is my work system!

That is a common phenomenon with Symantec AV products. Even if you disable them, sometimes even if you uninstall them, they still leave their filter drivers in full operation. I have seen this a few times over the years.

Another experience from it were when customers experienced painfully slow network applications etc until we wrote our own communication protocol that Symantec AV did not understand and could not slow down. In these cases, the problem was never solved by disabling Symantec AV. The only thing that made obvious difference was to go into Device Manager, select to show hidden devices, look under Non-Plug and Play drivers, and right-click and disable each driver called sym* or nav* or similar. Just stopping or disabling AV services never solved the problem, it was the filter drivers that had to be disabled.

That is a common phenomenon with Symantec AV products. Even if you disable them, sometimes even if you uninstall them, they still leave their filter drivers in full operation. I have seen this a few times over the years.

Another experience from it were when customers experienced painfully slow network applications etc until we wrote our own communication protocol that Symantec AV did not understand and could not slow down. In these cases, the problem was never solved by disabling Symantec AV. The only thing that made obvious difference was to go into Device Manager, select to show hidden devices, look under Non-Plug and Play drivers, and right-click and disable each driver called sym* or nav* or similar. Just stopping or disabling AV services never solved the problem, it was the filter drivers that had to be disabled.

Thanks for this Interesting Info.
Symantec AV is often giving a lot of trouble .....