CreateDeviceAccessInstance does not allow file sharing (?!)
-
5 เมษายน 2555 14:37
Hi everyone,
I successfully communicate with a custom driver through CreateDeviceAccessInstance / IDeviceIoControl API.
But.. now I face the following issue:
Question #1
Is there a way to configure CreateDeviceAccessInstance so that underling file object is shared for r/w access (FILE_SHARE_READ | FILE_SHARE_WRITE) ?
My custom driver is a UMDF (filter driver). It is also accessed via the desktop through plain old CreateFile (with above sharing flags set on).
If I try to play with CreateDeviceAccessInstance() flags it has no effect on file sharing options.
I can confirm it also by registering to IQueueCallbackCreate::OnCreateFile() in my driver : IWDFIoRequest::GetCreateParameters(&options, &fileAttributes, &shareAccess);
Question #2
Is there a way to modify the CreateFile request in the driver (for instance in above-mentionned callback), or issue another create file (internal to the driver) request, which would set FILE_SHARE_READ | FILE_SHARE_WRITE on? I just see IWDFIoRequest::GetCreateParameters, but no way to set them..
Thanks in advance!!
Julien
- เปลี่ยนแปลงประเภท Eric Hanson-MSFTMicrosoft, Moderator 8 มิถุนายน 2555 22:43
- เปลี่ยนแปลงประเภท Eric Hanson-MSFTMicrosoft, Moderator 8 มิถุนายน 2555 22:43
ตอบทั้งหมด
-
5 เมษายน 2555 15:47ผู้ดูแล
Julien,
I will look into this for you.
Best Wishes - Eric
-
5 เมษายน 2555 18:52
Hi Eric,
thanks very much! If you need more detailed context (or less obscure explanation :) I can provide some!
Regards,
Julien
Julien Racle
-
6 เมษายน 2555 19:28ผู้ดูแล
Julien,
Createfile supports a flag for ShareMode as well as DesiredAccess:
HANDLE WINAPI CreateFile(
__in LPCTSTR lpFileName,
__in DWORD dwDesiredAccess,
__in DWORD dwShareMode,
__in_opt LPSECURITY_ATTRIBUTES lpSecurityAttributes,
__in DWORD dwCreationDisposition,
__in DWORD dwFlagsAndAttributes,
__in_opt HANDLE hTemplateFile
);However CreateDeviceAccessInstance has only desiredAccess:
HRESULT WINAPI
CreateDeviceAccessInstance(
_In_ REFIID riid,
_In_ LPCWSTR deviceInterfacePath,
_In_ DWORD desiredAccess,
_Outptr_ ICreateDeviceAccessAsync **createAsync
);However what we recommend is that your device driver have an additional interface for your Metro style device app. Please let me know if you have any questions.
Best Wishes - Eric
- เสนอเป็นคำตอบโดย Eric Hanson-MSFTMicrosoft, Moderator 6 เมษายน 2555 19:28
- แก้ไขโดย Eric Hanson-MSFTMicrosoft, Moderator 6 เมษายน 2555 19:32
-
6 เมษายน 2555 20:47
Hi Eric,
Thanks for your kind reply. Indeed I'd need a bit more explanation :
CreateDeviceAccessInstance() is the only way I have to access my UMDF filter driver from within the Metro app I'm developing. It indeed does not support file sharing mode. Now, the trouble is that the same driver is also accessed from desktop mode via existing apps, which all use CreateFile (with sharing flags ON). Those apps are on the field, already published and used by many people.
So I'm a bit puzzled : why no sharing option in CreateDeviceAccessInstance? Indeed, apart from my use case, multiple privileged metro apps are likely to access same device at the same time.
Is there a way to get around the issue by enforcing those flags, for instance in my driver's IQueueCallbackCreate::OnCreateFile(), so that I don't get a sharing violation error..
Thanks so much for investigating!
JulienJulien Racle
-
7 เมษายน 2555 8:47
Eric,
Again thanks for your answer. If no other way than creating another interface in my driver is found, I gonna try to do so.
BTW my filter driver also is on top of (your) HID class driver, and it forwards many IO requests, so I don't know how to do the relationship between both interfaces/file objects (HID and mine).
You may consider raising the issue for DWORD dwShareMode abscence in CreateDeviceAccessInstance() : indeed the problem will be now that 2 metro apps running in parallel (tiled for instance, or 1 app and a background task), will encounter same file sharing issue (hence option would be to create several interfaces in the diver?! ;).
Thanks!
Julien
Julien Racle
-
11 เมษายน 2555 5:37ผู้ดูแล
Julien,
Is your driver a device filter or class filter? I will raise the issue about the WinRT API.
Best Wishes - Eric
-
11 เมษายน 2555 5:52
Hi Eric,
this is a HID class filter driver installed over a HID vendor collection.
It already works, "except" this file sharing violation issue, which prevents multiple clients.
Best Regards,
Julien
Julien Racle
-
13 เมษายน 2555 5:44ผู้ดูแล
Julien,
I am looking into this for you.
Best Wishes - Eric
-
16 เมษายน 2555 18:04ผู้ดูแล
Julien,
A HID vendor collection does not use file sharing modes in its create path. Are you building this driver on top of a file system? A file system driver is the only driver I am aware of that would need SharedMode.
Are you certain you need the share access in the desktop application?
Best Wishes - Eric
-
17 เมษายน 2555 12:22
Hi Eric,
no, my HID filter driver is built on top of HID class driver, not the filesystem.
I'm not sure to catch what you mean by "A HID vendor collection does not use file sharing modes in its create path.".
Indeed my legacy app uses CreateFile(.... FILE_SHARE_WRITE | FILE_SHARE_READ...) on top level collection's interface path.
If I remove this, then obviously it becomes single client.
Apps I have in the field already use file sharing option : they communicate via a single top level collection through HID class driver.
If I don't have share access in desktop, then it will :
- break legacy support
- break also device access sharing between metro apps / contracts / background tasks (imagine the pb when 2 apps are tiled, or 1 app is running and another needs a contract which also makes use of this device in question)
Best,
Julien
Julien Racle
-
24 เมษายน 2555 22:07ผู้ดูแล
Julien,
For MDA access to HID devices it is recommended to write a HID function driver using UMDF or KMDF to avoid sharing conflicts.
Best Wishes - Eric
- ทำเครื่องหมายเป็นคำตอบโดย Eric Hanson-MSFTMicrosoft, Moderator 25 พฤษภาคม 2555 5:32
- ยกเลิกการทำเครื่องหมายเป็นคำตอบโดย jracle 25 พฤษภาคม 2555 6:03
-
25 พฤษภาคม 2555 6:09
Sorry Eric, but that means I have to write HID class driver myself?
(I repeat : goal is to use HID class driver, and additionally provide shared access to custom features via a vendor collection).
We have dozens of thousands of devices (mice, keyboards) which work this way in my company actually on desktop side, and I would bet we won't plan to develop a function driver to replace HID class driver..
From my point of view, this sounds like a missing parameter in your API, isn't it?
Regards,
Julien
Julien Racle
-
26 พฤษภาคม 2555 5:36ผู้ดูแล
Julien,
I will continue to look into this.
Best Wishes - Eric
-
29 พฤษภาคม 2555 6:27Thanks again very much Eric, and sorry for taking your bandwidth :)
Julien Racle
-
29 พฤษภาคม 2555 6:32ผู้ดูแล
You are very welcome Julien. I appreciate the question.
Best Wishes - Eric
-
8 มิถุนายน 2555 22:43ผู้ดูแล
Julien,
We now have a sample of a HID function driver:
http://code.msdn.microsoft.com/windowshardware/HID-Client-Sample-2e2a6281
The function:
HRESULT WINAPI
CreateDeviceAccessInstance(
_In_ REFIID riid,
_In_ LPCWSTR deviceInterfacePath,
_In_ DWORD desiredAccess,
_Outptr_ ICreateDeviceAccessAsync **createAsync
);is not likely to have sharemode added to it.
Best Wishes - Eric
- ทำเครื่องหมายเป็นคำตอบโดย Eric Hanson-MSFTMicrosoft, Moderator 11 มิถุนายน 2555 23:45
-
9 กรกฎาคม 2555 20:25
Hi Eric,
thanks again for your reply. I'll try that out and hope it'll address my point!
Thanks very much!
Julien Racle
-
9 กรกฎาคม 2555 20:29ผู้ดูแล
Julien,
You are very welcome. Thank You!
Best Wishes - Eric