33 replies to this topic

[Sophia]

I came across a very odd side-effect with ImDisk virtual drives...

Windows doesn't seem to use the autorun.inf file located on it, no matter what I try.

The very same autorun.inf file, which just customises the icon, when put onto a USB stick works perfectly fine.

I am using Windows 7 x64, and the behaviour is the same in ImDisk 1.3.1 and 1.4.0. I have UAC disabled and the file system on the virtual drive is FAT32 (not a CD image). I tried mounting the image as both fixed and removable drive, with no luck.

Is it just me doing something wrong, or is it the case for everyone? Could someone please check this and let me know if autorun.inf works for you, when it is located on a virtual drive?

[amalux]

I had issues with IMDisk as well and ended up using the free DVDFab Virtual Drive here: http://www.dvdfab.co...rtual-drive.htm

Works great in Win 7 x64 and autorun.inf is properly detected (icons and autorun).

I have been a big fan of IMDisk for years, hopefully the issues can be worked out (driver signing as well).

[Sophia]

Thank you for the suggestion, but unfortunately this is not quite what I was looking for.

I need to create a virtual drive which is writeable and uses FAT32/NTFS file system, and from a brief look at DVDFab it looks like it cannot do any of it.

I, personally, think that ImDisk is an amazing product and is definitely the best thing for my purpose I have come across.

I was merely trying to find out if the autorun.inf anomaly is my fault because I set up ImDisk or the TCP/IP proxy incorrectly, or is it maybe a bug stemming perhaps from a missing notification to Windows that a new drive has appeared.

[L A M A]

If the goal is to simply change the icons of imDisk drives that reside inside "computer" (aka formally My computer), is it not better to look for registry tweak or drive icon changing app? instead of autorun.inf?

I've chosen to disable shell service itself [windows button + R >> services.msc >> Shell Hardware Detection?] given the fact that viruses land on PC via USB sticks which uses autorun.inf to start EXEs and mess around.

[Wonko the Sane]

Disambiguation needed.
IMDISK is essentially a virtual filesystem driver (as opposed to a virtual DISK driver):
http://reboot.pro/11642/page__st__40
it is likely that the autorun.inf working is connected to the "device" (and not to the "filesystem").


Wonko

[sara - pmedia]

Is there a possibility that IMDISK will remember the mounted images when you shut down the computer?

[Olof Lagerkvist]

I have been a big fan of IMDisk for years, hopefully the issues can be worked out (driver signing as well).

ImDisk drivers have been signed with a trusted certificate since about a year ago.

Disambiguation needed.
IMDISK is essentially a virtual filesystem driver (as opposed to a virtual DISK driver):
http://reboot.pro/11642/page__st__40
it is likely that the autorun.inf working is connected to the "device" (and not to the "filesystem").

Well, it is not exactly correct to call it a virtual filesystem driver either. Filesystem drivers are other things that are loaded on top of disk drivers. Filesystem drivers can be physical like NTFS, FAT etc, virtual like NPFS, Mailslot etc or redirectors like network file sharing drivers etc.

ImDisk is a virtual disk driver that just does not handle partition tables and creates non-partitionable disk devices, that is, without a PhysicalDriveN object etc. So, pretty much like a Floppy Disk driver, just handling larger volumes than ordinary floppy drivers.

Also, ImDisk does not interact with Volume Mount Manager and instead handles drive letters itself, which is getting more and more complicated for each new Windows version. This is the reason why users cannot use mountvol etc to assign drive letters and mount points to ImDisk drives while the same is possible for normal floppy drives. So, interaction with Volume Mount Manager has nothing to do with the type of disk driver or presence of PhysicalDriveX objects.

Many other virtual disk drivers are not implemented as disk drivers but instead as virtual SCSI miniport drivers. Such drivers need very little operating system interaction when drives are connected/disconnected because Windows will use the built-in disk.sys, floppy.sys, cdrom.sys etc drivers for the disks that the SCSI miniports presents for the operating system. Therefore such drivers get partition handling, PhysicalDriveN objects, interaction with Volume Mount Manger etc "for free".

Just to clarify Windows driver terminology.

