Hello, First thanks for imdisk, that's a very useful and powerful tool !
I have a problem when i try to stop then start the imdisk service after a first RAM drive creation.
When I execute the following sequence: 1- Start imdisk service, 2- Stop imdisk service, 3- Restart imdisk service 4- -> OK. I think this is because no RAM drive has been created. 5- Creation of a RAM drive. 6- -> Successfully created 7- Deletion of the RAM drive 8- -> Successfully deleted 9- Stop imdisk service, 10- Start imdisk service 11- -> the driver can’t be started
See the following trace (on Windows 7 64 bits):
C:imdisk-1.4.2>imdiskinst.exe -y
C:imdisk-1.4.2>sc start imdisk
SERVICE_NAME: imdisk
TYPE : 1 KERNEL_DRIVER
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 0
FLAGS :
C:imdisk-1.4.2>sc stop imdisk
SERVICE_NAME: imdisk
TYPE : 1 KERNEL_DRIVER
STATE : 1 STOPPED
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
C:imdisk-1.4.2>sc start imdisk
SERVICE_NAME: imdisk
TYPE : 1 KERNEL_DRIVER
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 0
FLAGS :
C:imdisk-1.4.2>imdisk.exe -a -s 1000000000 -m "#:" -p "/fs:ntfs /q /y"
Creating device...
Created device 0: E: -> VM image
Formatting disk...
The type of the file system is RAW.
The new file system is NTFS.
QuickFormatting 953M
Creating file system structures.
Format complete.
953.7 MB total disk space.
946.7 MB are available.
Notifying applications...
Done.
C:imdisk-1.4.2>imdisk.exe -d -u 0
Flushing file buffers...
Locking volume...
Dismounting filesystem...
Removing device...
Removing mountpoint...
Done.
C:imdisk-1.4.2>imdisk -l
No virtual disks.
C:imdisk-1.4.2>sc stop imdisk
SERVICE_NAME: imdisk
TYPE : 1 KERNEL_DRIVER
STATE : 1 STOPPED
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
C:imdisk-1.4.2>sc start imdisk
[SC] StartService FAILED 2:
The system cannot find the file specified.
C:imdisk-1.4.2>
Did i miss something ?
Pltf
Edited by supportPltf, 14 October 2011 - 03:31 PM.
I have seen this sometimes too. Mostly on Vista, Server 2008 and 7, but occasionally also on Server 2003. It seems it could happen to any legacy driver when you unload and load it a couple of times. I have no idea why. I have got a few reports about this from other developers as well (mostly developers see this, other users will not often unload and load drivers in this way).
Location:The Outside of the Asylum (gate is closed)
Italy
Posted 14 October 2011 - 06:09 PM
@Olof Just for the record (and possibly NOT related to this particular issue ) there is a known issue with VDK, which can be loaded/unloaded/installed/uninstalled/stopped and started all the times you want in Windows 2000 BUT often hangs in XP when attempting to do the same. A "shot in the dark" at the time was a connection with Volume Shadow Copy Service: http://reboot.pro/9195/ As fxscrpt correctly reported there, moving the actual .sys often works, but we don't have AFAIK/AFAICR a "real" explanation for this behaviour.
Thanks for this information. Yes, sometimes it works to move the .sys file or register a new service with the path of the existing .sys file like sc create imdisk2 ... or similar.
I came to think now about that someone suggested a while ago to check Device Manager and see if there is a (possibly hidden) non-PnP device left for an old version of the driver. In that case it could be worth it trying to delete it first and after that the driver could be registered and started again using the original same driver name and same location of the .sys file. But I have not tested that particular solution myself. But could be worth testing. If it works it will probably work using the "devcon" tool that provides command line access to what could be done with Device Manager and a lot more.
Have you tried not only stopping, but also deleting the service and then re-creating?
That's what I do, and I have done this over 100x without a restart just fine on Windows 7 x64. The only times when it fails is if I don't properly clean up all the existing virtual drives before stopping the service.
[SC]StartService FAILED 2: The system cannot find the file specified.
When you get this error, have you tried looking at the path to the binary of the service, just to be sure that it is what it should be?
Also, is this the case only for RAM drives, or for file-backed virtual drives as well?
Have you tried not only stopping, but also deleting the service and then re-creating?
In my case I have tried that as well, but it would not help. I can create a new driver with a different name though, or sometimes move the .sys file. So I suspect it has something to do with cached device information or something.
That's what I do, and I have done this over 100x without a restart just fine on Windows 7 x64. The only times when it fails is if I don't properly clean up all the existing virtual drives before stopping the service.
That's another matter. In case everything is not properly cleaned up it is actually the stopping of the driver that will fail and leave it in a state where it cannot be controlled in any way. But that is not what is discussed in this thread.
[SC]StartService FAILED 2: The system cannot find the file specified.
When you get this error, have you tried looking at the path to the binary of the service, just to be sure that it is what it should be?
Also, is this the case only for RAM drives, or for file-backed virtual drives as well?
In my case, yes, the driver binary is definitely there. Sometimes it helps creating a new driver pointing at the same binary and the new driver will start. But it is strange.
But anyway, I have also done this a few hundred times on various Windows versions without any problems and then suddenly it appears again. It seems more frequent on recent versions of Windows and it does not seem to make any difference what kind of virtual disks have been created.
... I came to think now about that someone suggested a while ago to check Device Manager and see if there is a (possibly hidden) non-PnP device left for an old version of the driver. ...
I tried checking the Device Manager but did'nt find any left device.
Have you tried not only stopping, but also deleting the service and then re-creating? ...
I also tried to stop / delete service / re-create service, it doesn't help (as said Olof Lagerkvist).
... The only times when it fails is if I don't properly clean up all the existing virtual drives before stopping the service. ...
I also confirm that i successfully delete existing device(s) before stopping imdisk service, and the driver file is present on filesystem.
If i rename the driver file and create an new service with different name, it starts successfully… I also add some traces in different driver functions and i see that when the "service start" fails, the SC manager doesn't even call the DriverEntry() function. Maybe the driver misses cleaning some resources during the unload() function or we may need to implement IRP_MJ_CLEANUP? I found this link : http://support.micro....com/kb/120170. It is interesting as the issue occurs only if a RamDrive is created. You seems to encounter this problem randomly, for me, it's systematic once i have created a RAM drive.
If i rename the driver file and create an new service with different name, it starts successfully… I also add some traces in different driver functions and i see that when the "service start" fails, the SC manager doesn't even call the DriverEntry() function. Maybe the driver misses cleaning some resources during the unload() function or we may need to implement IRP_MJ_CLEANUP? I found this link : http://support.micro....com/kb/120170. It is interesting as the issue occurs only if a RamDrive is created. You seems to encounter this problem randomly, for me, it's systematic once i have created a RAM drive.
We could of course give IRP_MJ_CLEANUP a try, but I doubt it. If there is some IRP cleanup that needs to be done, I cannot understand why it would differ between RAM disks and file-backed disks. Generally, you can check i IRP_MJ_CLEANUP should have been handled and should have done something, because if you add traces you will see that IRP_MJ_CLOSE would not get called in that case. But if IRP_MJ_CLOSE gets called, there is nothing IRP_MJ_CLEANUP could have done that would have made any practical difference to anything.
I used Windows driver verifier and I saw that the driver is correctly loaded and unloaded only if I stop/start imdisk. Once I create and delete one RAM drive, the driver can’t be unloaded anymore, and some memory pools remains allocated. Here is a summary of executed commands. (Full script and results are below)
First I configure Windows driver verifier (reboot needed):
In « full result files », we can see that there are remaining pools in both case (RAM drive and file-backed disk), and driver cannot be unloaded anymore.
I used Windows driver verifier and I saw that the driver is correctly loaded and unloaded only if I stop/start imdisk. Once I create and delete one RAM drive, the driver can’t be unloaded anymore, and some memory pools remains allocated. Here is a summary of executed commands. (Full script and results are below)
Which pool allocations remains allocated? All I can see in your verifier outputs are:
You are right. I think there is no memory allocation issue. Sorry, I was looking at "peak" pools which get back to 0 when we stop successfully, but stay non-zero when we get the issue (driver still in memory).
The problem seems to be that the driver is not successfully unloaded:
Name: imdisk.sys, loads: 2, unloads: 1
Maybe we should listen some IRP to accept to be unloaded by OS.
After you do imdisk -d -u 0, could you also do imdisk -l and share your output (to be sure that you really did remove the virtual drive before stopping the service)?
Also, try creating the virtual drive without a drive letter mount point (just skip the -m flag) and see if you still have the problem.
After you do imdisk -d -u 0, could you also do imdisk -l and share your output (to be sure that you really did remove the virtual drive before stopping the service)?
Also, try creating the virtual drive without a drive letter mount point (just skip the -m flag) and see if you still have the problem.
I think you could have a point here. I did not notice that OP actually uses -m parameter when creating but just -u parameter when deleting the virtual disk. There is a difference between -m and -u parameters when deleting disks because without the -m parameter, there will be no call to DefineDosDevice(DDD_REMOVE_DEFINITION, ...) in user mode. This may leave a symbolic link to a device object that belongs to imdisk.sys. This is not directly related to what imdisk.sys driver does, but there could be something strange going on here anyway.
If it makes any difference, it would be an easy change to the device remove routine to query drive letter from the driver and then make sure it is deleted.
After you do imdisk -d -u 0, could you also do imdisk -l and share your output (to be sure that you really did remove the virtual drive before stopping the service)?
Actually, there is no imdisk device left in “imdisk –l” when we get the issue: Test script (Suppose you already active windows verifier, Cf post #11):
There is a difference between -m and -u parameters when deleting disks because without the -m parameter, there will be no call to DefineDosDevice(DDD_REMOVE_DEFINITION, ...) in user mode. This may leave a symbolic link to a device object that belongs to imdisk.sys. This is not directly related to what imdisk.sys driver does, but there could be something strange going on here anyway.
If it makes any difference, it would be an easy change to the device remove routine to query drive letter from the driver and then make sure it is deleted.
Unfortunately, deleting the RAM drive using –m parameter doesn’t solve the problem, I still can’t unload the driver successfully, but we get closer to the problem ! Test script (Suppose you already active windows verifier, Cf post #11):
Could you try and see what happens if you mount your RAM disk to a subdirectory instead of a drive letter?
imdisk.exe -a -s 1000000000 -m C:\ramdisk -p "/fs:ntfs /q /y"
...and...
imdisk.exe -d -m C:\ramdisk
and then compare that to what happens if you dismount using
imdisk.exe -d -u 0
(Subdirectory needs to be on an NTFS volume and needs to be empty.)
In this case there is no drive letter symbolic link objects created but there will be object pointers left in the filesystem in the second case. Would be interesting to see if this makes any difference.
It seems that the format operation is part of the problem, see my results:
1 - Trying to format the RAM drive (NTFS) once mounted using dosdev (Fail):
Spoiler
C:\>mkdir C:\ramdisk
C:\>imdisk.exe -a -s 1000000000 -m C:\ramdisk
The ImDisk Virtual Disk Driver was loaded into the kernel.
Creating device...
Created device 0: C:\ramdisk -> VM image
Done.
C:\>dosdev -r R: \Device\ImDisk0
R:: The operation completed successfully.
C:\>format R: /fs:ntfs /q /y
The type of the file system is RAW.
The new file system is NTFS.
QuickFormatting 953M
Creating file system structures.
Format complete.
953.7 MB total disk space.
946.7 MB are available.
C:\>dosdev -d R:
R:: The operation completed successfully.
C:\>imdisk.exe -d -u 0
Flushing file buffers...
Locking volume...
Dismounting filesystem...
Removing device...
Done.
C:\>
C:\>sc stop imdisk
SERVICE_NAME: imdisk
TYPE : 1 KERNEL_DRIVER
STATE : 1 STOPPED
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
C:\>sc start imdisk
[SC] StartService FAILED 2:
The system cannot find the file specified.
2 - Same test using FAT32 file system (Success):
Spoiler
C:\>mkdir C:\ramdisk
C:\>imdisk.exe -a -s 1000000000 -m C:\ramdisk
The ImDisk Virtual Disk Driver was loaded into the kernel.
Creating device...
Created device 0: C:\ramdisk -> VM image
Done.
C:\>dosdev -r R: \Device\ImDisk0
R:: The operation completed successfully.
C:\>format R: /fs:fat32 /q /y
The type of the file system is RAW.
The new file system is FAT32.
QuickFormatting 953M
Initializing the File Allocation Table (FAT)...
Format complete.
949.7 MB total disk space.
949.7 MB are available.
4,096 bytes in each allocation unit.
243,115 allocation units available on disk.
32 bits in each FAT entry.
Volume Serial Number is EC86-ADFC
C:\>dosdev -d R:
R:: The operation completed successfully.
C:\>imdisk.exe -d -u 0
Flushing file buffers...
Locking volume...
Dismounting filesystem...
Removing device...
Done.
C:\>sc stop imdisk
SERVICE_NAME: imdisk
TYPE : 1 KERNEL_DRIVER
STATE : 1 STOPPED
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
C:\>sc start imdisk
SERVICE_NAME: imdisk
TYPE : 1 KERNEL_DRIVER
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 0
FLAGS :
3 - And my initial test changing only filesytem type (Success):
Spoiler
C:\>sc start imdisk
SERVICE_NAME: imdisk
TYPE : 1 KERNEL_DRIVER
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 0
FLAGS :
C:\>imdisk.exe -a -s 1000000000 -m "#:" -p "/fs:fat32 /q /y"
The type of the file system is RAW.
The new file system is FAT32.
QuickFormatting 953M
Initializing the File Allocation Table (FAT)...
Format complete.
949.7 MB total disk space.
949.7 MB are available.
4,096 bytes in each allocation unit.
243,115 allocation units available on disk.
32 bits in each FAT entry.
Volume Serial Number is 8862-0BFB
Creating device...
Created device 0: G: -> VM image
Formatting disk...
Notifying applications...
Done.
C:\>imdisk.exe -d -u 0
Flushing file buffers...
Locking volume...
Dismounting filesystem...
Removing device...
Removing mountpoint...
Done.
C:\>sc stop imdisk
SERVICE_NAME: imdisk
TYPE : 1 KERNEL_DRIVER
STATE : 1 STOPPED
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
C:\>verifier /query
10/24/2011, 2:29:22 AM
Level: 00000FFB
RaiseIrqls: 0
AcquireSpinLocks: 0
SynchronizeExecutions: 0
AllocationsAttempted: 83855
AllocationsSucceeded: 83855
AllocationsSucceededSpecialPool: 83855
AllocationsWithNoTag: 3
AllocationsFailed: 0
AllocationsFailedDeliberately: 0
Trims: 1470
UnTrackedPool: 83852
Verified drivers:
Name: imdisk.sys, loads: 1, unloads: 1
CurrentPagedPoolAllocations: 0
CurrentNonPagedPoolAllocations: 0
PeakPagedPoolAllocations: 0
PeakNonPagedPoolAllocations: 0
PagedPoolUsageInBytes: 0
NonPagedPoolUsageInBytes: 0
PeakPagedPoolUsageInBytes: 0
PeakNonPagedPoolUsageInBytes: 0
C:\>sc start imdisk
SERVICE_NAME: imdisk
TYPE : 1 KERNEL_DRIVER
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 0
FLAGS :
It seems the ramdisk is sensitive to filesystem type previously used on its device to be correctly unloaded. Very surprising to me…
Location:The Outside of the Asylum (gate is closed)
Italy
Posted 24 October 2011 - 12:40 PM
It seems the ramdisk is sensitive to filesystem type previously used on its device to be correctly unloaded. Very surprising to me…
Pltf
This could be another hint towards VSS sevices (which maybe only "hook" NTFS formatted drives ) There are a few hints about this (not "direct/explicit" but possibly suggesting this): http://www.techsuppo...copy-90165.html http://kbase.gfi.com...p?id=KBID003548 Or anyway some other filesystem related running service that makes a distinction about filesystems used.
I think you cannot "exclude" a Volume form the service, as even the "exclude files" sounds like a sort of filter when actually doing the Shadow copy: http://www.mydigital...system-restore/ The only way is probably to disable (for testing purposes) the service alltogether but this may possibly create other problems -