31 replies to this topic

[Verxion]

Hello there - I have had some emails back and forth with Olaf and he directed me to this forum.

Hopefully I can get some help because I think I am really close but I just can't seem to get this to go.

My goal: Make a ramdisk with the contents of c:\games\bfbc2_RAMDISK

My system: Windows 7 64 bit

My steps:

1. I had to turn off UAC before I was able to have ImDisk save .img files, so I did that as documented here: http://blogs.msdn.co.../20/763275.aspx
2. I went to the control panel and launched "ImDisk Virtual Disk Driver"
3. I chose "Mount New"
4. I set size to "Gigabytes" with a value of "7", then I clicked on "Ok"
5. I then formatted the drive it created as NTFS
6. I then copied the contents of c:\games\bfbc2_RAMDISK into the ramdisk
7. I clicked on "Save Image" and saved the ramdisk as c:\games\bfbc2.img
8. I then run the following command: "imdisk -a -t vm -o rw -m c:\games\bfbc2 -f c:\games\bfbc2.img" as administrator
9. If I now hit the "refresh" button in the ImDisk GUI, it shows up as "Virtual memory, from c:\games\bfbc2.img size 7gb read/write".
10. If I now double click on c:\games\bfbc2 (which was empty before I did all of this), I get the following message: "C:\games\bfbc2 is not accessible. The volume does not contain a recognized file system. Please make sure that all required file system drivers are loaded and that the volume is not corrupted"

If I reboot the computer into the OSX operating system, I can actually open the c:\games\bfbc2.img image and all the contents look perfectly fine to me.

Can anyone help?

-Verxion

[Verxion]

Is it possible that ImDisk isn't using the correct offset? I see a lot of posts on the internet about using 32256 as the offset (ie, the -b parameter to ImDisk). Does ImDisk not know how to determine the correct offset?

-Verxion

[was_JFX]

There seems to be serious bug!

Copying an existing image to RAM: --> Result broken file system
Creating an image in RAM --> No Problem
Save such an image --> Result broken file system

However I was able to recover a file with WinHex. The difference to original file was an additional first Byte and a missing last Byte.

So the hole content of this file was move 1 Byte to far. Hope this helps anyway.

[Verxion]

Can you tell me how to create an image in RAM since this apparently doesn't have a bug?

Thanks,

-Verxion

[was_JFX]

Can you tell me how to create an image in RAM since this apparently doesn't have a bug?

Use the control panel applet.
Create a new virtual disk, but do not enter an filename.

[Olof Lagerkvist]

There seems to be serious bug!

Copying an existing image to RAM: --> Result broken file system
Creating an image in RAM --> No Problem
Save such an image --> Result broken file system

However I was able to recover a file with WinHex. The difference to original file was an additional first Byte and a missing last Byte.

So the hole content of this file was move 1 Byte to far. Hope this helps anyway.

This was interesting to hear. If that is a reproducible problem it could be tracked down to what it is that causes this and fixed. The only fishy thing is that it seems to work for most users. I have never seen that myself and XIII did not have any such problems a few days ago either.

Any clues how to reproduce this?

[Verxion]

Well that doesn't work because it only allows me to make a drive letter. I need the ramdisk to be mounted at c:\games\bfbc2 and NOT as a full drive letter...

Hopefully Olaf can fix this soon.

-Verxion

[Verxion]

This was interesting to hear. If that is a reproducible problem it could be tracked down to what it is that causes this and fixed. The only fishy thing is that it seems to work for most users. I have never seen that myself and XIII did not have any such problems a few days ago either.

Any clues how to reproduce this?

I get it every SINGLE time I follow the process steps I gave you in the first post in this thread. I have made probably 20 .img files and they all fail to be recognized by windows when I mount them with ImDisk.

I'd say try just creating a 7gb image, copy some files in, and you should see the same result.

-Verxion

[Wonko the Sane]

Well that doesn't work because it only allows me to make a drive letter. I need the ramdisk to be mounted at c:\games\bfbc2 and NOT as a full drive letter...

Hopefully Olaf can fix this soon.

Well, you can de-assign the drive letter and mount it to a folder, don't you?

http://ss64.com/nt/mountvol.html



Wonko

[Verxion]

Well, you can de-assign the drive letter and mount it to a folder, don't you?

http://ss64.com/nt/mountvol.html



Wonko

That would be nice except that the drive doesn't even show up. It lists the possible values for VolumeName, and the ImDisk drive is completely missing.

-Verxion

[Wonko the Sane]

That would be nice except that the drive doesn't even show up. It lists the possible values for VolumeName, and the ImDisk drive is completely missing.