For the actual problem discussed in this thread: I would think that is has to do with some missing DBT_DEVICEARRIVAL messages (with and without DBTF_MEDIA flag set). Such messages are sent by ImDisk but they do not always seem to work correctly. Explorer seems to auto-open them, but not auto-run them, which is somewhat odd. Could there be some difference if the virtual disk device is created as a "removable" device?

[pscEx]

Thanks for the good explanation, Olof!

Now I have a lot more back knowledge of your driver (which I use since long time).

Peter

[Sophia]

Thanks Olof for the technical insight into virtual disk driver terminology and options.

I have tried making it both a Fixed and a Removable disk, but the behaviour is still the same. I managed to reproduce the same problem by creating the virtual drive using ImDisk Control Panel Applet, that is without any TCP/IP proxy, so the problem should be with some missing notification or alike.

I compared the broadcasted messages when a ImDisk mounts a drive vs. inserting a USB stick. Both have the following message:

WM_DEVICECHANGE - DBT_DEVICEARRIVAL

However, when inserting a USB stick before and after the DBT_DEVICEARRIVAL message, I also see the DBT_DEVNODES_CHANGED. When I mount an ImDisk drive, this message is not there.

I am by no means an expert on this, but is this maybe the message that Windows "expects" in order to auto-run the contents of the drive?

One more question, Olof, if you don't mind:

What happens if ImDisk doesn't broadcast the DBT_DEVICEARRIVAL message? Will the drive just "appear" in My Computer, but Windows will not "realise" that it is there and not auto-open it, or will it not even appear in My Computer at all?

The reason I am asking this seemingly odd question is not just being curious what happens if you do not follow driver development guidelines.

I wonder if there is a way to make the drive available so that it is there when the user needs it later, but so that it does not auto-open in any way.

[Sophia]

Update:

I don't think my previous suggestion will make any difference. I tried the following:
1. Created an ISO image with the autorun.inf and icon.ico files.
2. Mounted the image with ImDisk as CDFS - same like FAT32, no icon, no autoplay
3. Mounted the image with Daemon Tools - icon OK, autoplay working

I tracked the messages with Spy++, however they look exactly the same for both:
<00001> 000C1244 S WM_DEVICECHANGE Event:DBT_DEVICEARRIVAL dwData:0015D730
<00002> 000C1244 R WM_DEVICECHANGE fComplete:True

Maybe the DBT_DEVICEARRIVAL notification is sent "too early", before the media is properly available, or something like that?

I actually quite like the fact that autoplay doesn't pop-up the moment when the drive is mounted (maybe we can keep it as an optional feature?), but I hope we'll eventually get it fixed so that it works correctly and I can get the icon and drive label customised using autorun.inf

[amalux]

ImDisk drivers have been signed with a trusted certificate since about a year ago.

Very sorry for that mis-information and thank you for the clarification. I had experienced some (minor) 'issues' with IMDisk in Win 7 x64 and attempting to track down a 64bit version, found this site (yours were not working at the time): http://oss.netfarm.it/win32/ It was the imdiskinst_multiarch that caused the driver signing rejection. Now that I have the latest version (1.4.1) from your link, I still have the minor issues but drivers are accepted.

I can give you more info on the minor issues if wanted, they're not things I would normally care too much about but when the OP mentioned the autorun thing it sparked my response. I still get no autorun (or icon) detection with latest version IMDisk as is normal with (other) virtual disk drives (but perhaps this is by design).



I also get 'cannot lock the device...' when attempting to unmount image even though nothing is accessed or changed in the image (with or without 'Removable media' checked); a restart is required to clear up.

[Sophia]

amalux, thanks for confirming that I am not alone having both of these issues.

As for the problem with dismounting, I always use -D to force dismount, but it would be great to get this fixed eventually too.

[Olof Lagerkvist]

amalux, thanks for confirming that I am not alone having both of these issues.

As for the problem with dismounting, I always use -D to force dismount, but it would be great to get this fixed eventually too.

Like discussed before, I would not like to call a solution to this a "fix". Windows does not allow dismounting of a filesystem without administrative privileges. Therefore, the "fix" is to workaround the security model using calls to a separate service or similar. I call something a "fix" if it fixes something that is broken. This is not broken, Windows is intended to work this way...

