Jump to content











Photo
- - - - -

Unable to unmount RAM disk via SYSTEM user.

unmount

  • Please log in to reply
5 replies to this topic

#1 s.kunal13

s.kunal13
  • Members
  • 4 posts
  •  
    India

Posted A week ago

Hi,

 

I am evaluating the latest version of ImDisk (Imdisk.sys version 2.0.9.64). I use windows system() api to execute Imdisk commands from my service which runs as SYSTEM user.

I create a new RAM disk during my service start and delete the disk while stopping the service. Service sends the following commands:

1) RAM disk create: 

imdisk -a -s 100m -p "/fs:ntfs /q /y /v:mvram" -m X:

 

2) RAM disk delete:

imdisk -d -m X:

 

The service cannot delete the RAM disk. Also, when I search for open handles on X: in process explorer, I get following :

File         X:\$Extend\$RmMetadata\$TxfLog\$TxfLogContainer00000000000000000001

File         X:\$Extend\$RmMetadata\$TxfLog\$TxfLog.blf

File         X:\$Extend\$RmMetadata\$TxfLog\$TxfLogContainer00000000000000000002

File         X:\$Extend\$RmMetadata\$Txf

 

However, if I execute the command "imdisk -d -m X:" in cmd (Administrator user) it successfully removes the RAM disk. 

 

Is this a known issue in ImDisk while running as a SYSTEM user?

 

Thanks,

Kunal



#2 v77

v77

    Silver Member

  • Team Reboot
  • 518 posts
  •  
    France

Posted A week ago

It's not a privilege issue. If there are open handles, the volume cannot be locked and therefore it will not be unmounted with the -d switch. If you want to bypass that, use -D instead.

Note that a simple window of Explorer (not open on the volume) is enough to create handles on the volume.



#3 s.kunal13

s.kunal13
  • Members
  • 4 posts
  •  
    India

Posted A week ago

It's not a privilege issue. If there are open handles, the volume cannot be locked and therefore it will not be unmounted with the -d switch. If you want to bypass that, use -D instead.

Note that a simple window of Explorer (not open on the volume) is enough to create handles on the volume.

Thanks for the reply.

I did some more experiment on this. Instead of executing Imdisk commands using system() API, I created a new process (using CreateProcessAsUser()) for "cmd.exe" with administrator privileges and invoked the same Imdisk command (imdisk -d -m X:). This successfully unmounted the drive.

These behaviors are very consistent which makes me believe that it is a privilege issue.



#4 s.kunal13

s.kunal13
  • Members
  • 4 posts
  •  
    India

Posted A week ago

Moreover, I don't think its safe to force unmount the drive when there are open file handles, as it might cause failures elsewhere. When I search for these handles in process explorer, it says that these belong to "system" process with PID 4.



#5 s.kunal13

s.kunal13
  • Members
  • 4 posts
  •  
    India

Posted A week ago

I also found this posted by Olof some years back :

 

http://reboot.pro/to...-virtual-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. 

 

 

Is this related to the issue I am facing?

 

THanks

Kunal



#6 v77

v77

    Silver Member

  • Team Reboot
  • 518 posts
  •  
    France

Posted A week ago

The System acccount is supposed to provide even more privileges than an standard elevated account. So I would say that the system() function does much more than just starting a process...

Forcing a dismount is not a big issue as long as all your files are saved.
Dismounting without administrative privileges is rather dangerous, because the write caches cannot be flushed. Therefore, if a file is written just before the volume is dismounted, its content can be lost. Moreover, some resources are not freed.







Also tagged with one or more of these keywords: unmount

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users