Здравствуйте, zaza1, Вы писали:

Z>кстати вот еще какой вопрос.. заметил такую вещь. если дергать IoGetDeviceObjectPointer (применительно к >партиции) с FILE_READ_DATA сразу после запуска системы, функция обламывается со STATUS_SHARING_VIOLATION
>(помоему так). минут через 10 начинает работать нормально, какой то драйвер отпускает видимо и все ок >станивится.. если вызывать функцию с ACCESS_MASK=0 тогда все ок.. вопрос вообще в чем разница?

разница в том, что при определенных значениях accessmask можно открыть напрямую volume, в остальных случаях вернут верхний device_object из стека файловой системы. Подробнее:

Relative Open Requests for Direct Device Open Handles
The I/O Manager performs a direct device open in response to create or open
requests that meet all of the following criteria:

· The volume name has no trailing characters. For example, G: is
valid, but G:\ and G:\a\b are not.

· The create request is not relative to another file handle.

· The requested access includes one or more of the following, and no
other access types: SYNCHRONIZE, FILE_READ_ATTRIBUTES, READ_CONTROL,
ACCESS_SYSTEM_SECURITY, WRITE_OWNER, WRITE_DAC

For a normal create or open request on a storage volume, the I/O Manager
typically attempts to mount a file system, if none is already mounted.
However, when performing a direct device open, the I/O Manager does not
mount or send requests through a file system. Instead, it sends the
IRP_MJ_CREATE request directly to the storage stack, bypassing any file
system that has been mounted for the volume. Requests for further operations
(such as read, write, or DeviceIoControl) on the file handle are sent to the
topmost device object in the storage stack for the volume.

The I/O Manager performs a direct device open only when the caller requests
limited access to the device, such as the access required to read device
attributes. This type of open operation occurs rarely, but is useful when an
application wants to query certain attributes of a storage volume without
forcing a file system to be mounted.

>и еще.. копнул в эту функцию IoGetDeviceObjectPointer там идет вызов ZwOpenFile с ShareAccess=0, т.е. с >эксклюзивным доступом, изза чего и получается SHARING_VIOLATION.. зачем? почему бы не вызывать с >FILE_SHARE_READ|FILE_SHARE_WRITE? наверное не зря сделали как сделали, но чем черевато все же?

Почему функция IoGetDeviceObjectPointer не имеет параметра sharing мне неизвестно, но обойти это можно, вручную открывая ZwOpenFile с нужными параметрами sharing'а и затем ObOpenObjectByHandle.