[Sophia]

Sorry Olof, I didn't mean to offend with all my bug reports

I fully agree with you that if dismounting of a file system requires administrative privileges, ImDisk should respect this Windows rule (even though I still think an optional workaround would be great).

However, I think there was a misunderstanding, perhaps due to my slightly too general wording. By "problem with dismounting" I was not referring to the UAC issues, but to something completely different:

If you mount a virtual drive and then without doing anything at all (on a clean Windows installation, with no additional software) try to dismount it normally, it will still tell you that the drive is in use, even though nothing should be using it. The only thing that works for me is forced dismount.

Going back to the original topic, although I have very little C experience, I had a look at the ImDisk source code (1.4.0, not sure if my copy is up to date) and I have a quick question:

PostMessage(HWND_BROADCAST, WM_DEVICECHANGE, DBT_DEVICEARRIVAL, (LPARAM)&dev_broadcast_volume);



dev_broadcast_volume.dbcv_flags = DBTF_MEDIA;



PostMessage(HWND_BROADCAST, WM_DEVICECHANGE, DBT_DEVICEARRIVAL, (LPARAM)&dev_broadcast_volume);

I think the first notification (DBT_DEVTYP_VOLUME) will actually be never broadcasted and instead the DBTF_MEDIA notification will be sent twice, because PostMessage is asynchronous and both calls use the same pointer.

Unfortunately, even re-broadcasting the DBT_DEVICEARRIVAL manually after the virtual drive has been opened has no effect on Windows processing autorun.inf file.

Do you have any ideas what might be causing this anomaly?

Is there anything I can do from my side to help out with this?

[Olof Lagerkvist]

Sorry Olof, I didn't mean to offend with all my bug reports

No problem!

If you mount a virtual drive and then without doing anything at all (on a clean Windows installation, with no additional software) try to dismount it normally, it will still tell you that the drive is in use, even though nothing should be using it. The only thing that works for me is forced dismount.

That sounds strange. Could you try for example Process Explorer (from SysInternals) and see which process or what is actually holding the device open? In Process Explorer search for "\Device\ImDisk0" or the drive letter you use for it.

I use it regularly on everything from Windows NT 4.0 to Windows 7 and the only times I have seen this have been when there is some special software installed that open and holds disk devices. Most of such problems where however solved when I changed the control program to broadcast DBT_QUERYDEVICEREMOVAL before attempting to dismount.

Going back to the original topic, although I have very little C experience, I had a look at the ImDisk source code (1.4.0, not sure if my copy is up to date) and I have a quick question:

I think the first notification (DBT_DEVTYP_VOLUME) will actually be never broadcasted and instead the DBTF_MEDIA notification will be sent twice, because PostMessage is asynchronous and both calls use the same pointer.

Interesting idea but no, it does not work that way. If it would use the buffer after function return the documentation would have been very clear about that because it would be extremely dangerous. The pointer the caller sends could point to a stack variable in the calling function and will be invalid and most probably contain something completely different very soon after the calling function have returned in that case.

Unfortunately, even re-broadcasting the DBT_DEVICEARRIVAL manually after the virtual drive has been opened has no effect on Windows processing autorun.inf file.

Do you have any ideas what might be causing this anomaly?

Is there anything I can do from my side to help out with this?

One thing I wonder is if I really send the correct device number in the broadcasted message. You see, up to a few versions ago I mistakenly sent device number plus one. So, if you mounted drive F: applications where notified that drive G: had arrived. I did not notice that until I happened to use a drive letter where there actually were a following drive present at my machine and where Windows popped up the root folder of the following drive...

But this means that there was some kind of at least half-way working autorun mechanism at that time and now there seem to be none at all. Wonder what I happened to change apart from the drive number.

..and thanks a lot for helping this project with all your time and effort to investigate what it really does, why and what it is supposed to do (and not do).

[Sophia]

Interesting idea but no, it does not work that way. If it would use the buffer after function return the documentation would have been very clear about that because it would be extremely dangerous. The pointer the caller sends could point to a stack variable in the calling function and will be invalid and most probably contain something completely different very soon after the calling function have returned in that case.