Hmm, you are right.

Catch 22:
http://www.boot-land...?showtopic=9962

I thought that a volume handle would be created anyway.

Have you tried checking (instead of mountvol) with vlm part of the dsfok package:
http://members.ozema...eezip/freeware/

Or with Olof's devioctl/dosdev?:
http://www.ltr-data.se/opencode.html

Wonko

[Verxion]

Hmm, you are right.

Catch 22:
http://www.boot-land...?showtopic=9962

I thought that a volume handle would be created anyway.

Have you tried checking (instead of mountvol) with vlm part of the dsfok package:
http://members.ozema...eezip/freeware/

Or with Olof's devioctl/dosdev?:
http://www.ltr-data.se/opencode.html

Wonko

I just tried them both - neither one could see the RAMDISK.

-Verxion

[TheK]

There seems to be serious bug!

Copying an existing image to RAM: --> Result broken file system
Creating an image in RAM --> No Problem
Save such an image --> Result broken file system

However I was able to recover a file with WinHex. The difference to original file was an additional first Byte and a missing last Byte.

So the hole content of this file was move 1 Byte to far. Hope this helps anyway.

I already posted this bug one year ago : http://www.boot-land...?showtopic=7435

I always thought I'm the only one having this problem. Now I'm glad to see I'm not

[Wonko the Sane]

Well, let's hope that the issue is reproduceable by Olof and fixable.

Too bad we didn't find a temporary workaround.



Wonko

[was_JFX]

@Olof
Try this

Create Image

imdisk -a -m I: -f D:\512MB.IMG -s 512M -p "/fs:ntfs /q /c /v:RAMDISK /y"

imdisk -d -m I:

Copy Image to RAM

imdisk -a -m I: -f D:\512MB.IMG -t vm

Byte at adress F379FFF got lost on the 512 MB Image inside RAM .

It's a different adress by other image size. See [attachment=10603:Imdisk.7z].



BTW: Minor issue

imdisk -a -m I: -f D:\512MB.IMG -t vm

Show done and process close but copying not done at this time.
So it's not possible to get correct exit code.

[Olof Lagerkvist]

I get it every SINGLE time I follow the process steps I gave you in the first post in this thread. I have made probably 20 .img files and they all fail to be recognized by windows when I mount them with ImDisk.

I'd say try just creating a 7gb image, copy some files in, and you should see the same result.

Yes, I see now what is happening. Every time this has been reported I have for some reason assumed that it has something to do with loading the image file into RAM, but that is clearly not the case. The problem is [b}saving[/b] the image. Thanks JFX for explanation. We can also assume that the same problem was actually reported by jaclaz here.

Now, the problem seems to be that modern versions of Windows filesystem drivers have some limitations when you try to ask them to dump volume raw data to an image file. You simply do not get the complete image. The logic behind this should be that the filesystem driver only gives you the data it uses, that is, if the filesystem structure does not use the entire underlying volume, you do not get the entire volume. That should be fine as long as you create a disk the same size as the original when you load the image later. But the problem is that if you get a smaller image file, the size will be different and the auto-detected disk "geometry" will be somewhat different causing some structures to fail within the filesystem structure. It seems to happen both for NTFS and FAT32.

There seems to be no problem if you manually adjust the size of the image file to the expected disk size later. That is after saving the image file, use for example my chsize32 tool to adjust the file size, for example if the image file size is supposed to be 7 GB:

chsize32 c:\ramdisk.img 7G

I could add this logic to the feature for saving image files in ImDisk Control Panel applet and it will then also work when right-clicking a disk and using the menu option for saving image. But it could be dangerous to change rawcopy this way because rawcopy is used for a lot more things in the world than saving disk images so I would say that something else has to be added in that case.

The reason I have not seen this problem myself is, as I mentioned, that I have thought that the problem has to do with loading the image file later, and that I personally always skip the "imaging" step when creating RAM disks this way. I virtually always create the image file in place, format it, dismount it and later use it to create RAM disks. Therefore I miss potential problems with the imaging step.

C:\test>imdisk -a -s 100M -f c:\test\test.img -m #:

Creating device...

Created device 0: E: -> c:\test\test.img

Notifying applications...

Done.



C:\test>format e: /fs:ntfs /q /y

Filsystemet är av typen RAW.

Nytt filsystem är av typen NTFS.

Snabbformaterar 100 MB

Skapar strukturer för filsystemet.

Formateringen är klar.

	 100,0 MB diskutrymme totalt.

	  97,8 MB är ledigt.



C:\test>copy c:\Windows\write.exe e:\

		1 fil(er) kopierad(e).



