Если я открываю процесс в драйвере и передаю handle в юзермод я должен буду закрыть handle в драйвере или можно его закрыть в юзермоде используя CloseHandle()?

если это не OBJ_KERNEL_HANDLE то можно в юзермоде, если мне не изменяет склероз

по логике - где открыл, там и прибрался...

и вообще:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff567022%28v=vs.85%29.aspx

Если просто вернуть хэндл в юзермод, то ничего не получится, точнее данный хэндл для процесса будет не валиден.

Сделать можно примерно следующим образом: нужно из драйвера приаттачится к требуемому процессу и прописать описатель в EPROCESS, после чего уже вернуть валидный для процесса хэндл (который по сути является оффсетом в EPROCESS на описатель объекта)

> Если просто вернуть хэндл в юзермод, то ничего не получится,
>  точнее данный хэндл для процесса будет не валиден.

аа, ну в общем случае да.
когда я говорил что должно работать, то подразумевал что хендл получен хоть и в драйвере, но в контексте того же процесса в котором потом предполагается его использовать в юзермоде

> bems ©   (04.02.13 17:38) [5]
> аа, ну в общем случае да.

Тоже спорно, мы тут небольшой консилиум устроили и есть вариант один. Что будет если получить хэндл после того как драйвер будет работать в контексте из-за вызова KeStackAttachProcess(). Будет ли дублироваться описатель в EPROCESS? Это нужно проверить по логике. Но в общем случае, объект открытый в драйвере закрывать нужно в нем-же. Даже если будет дубляж на уровень процесса, то это только RefCount-ы.

ЗЫ: забыл. Ибо при открытии из драйвера описатель объекта по любому будет принадлежать процессу SYSTEM вне зависимости от контекста.

Если я вызываю CloseHandle из юзермод дальше идет по цепочке NtClose->ZwClose

А где ZwClose вызывается?

> А где ZwClose вызывается?

через шлюз вызов в ядро идет. Но роли не играет, данный вызов туда в любом случае проходит.

Короче надо пользовать ObCloseHandle для этого дела http://msdn.microsoft.com/en-us/library/windows/hardware/ff961905(v=vs.85).aspx

A user handle is a handle that is opened by a user-mode application, or by a kernel-mode driver that runs in the context of a user-mode thread but that does not open the handle with the OBJ_KERNEL_HANDLE attribute. If a driver creates a user handle to be used by a user-mode application, but an error occurs that requires the driver to close the handle on behalf of the application, the driver can call ObCloseHandle to close the handle.

ObCloseHandle(hObject, UserMode).

Как то так

> bems ©   (03.02.13 02:23) [1]


Да точняк можно закрывать в юзере, а если нужно в драйвере то (on behalf of the application - от имени приложения) the driver can call ObCloseHandle to close the handle

Дык эта...

> If a driver creates a user handle to be used by a user-mode
> application, but an error occurs that requires the driver
> to close the handle on behalf of the application, the driver
> can call ObCloseHandle to close the handle.

> Rouse_ ©   (04.02.13 22:38) [13]


can call - может вызвать и чего?

Может вызвать "драйвер", про приложение ничего не сказано. Но ты поэксперементируй с приложением, я просто не уверен что из третьего кольца данный вызов приведет к желаемому результату...
Да и если есть возможность тестовые исходники выложи, тоже поэксперементирую, лениво писать рыбу

> забыл. Ибо при открытии из драйвера описатель объекта по
> любому будет принадлежать процессу SYSTEM вне зависимости
> от контекста.

у меня внутри DispatchDeviceControl c запросом IRP_MJ_DEVICE_CONTROL создаётся событие, хендл которого потом успешно используется в юзермоде, процессом вызвавшим DeviceIoControl
В деталях мог напутать, потому что код не смотрел а писал по памяти, но суть в том что хендл живет не в таблице System

Ну вроде да, мы это использовали в двух драйерах - мышином и клавином.

> Rouse_ ©   (04.02.13 22:50) [15]


Ну вроде всё работает, сорцы драйвера и gui http://yadi.sk/d/mo8Jtu5a2Ncnc

Проект для DXE2, тестировал в x64