3 replies to this topic

[v77]

Hi!

Here is my feedback about the version 2.1.1 (yes I'm pretty late).
The UAC request for the control panel works fine. It's a very welcome improvement.
As expected, the installation does not work properly on Vista x64. It's also the case on Windows 7 x64 if not updated. No problem on other systems (still not tried on Windows 11).

What is deviodrv ? You did not mention it in the last news. By the way, it is not started by install.cmd.

[Olof Lagerkvist]

Thanks for your feedback!
 
The deviodrv driver is a kernel level implementation of client end of devio protocol. It is not yet used by default anywhere so it is not automatically started, but it might be in the future so I decided to include it anyway.
 
The driver can be used as an alternative to shared memory communication. It works in a very similar way as with shared memory communication but it makes it easier for driver side to track whether user mode server application is still alive and it also makes it easier to protect the memory from being accessed from other processes because it does not need a global named shared memory object. It is also more transparent to ImDisk and AIM drivers because the client end can be directly opened in the same way as those drivers open image files, so no queuing to worker thread is needed in kernel mode. It is therefore possible to implement more asynchronous behavior and even serve multiple requests simultaneously.
 
However there are not many other practical benefits and except for some exceptional use cases the performance is about the same. It has really only been used in one project so far. There is an implementation for the server end of it in latest devio.exe though, using drv: instead of shm: as prefix.
 

devio drv:examplename c:\imagefile.img
imdisk -a -f \\?\deviodrv\examplename -m #:

[v77]

deviodrv is set to "AUTO_START" so it runs after a reboot:

C:\Windows\system32>sc qc deviodrv
[SC] QueryServiceConfig réussite(s)

SERVICE_NAME: deviodrv
        TYPE               : 1  KERNEL_DRIVER
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 0   IGNORE
        BINARY_PATH_NAME   : \SystemRoot\system32\DRIVERS\deviodrv.sys
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : DevIO Client Driver
        DEPENDENCIES       :
        SERVICE_START_NAME :

C:\Windows\system32>sc query deviodrv

SERVICE_NAME: deviodrv
        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

It would be interesting to benchmark this new method with RamDyn...
Just took a quick look into devio.c... If I understand, the two main functions are alloc_drv_buffer() and drv_flush().

For now, I will just integrate the driver 2.1.1 in the Toolkit with a fallback to 2.0.10 in case where the drivers are not properly installed because of the signatures.

 

[Olof Lagerkvist]

Ah, sorry I missed that it was set to auto-start.

 

To implement server side of deviodrv is unfortunately not very intuitive because the goal was more to optimize performance than to make it easy to interact with. But basically, you first open a "file" called \\?\deviodrv\filename with FILE_FLAG_OVERLAPPED to get a server side handle. Then you allocate memory and lock it in kernel mode by calling IOCTL_DEVIODRV_LOCK_MEMORY specifying a "tag" as input buffer and the buffer you want to lock as output buffer. (I use the user mode address to the buffer as tag, to make it simple. It needs to match later calls and in case you serve multiple requests simultaneously each buffer needs a unique tag, so this address is an easy way to solve that.) Additionally, you specify an OVERLAPPED structure with an event in the DeviceIoControl call because this call will not return as successfully completed, it should return false and GetLastError should return ERROR_IO_PENDING so that the buffer keeps being locked in memory.

 

Then, the server loop calls IOCTL_DEVIODRV_EXCHANGE_IO to get a request from the driver. You pass the "tag" that you used in memory lock call as input buffer and NULL as output buffer. You also need another OVERLAPPED structure with another event object. To get the first request, call GetOverlappedResult, which will block until request is finished. If this fails and GetLastError returns ERROR_INSUFFICIENT_BUFFER a larger buffer is needed. Then finish the lock call by calling GetOverlappedResult on the memory lock OVERLAPPED structure, allocate a larger buffer and repeat.

 

After successful completion of IOCTL_DEVIODRV_EXCHANGE_IO you have the devio protocol header and data in the locked buffer. Then do what is needed with it, fill in the buffer with results and at the next call to IOCTL_DEVIODRV_EXCHANGE_IO the driver will first look at this data and complete the relevant request.

 

The header format is slightly different in that there is a IMDPROXY_DEVIODRV_BUFFER_HEADER before the usual header. It contains additional fields for reliable asynchronous operation. It is supposed to be opaque to the user mode server end, just keep it as it was filled by the driver for next call to the driver so that it can complete the corresponding request in case there are several outstanding requests.