C:\test>imdisk -d -m E:

Notifying applications...

Flushing file buffers...

Locking volume...

Dismounting filesystem...

Removing device...

Removing mountpoint...

Done.



C:\test>md c:\test\test



C:\test>imdisk -a -t vm -f c:\test\test.img -m c:\test\test

Creating device...

Created device 0: c:\test\test -> c:\test\test.img

Done.



C:\test>dir c:\test\test

 Volymen i enhet C har ingen etikett.

 Volymens serienummer är 982F-0763



 Innehåll i katalogen c:\test\test



2009-07-14  02:14			 9 216 write.exe

			   1 fil(er)			   9 216 byte

			   0 katalog(er)	  90 443 776 byte ledigt



C:\test>imdisk -d -m c:\test\test

Flushing file buffers...

Locking volume...

Dismounting filesystem...

Removing device...

Removing mountpoint...

Done.

(Sorry for the Swedish Windows messages, this was on one of my test machines.)

In this case there is no image saving involved. The newly created image file is used in-place.

[Olof Lagerkvist]

I just tried them both - neither one could see the RAMDISK.

ImDisk does not interact with Volume Mount Manager so the mountvol command is like you have seen not useful in this case.

Instead you can use my dosdev or junc tools for manually creating drive letters and directory mount points for ImDisk drives.

dosdev -r R: \Device\ImDisk0

This creates drive letter R: for first ImDisk drive.

junc c:\ramdisk \Device\ImDisk0\

This creates a junction at c:\ramdisk that points to first ImDisk drive.

If these do not work there is something wrong with the ImDisk drive.

[TheK]

Yes, I see now what is happening. Every time this has been reported I have for some reason assumed that it has something to do with loading the image file into RAM, but that is clearly not the case. The problem is [b}saving[/b] the image. Thanks JFX for explanation. We can also assume that the same problem was actually reported by jaclaz here.

Saving the image doesn't seem to be the only problem...

c:\>imdisk -a -f y:\XPRAM_1.img -b auto -m #:

Creating device...

Created device 0: H: -> y:\XPRAM_1.img

Notifying applications...

Done.



c:\>imdisk -l -m h:

H: = \??\y:\XPRAM_1.img

Size: 756693504 bytes (721.6 MB), File Type Virtual Disk, HDD, Modified.



c:\>chkdsk h:

Der Typ des Dateisystems ist NTFS.

Die Volumebezeichnung lautet XPRAM_1.



WARNUNG! Der Parameter F wurde nicht angegeben.

CHKDSK wird im schreibgeschützten Modus ausgeführt.



CHKDSK überprüft Dateien (Phase 1 von 3)...

Dateiüberprüfung beendet.

CHKDSK überprüft Indizes (Phase 2 von 3)...

Indexüberprüfung beendet.

CHKDSK überprüft Sicherheitsbeschreibungen (Phase 3 von 3)...

Überprüfung der Sicherheitsbeschreibungen beendet.



	738958 KB Speicherplatz auf dem Datenträger insgesamt

	371039 KB in 5846 Dateien

	  1676 KB in 590 Indizes

		 0 KB in fehlerhaften Sektoren

	 12765 KB vom System benutzt

	  5744 KB von der Protokolldatei belegt

	353478 KB auf dem Datenträger verfügbar



	  1024 Bytes in jeder Zuordnungseinheit

	738958 Zuordnungseinheiten auf dem Datenträger insgesamt

	353478 Zuordnungseinheiten auf dem Datenträger verfügbar



c:\>imdisk -d -m h:

Flushing file buffers...

Locking volume...

Dismounting filesystem...

Removing device...

Removing mountpoint...

Done.



c:\>imdisk -a -f y:\XPRAM_1.img -b auto -m #: -t vm

Creating device...

Created device 0: H: -> y:\XPRAM_1.img

Notifying applications...

Done.



c:\>imdisk -l -m h:

H: = \??\y:\XPRAM_1.img

Size: 756693504 bytes (721.6 MB), Virtual Memory Disk, HDD, Modified.



c:\>chkdsk h:

Der Typ des Dateisystems ist NTFS.

Die Volumebezeichnung lautet XPRAM_1.



WARNUNG! Der Parameter F wurde nicht angegeben.

CHKDSK wird im schreibgeschützten Modus ausgeführt.



CHKDSK überprüft Dateien (Phase 1 von 3)...

Dateiüberprüfung beendet.

CHKDSK überprüft Indizes (Phase 2 von 3)...

Fehler im Index $SDH der Datei 9 werden berichtigt.

Fehler im Index $SDH der Datei 9 werden berichtigt.