The way I had this idea is that I tried using PostMessage to broadcast the message from a Delphi application and the used Spy++ to monitor if it really gets broadcasted and it didn't, exactly for the reason you described - the pointer was to a stack variable. So I went to read the help and here's what I found:

If you send a message in the range below WM_USER to the asynchronous message functions (PostMessage, SendNotifyMessage, and SendMessageCallback), its message parameters cannot include pointers. Otherwise, the operation will fail. The functions will return before the receiving thread has had a chance to process the message and the sender will free the memory before it is used.

So I changed my code to SendMessage and then the messages were broadcasted correctly. I suspect I am missing something...

[Sophia]

That sounds strange. Could you try for example Process Explorer (from SysInternals) and see which process or what is actually holding the device open? In Process Explorer search for "\Device\ImDisk0" or the drive letter you use for it.

I tried exactly that and the only process that has a handle on the drive letter (in fact always two handles) is "explorer.exe". So as long as I have My Computer open, I cannot dismount the drive.

I also double checked and there are no open handles to "\Device\ImDisk" or anything similar.

Most of such problems where however solved when I changed the control program to broadcast DBT_QUERYDEVICEREMOVAL before attempting to dismount.

I am a bit confused why this would actually help. Doesn't the CLI (in ImDiskCliRemoveDevice) already send the DBT_QUERYDEVICEREMOVAL when a drive is dismounted?

[Olof Lagerkvist]

The way I had this idea is that I tried using PostMessage to broadcast the message from a Delphi application and the used Spy++ to monitor if it really gets broadcasted and it didn't, exactly for the reason you described - the pointer was to a stack variable. So I went to read the help and here's what I found:

If you send a message in the range below WM_USER to the asynchronous message functions (PostMessage, SendNotifyMessage, and SendMessageCallback), its message parameters cannot include pointers. Otherwise, the operation will fail. The functions will return before the receiving thread has had a chance to process the message and the sender will free the memory before it is used.

WM_DEVICECHANGE is not "below WM_USER" and should not be affected by the above. Also, ImDisk does not really use asynchronous message broadcasting, it uses SendMessageTimeout which is essentially like SendMessage but with a timeout.

So I changed my code to SendMessage and then the messages were broadcasted correctly. I suspect I am missing something...

Strange. Or something. I don't know what is happening.

[Olof Lagerkvist]

I tried exactly that and the only process that has a handle on the drive letter (in fact always two handles) is "explorer.exe". So as long as I have My Computer open, I cannot dismount the drive.

I also double checked and there are no open handles to "\Device\ImDisk" or anything similar.

Looks like it could be some shell extension living in the explorer.exe process then. It do not know exactly what it could be though.

I am a bit confused why this would actually help. Doesn't the CLI (in ImDiskCliRemoveDevice) already send the DBT_QUERYDEVICEREMOVAL when a drive is dismounted?

Yes it does nowadays but it did not that until a few versions ago. Since I added that I have never seen the problem myself and I also got many reports about that other users similar problems were solved with this change. That is the strange part.

This is an example of a problem that was reported solved with this change:
http://issues.tortoi...ils&task_id=188
So, that was in September 2007 and that was when I last time saw that problem myself.

Just to doublecheck, I tried it right now on Windows Server 2003, Vista and 7 and I don't see this problem.

[Sophia]

Also, ImDisk does not really use asynchronous message broadcasting, it uses SendMessageTimeout which is essentially like SendMessage but with a timeout.

From "cli\imdisk.c", approx. line 2050...

In 1.4.0:

