4 replies to this topic

[iturtleman]

I noticed today that if a ramdisk is created and the machine is hibernated, upon reboot, the driver manager window shows that a drive exists even after refreshing the list. the issue with this is that the drive cannot be removed. the error messge is "Error opening device: The system cannot find the file specified. " however addint another disk at the same location mounts properly and displays. At this point attempting to remove the original ramdisk will remove the currently mounted disk. Is there a way to keep this from occuring?

 

[Olof Lagerkvist]

I cannot seem to reproduce the actual problem, but it could of course be that it only happens on some Windows versions. My best guess from your description was that you are probably using Windows 7 x64, so I tried to verify the problem there. But that was just my best guess, I could of course be entirely mistaken...

 

Anyhow, I guess that for whatever reason, the drive letter assignment somehow gets lost, so that the ImDisk drive with everything is really still there, just not accessible through the original drive letter. One way to solve that particular problem could be to assign a new drive letter for example using my dosdev tool, to make it possible to access it again:

dosdev -r R: \Device\ImDisk0

 

...or just remove the drive from command line, using device number:

imdisk -d -u 0

 

But actually, I was under the impression that it would be possible to remove such "lost" devices from Control Panel. But I tested it now for myself and saw that it does not work. It actually used to be possible, but no longer. Since a couple of versions back, the Control Panel applet sends notifications to other applications before removing a drive with a drive letter. This was introduced for better compatibility with applications that keep handles open and need to close them before a drive can be safely removed. Problem is that the logic around that needs the drive to be accessible through the drive letter, which could possibly cause it to work with the wrong drive if many drives have been mounted with the same drive letter.

The problem does not occur for drives mounted without a drive letter in the first place. In such cases, the Control Panel applet does not even try to use a drive letter, but removes the drive by accessing the assigned drive number instead.

So, I am not sure how to solve this. One way could be to add some code to first check if the drive letter is accessible and/or if it still points to the original ImDisk drive, and in other cases open by number and skip the notification logic altogether. I will try to find out something!

 

Then, to solve your original problem with drive letter lost after hibernation, I think we would need to know (at least) which Windows version you are using!

 

[iturtleman]

Your best guess is a very good guess. I am running win7 x64.

 

it seems that the issue is not in fact a bug but simly oversight on my part. I was creating a new disk over the same drive letter again. However, I cannot remove one of the old disks. The message is:

 

Flushing file buffers...
Locking volume...
I: Access is denied.

 

I have run it from an elevated prompt with the same results.

 

The extra drive that was listed in the disk driver window did dissapear. Is there  a reason that imdisk0 would not like getting removed?

[Olof Lagerkvist]

Could be some open handles somewhere. You could either try to find and close them, for example using SysInternals Process Explorer or similar, or just force dismount and removal:

 

imdisk -D -u 0

 

(Notice capital -D in this case.)

[iturtleman]

That did it! Thank you!