Fehler im Index $SII der Datei 9 werden berichtigt.

Fehler im Index $SII der Datei 9 werden berichtigt.

Indexüberprüfung beendet.



Fehler gefunden. CHKDSK kann im schreibgeschützten Modus nicht

fortgesetzt werden.



c:\>

I loaded the same image once with and once without the -t vm swicht.
Without the t -vm switch everything is fine. However when it is loaded to RAM chkdsk finds some errors!

Sorry for the german chkdsk output. 'Fehler' means 'Error'.

Btw, this only happens to me with large image files (200-300 MB and larger).

[Olof Lagerkvist]

Saving the image doesn't seem to be the only problem...

I loaded the same image once with and once without the -t vm swicht.
Without the t -vm switch everything is fine. However when it is loaded to RAM chkdsk finds some errors!

Btw, this only happens to me with large image files (200-300 MB and larger).

This seems to be another issue. The only times I seem to be able to reproduce it is when the RAM disk size is close to amount of free memory. In that case space for the image can be allocated in memory, the image file contents copied to that memory area but it will later fail now and then when various buffers are needed and cannot be allocated, both in ntfs.sys and imdisk.sys.

I see in the debugger that on a chkdsk run on a close-to-the-limits RAM disk there are quite a few such memory allocation errors in different drivers and it means that chkdsk sees read errors in the filesystem structures when the filesystem driver cannot complete the read requests chkdsk sends.

There could of course be other problems behind what you have seen, but this is the only case I have found so far.

[Verxion]

There seems to be no problem if you manually adjust the size of the image file to the expected disk size later. That is after saving the image file, use for example my chsize32 tool to adjust the file size, for example if the image file size is supposed to be 7 GB:

chsize32 c:\ramdisk.img 7G

FYI, I tried this, and I do see the size change.

I made a 6500M .img file, copied my data into it and it was sized at 6,815,739,904 bytes. I then ran "chsize32 c:\games\bfbc2.img 6500M" and it was then sized at 6,815,744,000. At this point, I got excited hoping it might finally work!

I then mounted the image with my usual:

imdisk -a -t vm -o rw -m c:\games\bfbc2 -f c:\games\bfbc2.img

Then double clicking on bfbc2 gives me:

"C:\games\bfbc2 is not accessible.

The disk structure is corrupted and unreadable."



-Verxion

[was_JFX]

I would say it's the same problem:

Loading an existing image (over 300mb) to RAM and
Saving an Image (over 300mb) from RAM to file.

In both cases there goes something missing.

[Olof Lagerkvist]

I would say it's the same problem:

Loading an existing image (over 300mb) to RAM and
Saving an Image (over 300mb) from RAM to file.

In both cases there goes something missing.

Well, it looks reasonably obvious in a debugger with full debug output from imdisk.sys and checked ntfs.sys that it is not caused by the same problem, they just happen to look similar.

The problem with saving images happens when imaging any disk drive, not only ImDisk drives and it also happens with any small test program that just reads volume raw data off a volume. The problem with loading images is on the other hand easy to follow as a chain of failing memory allocations in different drivers when loading large images as RAM disks.

[Olof Lagerkvist]

FYI, I tried this, and I do see the size change.

I made a 6500M .img file, copied my data into it and it was sized at 6,815,739,904 bytes. I then ran "chsize32 c:\games\bfbc2.img 6500M" and it was then sized at 6,815,744,000. At this point, I got excited hoping it might finally work!

I then mounted the image with my usual:

imdisk -a -t vm -o rw -m c:\games\bfbc2 -f c:\games\bfbc2.img

Then double clicking on bfbc2 gives me:

"C:\games\bfbc2 is not accessible.

The disk structure is corrupted and unreadable."



-Verxion

If you try with smaller RAM disks, does it work then?

How much RAM do you have in your computer?

[Verxion]

[quote name='Olof Lagerkvist' post='93356' date='Mar 5 2010, 07:53 AM']

cd c:\games\imdisk -a -t vm -o rw -s 6500M -u 0 -m G: -p "/fs:ntfs /q /y"junc c:\games\bfbc2 \Device\ImDisk0\robocopy c:\games\bfbc2_RAMDISK c:\games\bfbc2 /E

THIS IS AWESOME! :whistling:I would PREFER to load it from an .img file instead of having to do this copy every time, but as long as it works, I'm a VERY happy camper!

-Verxion

-Verxion

[Verxion]

If you try with smaller RAM disks, does it work then?

How much RAM do you have in your computer?

I've got 16gb of RAM, and I get this failure even if I do it immediately after bootup.

-Verxion