puts("Notifying applications...");



	      dev_broadcast_volume.dbcv_unitmask =

		1 << (mount_point[0] - L&#39;A&#39;);



	      PostMessage(HWND_BROADCAST,

			  WM_DEVICECHANGE,

			  DBT_DEVICEARRIVAL,

			  (LPARAM)&dev_broadcast_volume);



	      dev_broadcast_volume.dbcv_flags = DBTF_MEDIA;



	      PostMessage(HWND_BROADCAST,

			  WM_DEVICECHANGE,

			  DBT_DEVICEARRIVAL,

			  (LPARAM)&dev_broadcast_volume);

In 1.3.1:

puts("Notifying applications...");



	      dev_broadcast_volume.dbcv_unitmask =

		1 << (mount_point[0] - L&#39;A&#39;);



	      SendMessageTimeout(HWND_BROADCAST,

				 WM_DEVICECHANGE,

				 DBT_DEVICEARRIVAL,

				 (LPARAM)&dev_broadcast_volume,

				 SMTO_BLOCK,

				 2000,

				 &dwp);



	      dev_broadcast_volume.dbcv_flags = DBTF_MEDIA;



	      SendMessageTimeout(HWND_BROADCAST,

				 WM_DEVICECHANGE,

				 DBT_DEVICEARRIVAL,

				 (LPARAM)&dev_broadcast_volume,

				 SMTO_BLOCK,

				 2000,

				 &dwp);

So in 1.3.1 there was nothing wrong with SendMessageTimeout, but my concern was regarding the change in 1.4.0 from SendMessageTimeout to PostMessage.

Update:

WM_DEVICECHANGE is not "below WM_USER" and should not be affected by the above

Just out of curiosity I double checked:

WM_DEVICECHANGE = 537
WM_USER = 1024

Not that I think it makes really any difference

Edited by Sophia, 06 April 2011 - 07:05 PM.

[Sophia]

Looks like it could be some shell extension living in the explorer.exe process then.

Hm, great idea, haven't thought of it, and given that it works for you I suppose I have something installed that has a Windows Explorer extension and doesn't process DBT_QUERYDEVICEREMOVAL correctly. I will try it out later on a clean Windows install one more time - maybe what I thought was a clean Windows installation last time was not that "clean" after all

[Sha0]

...I suppose I have something installed that has a Windows Explorer extension and doesn't process DBT_QUERYDEVICEREMOVAL correctly.

One common "user" of a volume is anti-virus software.

Also, for some odd reason, certain .EXE constructions will leave Explorer holding onto them. For me, they're typically DOS .EXEs that cause this issue. I usually have to destroy the handle with Process Explorer.

You might consider running Process Monitor and monitoring before mounting the volume, then try dismounting the volume, observe the failure, then stop monitoring. You should then be able to trace the file open operation and observe the stack trace at the time of the open operation in Explorer. You can then observe which thread opened the file and possibly gain insight on which modules (beyond Explorer and the usual suspects) were involved.

[Olof Lagerkvist]

So in 1.3.1 there was nothing wrong with SendMessageTimeout, but my concern was regarding the change in 1.4.0 from SendMessageTimeout to PostMessage.

Ah, okay, I forgot that it actually was changed in 1.4.0. It was changed back again in 1.4.1.

[Sophia]

One common "user" of a volume is anti-virus software.

Also, for some odd reason, certain .EXE constructions will leave Explorer holding onto them. For me, they're typically DOS .EXEs that cause this issue. I usually have to destroy the handle with Process Explorer.

You might consider running Process Monitor and monitoring before mounting the volume, then try dismounting the volume, observe the failure, then stop monitoring. You should then be able to trace the file open operation and observe the stack trace at the time of the open operation in Explorer. You can then observe which thread opened the file and possibly gain insight on which modules (beyond Explorer and the usual suspects) were involved.

Thanks for the suggestions, Sha0. I don't have any anti-virus software installed but I've got enough other stuff running that could cause it.

I was half-way done asking for how exactly to do it, before I realised that "Process Monitor" is not the same as "Process Explorer"

I will try it out and come back with my findings.

[DVS]

Without having read through all the hoopla, you should also note that Microsoft has deployed Security Updates to combat rogue malware and virii that took advantage of the auto-run and shortcut link creation. Antivirus software have also changed their default behavior to prevent or limit boot-time and interactive desktop running from removable media (outside of cd/dvd and/or digitally-signed installers).

If you've followed all the usual protocols booting from removable media (or formatted/partitioned your removable media as such), then you may be experiencing the security blockage.

Look at your Add/Remove Programs/Windows Services Pack and locate any KB's related to Auto-Run for CD, DVD and Removable media.

Here's a short article that covers the general problem and reason for the change: My link

Edited by DVS, 07 April 2011 - 04:04 AM.