Re: fopen vs CreateFile Driver Access issue

After having gone down the suggested path for a couple of weeks I’m still no
closer to finding the answer to my previous question. It was odd however
that when running against the Process monitor, the Create file with my
device name was never run. I’ve tried using the fopen that comes with Visual
C++ 2008 and mingw fopen port and both have a similar issue. When running
with the mingw I don’t however get a Permission Denied message but rather an
Invalid Argument. If I however pass a device like the LTP1 or COM1 devices
to the fopen call there is no issue.

Any help you can give on this issue would be greatly appreciated.

Thanks,


Paul Ryan
OSEC Robotics
xxxxx@gmail.com

On Wed, Apr 30, 2008 at 12:13 PM, Paul Ryan wrote:

> Thanks guys I’ll give those a try.
>
>
> On Wed, Apr 30, 2008 at 11:23 AM, wrote:
>
>> Or, if you don’t have the source of your runtime, Sysinternals’ Process
>> Monitor can capture the CreateFile flags for you too.
>>
>> -Stephen Cleary
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> –
> Paul Ryan
> xxxxx@gmail.com
>

How about you post your code.

mm

Paul Ryan wrote:

After having gone down the suggested path for a couple of weeks I’m
still no closer to finding the answer to my previous question. It was
odd however that when running against the Process monitor, the Create
file with my device name was never run. I’ve tried using the fopen that
comes with Visual C++ 2008 and mingw fopen port and both have a similar
issue. When running with the mingw I don’t however get a Permission
Denied message but rather an Invalid Argument. If I however pass a
device like the LTP1 or COM1 devices to the fopen call there is no issue.

Any help you can give on this issue would be greatly appreciated.

Thanks,


Paul Ryan
OSEC Robotics
xxxxx@gmail.com mailto:xxxxx
>
> On Wed, Apr 30, 2008 at 12:13 PM, Paul Ryan > mailto:xxxxx> wrote:
>
> Thanks guys I’ll give those a try.
>
>
> On Wed, Apr 30, 2008 at 11:23 AM, > mailto:xxxxx> wrote:
>
> Or, if you don’t have the source of your runtime, Sysinternals’
> Process Monitor can capture the CreateFile flags for you too.
>
> -Stephen Cleary
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
> –
> Paul Ryan
> xxxxx@gmail.com mailto:xxxxx
>
>
></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

Martin,

Of course sorry, I can do that, below is the driver entry and create calls
for the driver we’ve been trying to develop, as well as the inf for loading
this driver (this is derived from an example from the code project at
http://www.codeproject.com/KB/system/WDM_Driver_development.aspx), again
thank you for your help with this. Of note with this posted code is that we
at this point are just trying to get our test suite (written for unix) to
talk to the device, then comes the fun (hard part) of porting the driver
control from unix. If there is another peice of the code you think might be
helpful I can provide that as well, I was trying to keep this down to the
parts which I suspect are causing the problem so as not to send a giant
email.

From the driver:

NTSTATUS
DriverEntry(
IN PDRIVER_OBJECT DriverObject,
IN PUNICODE_STRING RegistryPath
)
{
DbgPrint(“In driver entry: begin\n”);
RtlInitUnicodeString(
&Global_sz_Drv_RegInfo,
RegistryPath->Buffer);

// Initialize function pointers

DriverObject->DriverUnload = DriverUnload;
//DriverObject->DriverStartIo = (PVOID)StartIo;
DriverObject->DriverExtension->AddDevice = AddDevice;

DriverObject->MajorFunction[IRP_MJ_CREATE] = PsdoDispatchCreate;
DriverObject->MajorFunction[IRP_MJ_CLOSE] = PsdoDispatchClose;
DriverObject->MajorFunction[IRP_MJ_READ] = PsdoDispatchRead;
DriverObject->MajorFunction[IRP_MJ_WRITE] = PsdoDispatchWrite;
DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] =
PsdoDispatchDeviceControl;
DriverObject->MajorFunction[IRP_MJ_POWER] = PsdoDispatchPower;
DriverObject->MajorFunction[IRP_MJ_PNP] = PsdoDispatchPnP;
DbgPrint(“In driver entry: end\n”);

return STATUS_SUCCESS;
}

NTSTATUS
AddDevice(
IN PDRIVER_OBJECT DriverObject,
IN PDEVICE_OBJECT PhysicalDeviceObject
)
{
ULONG DeviceExtensionSize;
PDEVICE_EXTENSION p_DVCEXT;
PDEVICE_OBJECT ptr_PDO;
NTSTATUS status;
UNICODE_STRING devname;
UNICODE_STRING dosdevname;
ULONG IdxPwrState;
static long lastIndex = -1;
long devIndex = InterlockedIncrement(&lastIndex);
WCHAR name[32];
WCHAR symname[32];

DbgPrint(“*******************************Update 4\n”);

_snwprintf(name, 32, L"\Device\OSEC%d", devIndex);
_snwprintf(symname, 32, L"\DosDevices\OSEC%d", devIndex);

RtlInitUnicodeString(&devname, name);
RtlInitUnicodeString(&dosdevname, symname);
// TODO (pryan) point at actual device location.
DbgPrint(“Loading device in to \Device\OSEC%d file\n”, devIndex);
//Get DEVICE_EXTENSION required memory space
DeviceExtensionSize = sizeof(DEVICE_EXTENSION);
status = IoCreateDevice(
DriverObject,
DeviceExtensionSize,
&devname,
FILE_DEVICE_UNKNOWN,
FILE_DEVICE_SECURE_OPEN,
TRUE,
&ptr_PDO
);

if (NT_SUCCESS(status)) {
ptr_PDO->Flags &= ~DO_DEVICE_INITIALIZING;
ptr_PDO->Flags |= DO_DIRECT_IO;
p_DVCEXT = ptr_PDO->DeviceExtension;
p_DVCEXT->DeviceObject = ptr_PDO;
RtlInitUnicodeString(
&p_DVCEXT->Device_Description,
L"This is a Direct I/O Driver for Pseudo Device\r\n"
L"Created by mjtsai 2003/8/4\r\n");
IoInitializeRemoveLock(
&p_DVCEXT->RemoveLock,
‘KCOL’,
0,
0
);
p_DVCEXT->DataBuffer = ExAllocatePool(
NonPagedPool, 1024);
RtlZeroMemory(
p_DVCEXT->DataBuffer,
1024);
//Initialize driver power state
p_DVCEXT->SysPwrState = PowerSystemWorking;
p_DVCEXT->DevPwrState = PowerDeviceD0;

//Initialize device power information
Global_PowerInfo_Ptr = ExAllocatePool(
NonPagedPool, sizeof(DEVICE_POWER_INFORMATION));
RtlZeroMemory(
Global_PowerInfo_Ptr,
sizeof(DEVICE_POWER_INFORMATION));
Global_PowerInfo_Ptr->SupportQueryCapability = FALSE;
Global_PowerInfo_Ptr->DeviceD1 = 0;
Global_PowerInfo_Ptr->DeviceD2 = 0;
Global_PowerInfo_Ptr->WakeFromD0 = 0;
Global_PowerInfo_Ptr->WakeFromD1 = 0;
Global_PowerInfo_Ptr->WakeFromD2 = 0;
Global_PowerInfo_Ptr->WakeFromD3 = 0;
Global_PowerInfo_Ptr->DeviceWake = 0;
Global_PowerInfo_Ptr->SystemWake = 0;
for (IdxPwrState = 0;
IdxPwrState < PowerSystemMaximum;
IdxPwrState++)
{
Global_PowerInfo_Ptr->DeviceState[IdxPwrState] = 0;
}
//Store next-layered device object
//Attach device object to device stack
p_DVCEXT->NextDeviceObject =
IoAttachDeviceToDeviceStack(ptr_PDO, PhysicalDeviceObject);
}

status = IoCreateSymbolicLink(&dosdevname, &devname);
if (!NT_SUCCESS(status)) {
DbgPrint(“Error creating symlink for device \Device\OSEC%d to
\DosDevices\OSEC%d\n”, devIndex, devIndex);
}

return status;
}

; A:\DevInst.inf
;
; Created by GenINF.
;
;

[Version]
Signature = “$Windows NT$”
Class=System
ClassGUID={4d36e97d-e325-11ce-bfc1-08002be10318}
Provider=%osecrobotics%
CatalogFile=MyCat.cat
DriverVer= 8/4/2003

[DestinationDirs]
DirectIODriver.Files.x86_12 = 12

[SourceDisksNames.x86]
0=%Desc_x860%

[SourceDisksNames.ia64]

[SourceDisksFiles.x86]
DirectDrv.sys=0,

[SourceDisksFiles.ia64]

[Manufacturer]
%osecrobotics%=osecrobotics

[osecrobotics]
%USB\VID_04d8&PID_fe2c.DeviceDesc%=DirectIODriver_Inst,USB\VID_04d8&PID_fe2c

[DirectIODriver_Inst.ntx86]
CopyFiles = DirectIODriver.Files.x86_12

[DirectIODriver_Inst.ntx86.Services]
AddService = DirectDrv,0x00000002,DirectIODriver_Service_Instx86,

[DirectIODriver_Service_Instx86]
ServiceType = %SERVICE_KERNEL_DRIVER%
StartType = %SERVICE_DEMAND_START%
ErrorControl = %SERVICE_ERROR_IGNORE%
ServiceBinary = %12%\DirectDrv.sys

[DirectIODriver.Files.x86_12]
DirectDrv.sys

[DirectIODriver_EventLog_Inst]
AddReg = DirectIODriver_EventLog_Inst.AddReg

[DirectIODriver_EventLog_Inst.AddReg]
HKR,EventMessageFile,%REG_EXPAND_SZ%,“%%SystemRoot%%\System32\IoLogMsg.dll”

HKR,TypesSupported,%REG_DWORD%,7

[Strings]

; *******Localizable Strings*******
mjtsai= “MjtsaiCorp”
Desc_x860= “MjtsaiCorp Systemdrivers”
DirectIODriverDesc= “Virtual Device 1.0.0.1 for Direct I/O Demo”
USB\VID_04d8&PID_fe2c.DeviceDesc= “OSEC Robotics 2.0FS v2.3”

; *******Non Localizable Strings*******

SERVICE_BOOT_START = 0x0
SERVICE_SYSTEM_START = 0x1
SERVICE_AUTO_START = 0x2
SERVICE_DEMAND_START = 0x3
SERVICE_DISABLED = 0x4

SERVICE_KERNEL_DRIVER = 0x1
SERVICE_ERROR_IGNORE = 0x0
SERVICE_ERROR_NORMAL = 0x1
SERVICE_ERROR_SEVERE = 0x2
SERVICE_ERROR_CRITICAL = 0x3

REG_EXPAND_SZ = 0x00020000
REG_DWORD = 0x00010001

On Sat, Jun 7, 2008 at 4:52 PM, Martin O’Brien
wrote:

> How about you post your code.
>
>
> mm
>
> Paul Ryan wrote:
>
>> After having gone down the suggested path for a couple of weeks I’m still
>> no closer to finding the answer to my previous question. It was odd however
>> that when running against the Process monitor, the Create file with my
>> device name was never run. I’ve tried using the fopen that comes with Visual
>> C++ 2008 and mingw fopen port and both have a similar issue. When running
>> with the mingw I don’t however get a Permission Denied message but rather an
>> Invalid Argument. If I however pass a device like the LTP1 or COM1 devices
>> to the fopen call there is no issue.
>>
>> Any help you can give on this issue would be greatly appreciated.
>>
>> Thanks,
>>
>> –
>> Paul Ryan
>> OSEC Robotics
>> xxxxx@gmail.com mailto:xxxxx
>>
>> On Wed, Apr 30, 2008 at 12:13 PM, Paul Ryan >> xxxxx@gmail.com>> wrote:
>>
>> Thanks guys I’ll give those a try.
>>
>>
>> On Wed, Apr 30, 2008 at 11:23 AM, >> mailto:xxxxx> wrote:
>>
>> Or, if you don’t have the source of your runtime, Sysinternals’
>> Process Monitor can capture the CreateFile flags for you too.
>>
>> -Stephen Cleary
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>>
>> – Paul Ryan
>> xxxxx@gmail.com mailto:xxxxx
>>
>>
>>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


Paul Ryan
xxxxx@gmail.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

First of all, you attach a named device. This is your first mistake - for the security reasons it is better to have only one named device (i.e. PDO) in the stack. If you want to access FDO/filter via CreateFile(), it is better to create a standalone device object that is not on the same stack as your actual FDO/filter.

Second, you should clear DO_DEVICE_INITIALIZING *after* having attached your device to the stack and not before doing it. The purpose of having this flag set is telling the system that the additional devices cannot get attached to your device, because it is in the process of being initialized. If you create a device in DriverEntry() the system clears DO_DEVICE_INITIALIZING itself right after DriverEntry() returns control; otherwise it is your responsibility to do so. However, you do it a bit too early -consider what happens if someone attaches on top of your device before you have even attached your device to the stack. Therefore, clearing DO_DEVICE_INITIALIZING flag is the thing that you should do as one of your last steps in device initialization…

These are the very first mistakes that I have noticed after a brief glance at your code…

Anton Bassov

Anton,

First thank you very much for the quick reply, I think I get what you mean
but there is one point of clarification I think I need before proceeding. I
assume you mean I should be giving the IoCreateDevice as follows:

status = IoCreateDevice(
DriverObject,
DeviceExtensionSize,
null,
FILE_DEVICE_UNKNOWN,
FILE_DEVICE_SECURE_OPEN,
TRUE,
&ptr_PDO
);

but I’m confused, if I set null on the name how do I link this device to a
dos device name so that it can be referenced from the create file. I assume
it’s something I can get from the device pointer (ptr_PDO) but I’m not sure
how so I don’t know what the replacement for the following command should be
(what replaces the devname pointer):

status = IoCreateSymbolicLink(&dosdevname, &devname);

I know this must be a very basic question but I’m at a loss to find
documentation pointing to how to do this. The other point you made make
about the clearing of the initialization flag I think you just mean that the
order should be as follows correct:

//Store next-layered device object
//Attach device object to device stack
p_DVCEXT->NextDeviceObject =
IoAttachDeviceToDeviceStack(ptr_PDO, PhysicalDeviceObject);
ptr_PDO->Flags &= ~DO_DEVICE_INITIALIZING;

Again thank you very much for your help with this.

Paul Ryan

On Sat, Jun 7, 2008 at 7:07 PM, wrote:

> First of all, you attach a named device. This is your first mistake - for
> the security reasons it is better to have only one named device (i.e. PDO)
> in the stack. If you want to access FDO/filter via CreateFile(), it is
> better to create a standalone device object that is not on the same stack as
> your actual FDO/filter.
>
>
>
> Second, you should clear DO_DEVICE_INITIALIZING after having attached
> your device to the stack and not before doing it. The purpose of having this
> flag set is telling the system that the additional devices cannot get
> attached to your device, because it is in the process of being initialized.
> If you create a device in DriverEntry() the system clears
> DO_DEVICE_INITIALIZING itself right after DriverEntry() returns control;
> otherwise it is your responsibility to do so. However, you do it a bit too
> early -consider what happens if someone attaches on top of your device
> before you have even attached your device to the stack. Therefore, clearing
> DO_DEVICE_INITIALIZING flag is the thing that you should do as one of your
> last steps in device initialization…
>
> These are the very first mistakes that I have noticed after a brief glance
> at your code…
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

> if I set null on the name how do I link this device to a dos device name so that it can be referenced

from the create file.

This is why you have to create a *standalone* named device object that is not on the stack, and logically associate it with your FDO/filter that is on the stack. When you want to access your FDO/filter, you will send an IOCTL to the named standalone object, rather than device on the stack. This suggestion is based solely upon the security concerns - otherwise, if PDO and named FDO/filter have different user access permissions, by supplying the name of the least restrictively protected one in CreateFile() call you automatically gain an access to all devices on the stack…

//Store next-layered device object
//Attach device object to device stack

p_DVCEXT->NextDeviceObject = IoAttachDeviceToDeviceStack(ptr_PDO, PhysicalDeviceObject); >ptr_PDO->Flags &= ~DO_DEVICE_INITIALIZING;

This is already a better option. In general, clearing DO_DEVICE_INITIALIZING flag should be done when you have done all initialization, so normally it gets done right before returning from AddDEvice(). Check any WDK sample, so that you will see it yourself…

Anton Bassov

It sounds like you’re new to all of this. The advice Anton gave you about not naming your device is a very well supported, and is
in fact the official policy; however, not everyone feels that way, or follows it, including some MSFT drivers, like the one for the
serial port. There are reasons to not follow this guideline, which the WDK does not really make clear and actually states the
opposite as an invariant, but in the big picture, the advice that Anton gave you is very likely to be correct. However, given that
you’re new to this, I’m not sure that I would worry about this security issue right now, as it makes things more complicated, and
you’re having problems that might be related to naming already, so I would go the most straightforward route possible, which is to
just name the thing, at least for the moment.

If you’re interested in an alternative viewpoint on naming device objects from a well respected source, I would
recommend:http://www.osronline.com/article.cfm?article=507. It is also an excellent source of information about how naming of
device objects works in general.

Good luck,

mm

xxxxx@hotmail.com wrote:

> if I set null on the name how do I link this device to a dos device name so that it can be referenced
> from the create file.

This is why you have to create a *standalone* named device object that is not on the stack, and logically associate it with your FDO/filter that is on the stack. When you want to access your FDO/filter, you will send an IOCTL to the named standalone object, rather than device on the stack. This suggestion is based solely upon the security concerns - otherwise, if PDO and named FDO/filter have different user access permissions, by supplying the name of the least restrictively protected one in CreateFile() call you automatically gain an access to all devices on the stack…

> //Store next-layered device object
> //Attach device object to device stack

> p_DVCEXT->NextDeviceObject = IoAttachDeviceToDeviceStack(ptr_PDO, PhysicalDeviceObject); >ptr_PDO->Flags &= ~DO_DEVICE_INITIALIZING;

This is already a better option. In general, clearing DO_DEVICE_INITIALIZING flag should be done when you have done all initialization, so normally it gets done right before returning from AddDEvice(). Check any WDK sample, so that you will see it yourself…

Anton Bassov

Let’s see the code that you’re using to try to open the device. If I understand you correctly, it sounds like you’re saying that
you’re not seeing the user mode call, which is strange.

Thanks,

mm

Paul Ryan wrote:

Martin,

Of course sorry, I can do that, below is the driver entry and create
calls for the driver we’ve been trying to develop, as well as the inf
for loading this driver (this is derived from an example from the code
project at
http://www.codeproject.com/KB/system/WDM_Driver_development.aspx), again
thank you for your help with this. Of note with this posted code is that
we at this point are just trying to get our test suite (written for
unix) to talk to the device, then comes the fun (hard part) of porting
the driver control from unix. If there is another peice of the code you
think might be helpful I can provide that as well, I was trying to keep
this down to the parts which I suspect are causing the problem so as not
to send a giant email.

From the driver:

NTSTATUS
DriverEntry(
IN PDRIVER_OBJECT DriverObject,
IN PUNICODE_STRING RegistryPath
)
{
DbgPrint(“In driver entry: begin\n”);
RtlInitUnicodeString(
&Global_sz_Drv_RegInfo,
RegistryPath->Buffer);

// Initialize function pointers

DriverObject->DriverUnload = DriverUnload;
//DriverObject->DriverStartIo = (PVOID)StartIo;
DriverObject->DriverExtension->AddDevice = AddDevice;

DriverObject->MajorFunction[IRP_MJ_CREATE] = PsdoDispatchCreate;
DriverObject->MajorFunction[IRP_MJ_CLOSE] = PsdoDispatchClose;
DriverObject->MajorFunction[IRP_MJ_READ] = PsdoDispatchRead;
DriverObject->MajorFunction[IRP_MJ_WRITE] = PsdoDispatchWrite;
DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] =
PsdoDispatchDeviceControl;
DriverObject->MajorFunction[IRP_MJ_POWER] = PsdoDispatchPower;
DriverObject->MajorFunction[IRP_MJ_PNP] = PsdoDispatchPnP;
DbgPrint(“In driver entry: end\n”);

return STATUS_SUCCESS;
}

NTSTATUS
AddDevice(
IN PDRIVER_OBJECT DriverObject,
IN PDEVICE_OBJECT PhysicalDeviceObject
)
{
ULONG DeviceExtensionSize;
PDEVICE_EXTENSION p_DVCEXT;
PDEVICE_OBJECT ptr_PDO;
NTSTATUS status;
UNICODE_STRING devname;
UNICODE_STRING dosdevname;
ULONG IdxPwrState;
static long lastIndex = -1;
long devIndex = InterlockedIncrement(&lastIndex);
WCHAR name[32];
WCHAR symname[32];

DbgPrint(“*******************************Update 4\n”);

_snwprintf(name, 32, L"\Device\OSEC%d", devIndex);
_snwprintf(symname, 32, L"\DosDevices\OSEC%d", devIndex);

RtlInitUnicodeString(&devname, name);
RtlInitUnicodeString(&dosdevname, symname);
// TODO (pryan) point at actual device location.
DbgPrint(“Loading device in to \Device\OSEC%d file\n”, devIndex);
//Get DEVICE_EXTENSION required memory space
DeviceExtensionSize = sizeof(DEVICE_EXTENSION);
status = IoCreateDevice(
DriverObject,
DeviceExtensionSize,
&devname,
FILE_DEVICE_UNKNOWN,
FILE_DEVICE_SECURE_OPEN,
TRUE,
&ptr_PDO
);

if (NT_SUCCESS(status)) {
ptr_PDO->Flags &= ~DO_DEVICE_INITIALIZING;
ptr_PDO->Flags |= DO_DIRECT_IO;
p_DVCEXT = ptr_PDO->DeviceExtension;
p_DVCEXT->DeviceObject = ptr_PDO;
RtlInitUnicodeString(
&p_DVCEXT->Device_Description,
L"This is a Direct I/O Driver for Pseudo Device\r\n"
L"Created by mjtsai 2003/8/4\r\n");
IoInitializeRemoveLock(
&p_DVCEXT->RemoveLock,
‘KCOL’,
0,
0
);
p_DVCEXT->DataBuffer = ExAllocatePool(
NonPagedPool, 1024);
RtlZeroMemory(
p_DVCEXT->DataBuffer,
1024);
//Initialize driver power state
p_DVCEXT->SysPwrState = PowerSystemWorking;
p_DVCEXT->DevPwrState = PowerDeviceD0;

//Initialize device power information
Global_PowerInfo_Ptr = ExAllocatePool(
NonPagedPool, sizeof(DEVICE_POWER_INFORMATION));
RtlZeroMemory(
Global_PowerInfo_Ptr,
sizeof(DEVICE_POWER_INFORMATION));
Global_PowerInfo_Ptr->SupportQueryCapability = FALSE;
Global_PowerInfo_Ptr->DeviceD1 = 0;
Global_PowerInfo_Ptr->DeviceD2 = 0;
Global_PowerInfo_Ptr->WakeFromD0 = 0;
Global_PowerInfo_Ptr->WakeFromD1 = 0;
Global_PowerInfo_Ptr->WakeFromD2 = 0;
Global_PowerInfo_Ptr->WakeFromD3 = 0;
Global_PowerInfo_Ptr->DeviceWake = 0;
Global_PowerInfo_Ptr->SystemWake = 0;
for (IdxPwrState = 0;
IdxPwrState < PowerSystemMaximum;
IdxPwrState++)
{
Global_PowerInfo_Ptr->DeviceState[IdxPwrState] = 0;
}
//Store next-layered device object
//Attach device object to device stack
p_DVCEXT->NextDeviceObject =
IoAttachDeviceToDeviceStack(ptr_PDO, PhysicalDeviceObject);
}

status = IoCreateSymbolicLink(&dosdevname, &devname);
if (!NT_SUCCESS(status)) {
DbgPrint(“Error creating symlink for device \Device\OSEC%d to
\DosDevices\OSEC%d\n”, devIndex, devIndex);
}

return status;
}

; A:\DevInst.inf
;
; Created by GenINF.
;
;

[Version]
Signature = “$Windows NT$”
Class=System
ClassGUID={4d36e97d-e325-11ce-bfc1-08002be10318}
Provider=%osecrobotics%
CatalogFile=MyCat.cat
DriverVer= 8/4/2003

[DestinationDirs]
DirectIODriver.Files.x86_12 = 12

[SourceDisksNames.x86]
0=%Desc_x860%

[SourceDisksNames.ia64]

[SourceDisksFiles.x86]
DirectDrv.sys=0,

[SourceDisksFiles.ia64]

[Manufacturer]
%osecrobotics%=osecrobotics

[osecrobotics]
%USB\VID_04d8&PID_fe2c.DeviceDesc%=DirectIODriver_Inst,USB\VID_04d8&PID_fe2c

[DirectIODriver_Inst.ntx86]
CopyFiles = DirectIODriver.Files.x86_12

[DirectIODriver_Inst.ntx86.Services]
AddService = DirectDrv,0x00000002,DirectIODriver_Service_Instx86,

[DirectIODriver_Service_Instx86]
ServiceType = %SERVICE_KERNEL_DRIVER%
StartType = %SERVICE_DEMAND_START%
ErrorControl = %SERVICE_ERROR_IGNORE%
ServiceBinary = %12%\DirectDrv.sys

[DirectIODriver.Files.x86_12]
DirectDrv.sys

[DirectIODriver_EventLog_Inst]
AddReg = DirectIODriver_EventLog_Inst.AddReg

[DirectIODriver_EventLog_Inst.AddReg]
HKR,EventMessageFile,%REG_EXPAND_SZ%,“%%SystemRoot%%\System32\IoLogMsg.dll”

HKR,TypesSupported,%REG_DWORD%,7

[Strings]

; *******Localizable Strings*******
mjtsai= “MjtsaiCorp”
Desc_x860= “MjtsaiCorp Systemdrivers”
DirectIODriverDesc= “Virtual Device 1.0.0.1 http: for Direct
> I/O Demo”
> USB\VID_04d8&PID_fe2c.DeviceDesc= “OSEC Robotics 2.0FS v2.3”
>
> ; Non Localizable Strings
>
> SERVICE_BOOT_START = 0x0
> SERVICE_SYSTEM_START = 0x1
> SERVICE_AUTO_START = 0x2
> SERVICE_DEMAND_START = 0x3
> SERVICE_DISABLED = 0x4
>
> SERVICE_KERNEL_DRIVER = 0x1
> SERVICE_ERROR_IGNORE = 0x0
> SERVICE_ERROR_NORMAL = 0x1
> SERVICE_ERROR_SEVERE = 0x2
> SERVICE_ERROR_CRITICAL = 0x3
>
> REG_EXPAND_SZ = 0x00020000
> REG_DWORD = 0x00010001
>
> On Sat, Jun 7, 2008 at 4:52 PM, Martin O’Brien
> > wrote:
>
> How about you post your code.
>
>
> mm
>
> Paul Ryan wrote:
>
> After having gone down the suggested path for a couple of weeks
> I’m still no closer to finding the answer to my previous
> question. It was odd however that when running against the
> Process monitor, the Create file with my device name was never
> run. I’ve tried using the fopen that comes with Visual C++ 2008
> and mingw fopen port and both have a similar issue. When running
> with the mingw I don’t however get a Permission Denied message
> but rather an Invalid Argument. If I however pass a device like
> the LTP1 or COM1 devices to the fopen call there is no issue.
>
> Any help you can give on this issue would be greatly appreciated.
>
> Thanks,
>
> –
> Paul Ryan
> OSEC Robotics
> xxxxx@gmail.com mailto:xxxxx
> mailto:xxxxx>
>
>
> On Wed, Apr 30, 2008 at 12:13 PM, Paul Ryan > mailto:xxxxx mailto:xxxxx> mailto:xxxxx>> wrote:
>
> Thanks guys I’ll give those a try.
>
>
> On Wed, Apr 30, 2008 at 11:23 AM, > mailto:xxxxx
> mailto:xxxxx> mailto:xxxxx>> wrote:
>
> Or, if you don’t have the source of your runtime,
> Sysinternals’
> Process Monitor can capture the CreateFile flags for you too.
>
> -Stephen Cleary
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other
> seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR
> Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
> – Paul Ryan
> xxxxx@gmail.com mailto:xxxxx
> mailto:xxxxx>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
> –
> Paul Ryan
> xxxxx@gmail.com mailto:xxxxx</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></http:>

Martin,

Thanks for the earlier naming advice (I’ll look into the article and have
already started to see the advantage to it). Yes I’m new to windows device
drivers however I’ve done a bit of linux kernel hacking and have a pretty
extensive windows background (writing low level network protocols), but
again this is really my first foray into windows drivers (I’ve had the most
windows experience in our group so I got tagged with the task). So back to
the other statement about the user mode call, yes that is exactly the
behavior I’ve witnessed. When fopen is called it appears that at some point
another part of the process decides that my driver file is not proper and
throws an error back out without ever calling the CreateFile. I don’t have
the source to the CreateFile so I had to rely on the SysInternals Process
Monitor so it may be reporting wrong however when I run other devices I
definitely see it run the CreateFile. This is the reason I sent the INF
along with the earlier attached source code, it feels like a registry issue,
but then again this is my first time in this realm so I can’t be sure.

Thanks,

Paul Ryan

On Sat, Jun 7, 2008 at 8:39 PM, Martin O’Brien
wrote:

> Let’s see the code that you’re using to try to open the device. If I
> understand you correctly, it sounds like you’re saying that you’re not
> seeing the user mode call, which is strange.
>
>
> Thanks,
>
> mm
>
> Paul Ryan wrote:
>
>> Martin,
>>
>> Of course sorry, I can do that, below is the driver entry and create calls
>> for the driver we’ve been trying to develop, as well as the inf for loading
>> this driver (this is derived from an example from the code project at
>> http://www.codeproject.com/KB/system/WDM_Driver_development.aspx), again
>> thank you for your help with this. Of note with this posted code is that we
>> at this point are just trying to get our test suite (written for unix) to
>> talk to the device, then comes the fun (hard part) of porting the driver
>> control from unix. If there is another peice of the code you think might be
>> helpful I can provide that as well, I was trying to keep this down to the
>> parts which I suspect are causing the problem so as not to send a giant
>> email.
>>
>> From the driver:
>>
>> NTSTATUS
>> DriverEntry(
>> IN PDRIVER_OBJECT DriverObject,
>> IN PUNICODE_STRING RegistryPath
>> )
>> {
>> DbgPrint(“In driver entry: begin\n”);
>> RtlInitUnicodeString(
>> &Global_sz_Drv_RegInfo,
>> RegistryPath->Buffer);
>> // Initialize function pointers
>>
>> DriverObject->DriverUnload = DriverUnload;
>> //DriverObject->DriverStartIo = (PVOID)StartIo;
>> DriverObject->DriverExtension->AddDevice = AddDevice;
>>
>> DriverObject->MajorFunction[IRP_MJ_CREATE] = PsdoDispatchCreate;
>> DriverObject->MajorFunction[IRP_MJ_CLOSE] = PsdoDispatchClose;
>> DriverObject->MajorFunction[IRP_MJ_READ] = PsdoDispatchRead;
>> DriverObject->MajorFunction[IRP_MJ_WRITE] = PsdoDispatchWrite;
>> DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] =
>> PsdoDispatchDeviceControl;
>> DriverObject->MajorFunction[IRP_MJ_POWER] = PsdoDispatchPower;
>> DriverObject->MajorFunction[IRP_MJ_PNP] = PsdoDispatchPnP;
>> DbgPrint(“In driver entry: end\n”);
>>
>> return STATUS_SUCCESS;
>> }
>>
>> NTSTATUS
>> AddDevice(
>> IN PDRIVER_OBJECT DriverObject,
>> IN PDEVICE_OBJECT PhysicalDeviceObject
>> )
>> {
>> ULONG DeviceExtensionSize;
>> PDEVICE_EXTENSION p_DVCEXT;
>> PDEVICE_OBJECT ptr_PDO;
>> NTSTATUS status;
>> UNICODE_STRING devname;
>> UNICODE_STRING dosdevname;
>> ULONG IdxPwrState;
>> static long lastIndex = -1;
>> long devIndex = InterlockedIncrement(&lastIndex);
>> WCHAR name[32];
>> WCHAR symname[32];
>>
>> DbgPrint(“*******************************Update 4\n”);
>> _snwprintf(name, 32, L"\Device\OSEC%d", devIndex);
>> _snwprintf(symname, 32, L"\DosDevices\OSEC%d", devIndex);
>> RtlInitUnicodeString(&devname, name);
>> RtlInitUnicodeString(&dosdevname, symname);
>> // TODO (pryan) point at actual device location.
>> DbgPrint(“Loading device in to \Device\OSEC%d file\n”, devIndex);
>> //Get DEVICE_EXTENSION required memory space
>> DeviceExtensionSize = sizeof(DEVICE_EXTENSION);
>> status = IoCreateDevice(
>> DriverObject,
>> DeviceExtensionSize,
>> &devname,
>> FILE_DEVICE_UNKNOWN,
>> FILE_DEVICE_SECURE_OPEN,
>> TRUE,
>> &ptr_PDO
>> );
>>
>> if (NT_SUCCESS(status)) {
>> ptr_PDO->Flags &= ~DO_DEVICE_INITIALIZING;
>> ptr_PDO->Flags |= DO_DIRECT_IO;
>> p_DVCEXT = ptr_PDO->DeviceExtension;
>> p_DVCEXT->DeviceObject = ptr_PDO;
>> RtlInitUnicodeString(
>> &p_DVCEXT->Device_Description,
>> L"This is a Direct I/O Driver for Pseudo Device\r\n"
>> L"Created by mjtsai 2003/8/4\r\n");
>> IoInitializeRemoveLock(
>> &p_DVCEXT->RemoveLock,
>> ‘KCOL’,
>> 0,
>> 0
>> );
>> p_DVCEXT->DataBuffer = ExAllocatePool(
>> NonPagedPool, 1024);
>> RtlZeroMemory(
>> p_DVCEXT->DataBuffer,
>> 1024);
>> //Initialize driver power state
>> p_DVCEXT->SysPwrState = PowerSystemWorking;
>> p_DVCEXT->DevPwrState = PowerDeviceD0;
>>
>> //Initialize device power information
>> Global_PowerInfo_Ptr = ExAllocatePool(
>> NonPagedPool, sizeof(DEVICE_POWER_INFORMATION));
>> RtlZeroMemory(
>> Global_PowerInfo_Ptr,
>> sizeof(DEVICE_POWER_INFORMATION));
>> Global_PowerInfo_Ptr->SupportQueryCapability = FALSE;
>> Global_PowerInfo_Ptr->DeviceD1 = 0;
>> Global_PowerInfo_Ptr->DeviceD2 = 0;
>> Global_PowerInfo_Ptr->WakeFromD0 = 0;
>> Global_PowerInfo_Ptr->WakeFromD1 = 0;
>> Global_PowerInfo_Ptr->WakeFromD2 = 0;
>> Global_PowerInfo_Ptr->WakeFromD3 = 0;
>> Global_PowerInfo_Ptr->DeviceWake = 0;
>> Global_PowerInfo_Ptr->SystemWake = 0;
>> for (IdxPwrState = 0;
>> IdxPwrState < PowerSystemMaximum;
>> IdxPwrState++)
>> {
>> Global_PowerInfo_Ptr->DeviceState[IdxPwrState] = 0;
>> }
>> //Store next-layered device object
>> //Attach device object to device stack
>> p_DVCEXT->NextDeviceObject =
>> IoAttachDeviceToDeviceStack(ptr_PDO, PhysicalDeviceObject);
>> }
>> status = IoCreateSymbolicLink(&dosdevname, &devname);
>> if (!NT_SUCCESS(status)) {
>> DbgPrint(“Error creating symlink for device \Device\OSEC%d to
>> \DosDevices\OSEC%d\n”, devIndex, devIndex);
>> }
>>
>> return status;
>> }
>>
>> ; A:\DevInst.inf
>> ;
>> ; Created by GenINF.
>> ;
>> ;
>> [Version]
>> Signature = “$Windows NT$”
>> Class=System
>> ClassGUID={4d36e97d-e325-11ce-bfc1-08002be10318}
>> Provider=%osecrobotics%
>> CatalogFile=MyCat.cat
>> DriverVer= 8/4/2003
>>
>> [DestinationDirs]
>> DirectIODriver.Files.x86_12 = 12
>>
>> [SourceDisksNames.x86]
>> 0=%Desc_x860%
>>
>> [SourceDisksNames.ia64]
>>
>>
>> [SourceDisksFiles.x86]
>> DirectDrv.sys=0,
>>
>> [SourceDisksFiles.ia64]
>>
>>
>> [Manufacturer]
>> %osecrobotics%=osecrobotics
>>
>> [osecrobotics]
>>
>> %USB\VID_04d8&PID_fe2c.DeviceDesc%=DirectIODriver_Inst,USB\VID_04d8&PID_fe2c
>>
>> [DirectIODriver_Inst.ntx86]
>> CopyFiles = DirectIODriver.Files.x86_12
>>
>> [DirectIODriver_Inst.ntx86.Services]
>> AddService = DirectDrv,0x00000002,DirectIODriver_Service_Instx86,
>>
>> [DirectIODriver_Service_Instx86]
>> ServiceType = %SERVICE_KERNEL_DRIVER%
>> StartType = %SERVICE_DEMAND_START%
>> ErrorControl = %SERVICE_ERROR_IGNORE%
>> ServiceBinary = %12%\DirectDrv.sys
>>
>>
>> [DirectIODriver.Files.x86_12]
>> DirectDrv.sys
>>
>> [DirectIODriver_EventLog_Inst]
>> AddReg = DirectIODriver_EventLog_Inst.AddReg
>> [DirectIODriver_EventLog_Inst.AddReg]
>> HKR,EventMessageFile,%REG_EXPAND_SZ%,“%%SystemRoot%%\System32\IoLogMsg.dll”
>>
>> HKR,TypesSupported,%REG_DWORD%,7
>>
>>
>> [Strings]
>>
>> ;*******Localizable Strings
>> mjtsai= “MjtsaiCorp”
>> Desc_x860= “MjtsaiCorp Systemdrivers”
>> DirectIODriverDesc= “Virtual Device 1.0.0.1 http: for Direct
>> I/O Demo”
>> USB\VID_04d8&PID_fe2c.DeviceDesc= “OSEC Robotics 2.0FS v2.3”
>>
>> ;
Non Localizable Strings *******
>>
>> SERVICE_BOOT_START = 0x0
>> SERVICE_SYSTEM_START = 0x1
>> SERVICE_AUTO_START = 0x2
>> SERVICE_DEMAND_START = 0x3
>> SERVICE_DISABLED = 0x4
>>
>> SERVICE_KERNEL_DRIVER = 0x1
>> SERVICE_ERROR_IGNORE = 0x0
>> SERVICE_ERROR_NORMAL = 0x1
>> SERVICE_ERROR_SEVERE = 0x2
>> SERVICE_ERROR_CRITICAL = 0x3
>>
>> REG_EXPAND_SZ = 0x00020000
>> REG_DWORD = 0x00010001
>>
>> On Sat, Jun 7, 2008 at 4:52 PM, Martin O’Brien >> xxxxx@evitechnology.com>> wrote:
>>
>> How about you post your code.
>>
>>
>> mm
>>
>> Paul Ryan wrote:
>>
>> After having gone down the suggested path for a couple of weeks
>> I’m still no closer to finding the answer to my previous
>> question. It was odd however that when running against the
>> Process monitor, the Create file with my device name was never
>> run. I’ve tried using the fopen that comes with Visual C++ 2008
>> and mingw fopen port and both have a similar issue. When running
>> with the mingw I don’t however get a Permission Denied message
>> but rather an Invalid Argument. If I however pass a device like
>> the LTP1 or COM1 devices to the fopen call there is no issue.
>>
>> Any help you can give on this issue would be greatly appreciated.
>>
>> Thanks,
>>
>> –
>> Paul Ryan
>> OSEC Robotics
>> xxxxx@gmail.com mailto:xxxxx
>> mailto:xxxxx>
>>
>>
>> On Wed, Apr 30, 2008 at 12:13 PM, Paul Ryan >> mailto:xxxxx mailto:xxxxx>> mailto:xxxxx>> wrote:
>>
>> Thanks guys I’ll give those a try.
>>
>>
>> On Wed, Apr 30, 2008 at 11:23 AM, >> mailto:xxxxx
>> mailto:xxxxx>> mailto:xxxxx>> wrote:
>>
>> Or, if you don’t have the source of your runtime,
>> Sysinternals’
>> Process Monitor can capture the CreateFile flags for you
>> too.
>>
>> -Stephen Cleary
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other
>> seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR
>> Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>>
>> – Paul Ryan
>> xxxxx@gmail.com mailto:xxxxx
>> mailto:xxxxx>
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>>
>> –
>> Paul Ryan
>> xxxxx@gmail.com mailto:xxxxx
>>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


Paul Ryan
xxxxx@gmail.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></http:>

A lot is going on here

  1. Why naming your fdo is not a great idea and things you can do to mitigate the issues that this brings up, http://blogs.msdn.com/doronh/archive/2007/04/18/having-two-names-is-not-necessarily-better-than-one.aspx

  2. How to create a named symbolic link in your FDO driver w/out naming the FDO (using the PDO’s name instead), http://blogs.msdn.com/doronh/archive/2007/05/03/creating-symbolic-links-for-an-anonymous-fdo-or-filter.aspx

  3. Anton’s advice of creating a 2ndary device that is named is really not good (I would never personally advise to do this purely for this reason, there are other reasons not related to this device to do this though). You have to know manage two devices lifetimes and now pnp has no idea that the handles opened against the 2ndary device are really against the pnp stack, making a lot more work for you in the driver

  4. While technically correct that you should clear DO_DEVICE_INITIALIZING later in your AddDevice routine, in reality the creates to the stack are also blocked by the stack’s pnp state so you will not see a create until the entire stack has successfully completed the pnp start irp so this mistake is no big deal

  5. I would also strongly suggest that you consider KMDF instead. A lot of this stuff (the initializing flag, anonymous symbolic links to the PDO, pnp/power) goes way.
    d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Paul Ryan
Sent: Saturday, June 07, 2008 10:18 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] fopen vs CreateFile Driver Access issue

Martin,

Thanks for the earlier naming advice (I’ll look into the article and have already started to see the advantage to it). Yes I’m new to windows device drivers however I’ve done a bit of linux kernel hacking and have a pretty extensive windows background (writing low level network protocols), but again this is really my first foray into windows drivers (I’ve had the most windows experience in our group so I got tagged with the task). So back to the other statement about the user mode call, yes that is exactly the behavior I’ve witnessed. When fopen is called it appears that at some point another part of the process decides that my driver file is not proper and throws an error back out without ever calling the CreateFile. I don’t have the source to the CreateFile so I had to rely on the SysInternals Process Monitor so it may be reporting wrong however when I run other devices I definitely see it run the CreateFile. This is the reason I sent the INF along with the earlier attached source code, it feels like a registry issue, but then again this is my first time in this realm so I can’t be sure.

Thanks,

Paul Ryan
On Sat, Jun 7, 2008 at 8:39 PM, Martin O’Brien > wrote:
Let’s see the code that you’re using to try to open the device. If I understand you correctly, it sounds like you’re saying that you’re not seeing the user mode call, which is strange.

Thanks,

mm

Paul Ryan wrote:
Martin,

Of course sorry, I can do that, below is the driver entry and create calls for the driver we’ve been trying to develop, as well as the inf for loading this driver (this is derived from an example from the code project at http://www.codeproject.com/KB/system/WDM_Driver_development.aspx), again thank you for your help with this. Of note with this posted code is that we at this point are just trying to get our test suite (written for unix) to talk to the device, then comes the fun (hard part) of porting the driver control from unix. If there is another peice of the code you think might be helpful I can provide that as well, I was trying to keep this down to the parts which I suspect are causing the problem so as not to send a giant email.

From the driver:

NTSTATUS
DriverEntry(
IN PDRIVER_OBJECT DriverObject,
IN PUNICODE_STRING RegistryPath
)
{
DbgPrint(“In driver entry: begin\n”);
RtlInitUnicodeString(
&Global_sz_Drv_RegInfo,
RegistryPath->Buffer);
// Initialize function pointers

DriverObject->DriverUnload = DriverUnload;
//DriverObject->DriverStartIo = (PVOID)StartIo;
DriverObject->DriverExtension->AddDevice = AddDevice;

DriverObject->MajorFunction[IRP_MJ_CREATE] = PsdoDispatchCreate;
DriverObject->MajorFunction[IRP_MJ_CLOSE] = PsdoDispatchClose;
DriverObject->MajorFunction[IRP_MJ_READ] = PsdoDispatchRead;
DriverObject->MajorFunction[IRP_MJ_WRITE] = PsdoDispatchWrite;
DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = PsdoDispatchDeviceControl;
DriverObject->MajorFunction[IRP_MJ_POWER] = PsdoDispatchPower;
DriverObject->MajorFunction[IRP_MJ_PNP] = PsdoDispatchPnP;
DbgPrint(“In driver entry: end\n”);

return STATUS_SUCCESS;
}

NTSTATUS
AddDevice(
IN PDRIVER_OBJECT DriverObject,
IN PDEVICE_OBJECT PhysicalDeviceObject
)
{
ULONG DeviceExtensionSize;
PDEVICE_EXTENSION p_DVCEXT;
PDEVICE_OBJECT ptr_PDO;
NTSTATUS status;
UNICODE_STRING devname;
UNICODE_STRING dosdevname;
ULONG IdxPwrState;
static long lastIndex = -1;
long devIndex = InterlockedIncrement(&lastIndex);
WCHAR name[32];
WCHAR symname[32];

DbgPrint(“*******************************Update 4\n”);
_snwprintf(name, 32, L"\Device\OSEC%d", devIndex);
_snwprintf(symname, 32, L"\DosDevices\OSEC%d", devIndex);
RtlInitUnicodeString(&devname, name);
RtlInitUnicodeString(&dosdevname, symname);
// TODO (pryan) point at actual device location.
DbgPrint(“Loading device in to \Device\OSEC%d file\n”, devIndex);
//Get DEVICE_EXTENSION required memory space
DeviceExtensionSize = sizeof(DEVICE_EXTENSION);
status = IoCreateDevice(
DriverObject,
DeviceExtensionSize,
&devname,
FILE_DEVICE_UNKNOWN,
FILE_DEVICE_SECURE_OPEN,
TRUE,
&ptr_PDO
);
if (NT_SUCCESS(status)) {

ptr_PDO->Flags &= ~DO_DEVICE_INITIALIZING;
ptr_PDO->Flags |= DO_DIRECT_IO;
p_DVCEXT = ptr_PDO->DeviceExtension;
p_DVCEXT->DeviceObject = ptr_PDO;
RtlInitUnicodeString(
&p_DVCEXT->Device_Description,
L"This is a Direct I/O Driver for Pseudo Device\r\n"
L"Created by mjtsai 2003/8/4\r\n");
IoInitializeRemoveLock(
&p_DVCEXT->RemoveLock,
‘KCOL’,
0,
0
);
p_DVCEXT->DataBuffer = ExAllocatePool(
NonPagedPool, 1024);
RtlZeroMemory(
p_DVCEXT->DataBuffer,
1024);
//Initialize driver power state
p_DVCEXT->SysPwrState = PowerSystemWorking;
p_DVCEXT->DevPwrState = PowerDeviceD0;

//Initialize device power information
Global_PowerInfo_Ptr = ExAllocatePool(
NonPagedPool, sizeof(DEVICE_POWER_INFORMATION));
RtlZeroMemory(
Global_PowerInfo_Ptr,
sizeof(DEVICE_POWER_INFORMATION));
Global_PowerInfo_Ptr->SupportQueryCapability = FALSE;
Global_PowerInfo_Ptr->DeviceD1 = 0;
Global_PowerInfo_Ptr->DeviceD2 = 0;
Global_PowerInfo_Ptr->WakeFromD0 = 0;
Global_PowerInfo_Ptr->WakeFromD1 = 0;
Global_PowerInfo_Ptr->WakeFromD2 = 0;
Global_PowerInfo_Ptr->WakeFromD3 = 0;
Global_PowerInfo_Ptr->DeviceWake = 0;
Global_PowerInfo_Ptr->SystemWake = 0;
for (IdxPwrState = 0;
IdxPwrState < PowerSystemMaximum;
IdxPwrState++)
{
Global_PowerInfo_Ptr->DeviceState[IdxPwrState] = 0;
}
//Store next-layered device object
//Attach device object to device stack
p_DVCEXT->NextDeviceObject =
IoAttachDeviceToDeviceStack(ptr_PDO, PhysicalDeviceObject);
}
status = IoCreateSymbolicLink(&dosdevname, &devname);
if (!NT_SUCCESS(status)) {
DbgPrint(“Error creating symlink for device \Device\OSEC%d to \DosDevices\OSEC%d\n”, devIndex, devIndex);
}

return status;
}

; A:\DevInst.inf
;
; Created by GenINF.
;
;
[Version]
Signature = “$Windows NT$”
Class=System
ClassGUID={4d36e97d-e325-11ce-bfc1-08002be10318}
Provider=%osecrobotics%
CatalogFile=MyCat.cat
DriverVer= 8/4/2003

[DestinationDirs]
DirectIODriver.Files.x86_12 = 12

[SourceDisksNames.x86]
0=%Desc_x860%

[SourceDisksNames.ia64]

[SourceDisksFiles.x86]
DirectDrv.sys=0,

[SourceDisksFiles.ia64]

[Manufacturer]
%osecrobotics%=osecrobotics

[osecrobotics]
%USB\VID_04d8&PID_fe2c.DeviceDesc%=DirectIODriver_Inst,USB\VID_04d8&PID_fe2c

[DirectIODriver_Inst.ntx86]
CopyFiles = DirectIODriver.Files.x86_12

[DirectIODriver_Inst.ntx86.Services]
AddService = DirectDrv,0x00000002,DirectIODriver_Service_Instx86,

[DirectIODriver_Service_Instx86]
ServiceType = %SERVICE_KERNEL_DRIVER%
StartType = %SERVICE_DEMAND_START%
ErrorControl = %SERVICE_ERROR_IGNORE%
ServiceBinary = %12%\DirectDrv.sys

[DirectIODriver.Files.x86_12]
DirectDrv.sys

[DirectIODriver_EventLog_Inst]
AddReg = DirectIODriver_EventLog_Inst.AddReg
[DirectIODriver_EventLog_Inst.AddReg]
HKR,EventMessageFile,%REG_EXPAND_SZ%,“%%SystemRoot%%\System32\IoLogMsg.dll”
HKR,TypesSupported,%REG_DWORD%,7

[Strings]

;*******Localizable Strings
mjtsai= “MjtsaiCorp”
Desc_x860= “MjtsaiCorp Systemdrivers”
DirectIODriverDesc= “Virtual Device 1.0.0.1http: http: for Direct I/O Demo”

USB\VID_04d8&PID_fe2c.DeviceDesc= “OSEC Robotics 2.0FS v2.3”

;
Non Localizable Strings *******

SERVICE_BOOT_START = 0x0
SERVICE_SYSTEM_START = 0x1
SERVICE_AUTO_START = 0x2
SERVICE_DEMAND_START = 0x3
SERVICE_DISABLED = 0x4

SERVICE_KERNEL_DRIVER = 0x1
SERVICE_ERROR_IGNORE = 0x0
SERVICE_ERROR_NORMAL = 0x1
SERVICE_ERROR_SEVERE = 0x2
SERVICE_ERROR_CRITICAL = 0x3

REG_EXPAND_SZ = 0x00020000
REG_DWORD = 0x00010001
On Sat, Jun 7, 2008 at 4:52 PM, Martin O’Brien mailto:xxxxx>> wrote:

How about you post your code.

mm

Paul Ryan wrote:

After having gone down the suggested path for a couple of weeks
I’m still no closer to finding the answer to my previous
question. It was odd however that when running against the
Process monitor, the Create file with my device name was never
run. I’ve tried using the fopen that comes with Visual C++ 2008
and mingw fopen port and both have a similar issue. When running
with the mingw I don’t however get a Permission Denied message
but rather an Invalid Argument. If I however pass a device like
the LTP1 or COM1 devices to the fopen call there is no issue.

Any help you can give on this issue would be greatly appreciated.

Thanks,


Paul Ryan
OSEC Robotics
xxxxx@gmail.commailto:xxxxx mailto:xxxxx>
mailto:xxxxx mailto:xxxxx>>

On Wed, Apr 30, 2008 at 12:13 PM, Paul Ryan
mailto:xxxxx> mailto:xxxxx

mailto:xxxxx>>> wrote:

Thanks guys I’ll give those a try.

On Wed, Apr 30, 2008 at 11:23 AM,
mailto:xxxxx>
mailto:xxxxx
mailto:xxxxx>>> wrote:

Or, if you don’t have the source of your runtime,
Sysinternals’
Process Monitor can capture the CreateFile flags for you too.

-Stephen Cleary


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other
seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR
Online at
http://www.osronline.com/page.cfm?name=ListServer

– Paul Ryan
xxxxx@gmail.commailto:xxxxx mailto:xxxxx>
mailto:xxxxx mailto:xxxxx>>


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer


Paul Ryan
xxxxx@gmail.commailto:xxxxx mailto:xxxxx>


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


Paul Ryan
xxxxx@gmail.commailto:xxxxx — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></http:></http:>

> You have to know manage two devices lifetimes and now pnp has no idea that the handles opened >against the 2ndary device are really against the pnp stack, making a lot more work for you in the driver

Well, you can take advantage on the fact that, as long as 2dary device’s refcount is nonzero, it cannot get
removed from RAM (and, hence, driver image cannot get unloaded either - not even after DrvUnload()'s return) . IoDeleteDevice() is just going to mark it for a deletion, but it will stay resident in RAM until refcount goes down to zero. Therefore, you can delete 2dary device together with a primary one, Just complete all outstanding requests to it, mark it as being deleted so that you will know that you should fail all subsequent ones (apart from IRP_MJ_CLEANUP and IRP_MJ_CLOSE, of course), delete it, and that’s it. - when the last reference to it gets released it will be gone…

Anton Bassov

Yes and if it is a conduit to hardware in the pnp state, you have to purge pending i/o when the pnp device goes away. You potentially also have to coordinate power state as well. This can all be done…but why add such complexity? Purely for a named devobj? That is a ridiculously large hammer for a very tiny nail.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Saturday, June 07, 2008 11:20 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Re: fopen vs CreateFile Driver Access issue

You have to know manage two devices lifetimes and now pnp has no idea that the handles opened >against the 2ndary device are really against the pnp stack, making a lot more work for you in the driver

Well, you can take advantage on the fact that, as long as 2dary device’s refcount is nonzero, it cannot get
removed from RAM (and, hence, driver image cannot get unloaded either - not even after DrvUnload()'s return) . IoDeleteDevice() is just going to mark it for a deletion, but it will stay resident in RAM until refcount goes down to zero. Therefore, you can delete 2dary device together with a primary one, Just complete all outstanding requests to it, mark it as being deleted so that you will know that you should fail all subsequent ones (apart from IRP_MJ_CLEANUP and IRP_MJ_CLOSE, of course), delete it, and that’s it. - when the last reference to it gets released it will be gone…

Anton Bassov


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

> Yes and if it is a conduit to hardware in the pnp state, you have to purge pending i/o when the pnp device >goes away. You potentially also have to coordinate power state as well. This can all be done…but why add >such complexity? Purely for a named devobj?

Well, all the complexity that you have mentioned is implied not by the secondary device in itself but by the very fact that the OP wants to send PnP device the requests that are totally unrelated to PnP - this is why he needs a named devobj, in the first place. Therefore, even if he does not create a secondary device and, instead, just attaches the named devobj to the stack the way he currently does, it still does not save him from the pains that you have mentioned above. If you mean that accessing PnP device this way is not a very good idea… well, I do agree with you, but I am afraid this is his primary objective…

Anton Bassov

> behavior I’ve witnessed. When fopen is called it appears that at some point

another part of the process decides that my driver file is not proper and
throws an error back out without ever calling the CreateFile.

How about calling CreateFile directly?


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Good idea, Maxim.

This was is what I was going for the advice of not getting in to whether to name the device object or not - let’s start with the
basics, because according to what I’ve read so far, the CreateFile call is even showing in Process Explorer (or some tool), so
there’s something more fundamental at issue here.

Cheers,

mm

Maxim S. Shatskih wrote:

> behavior I’ve witnessed. When fopen is called it appears that at some point
> another part of the process decides that my driver file is not proper and
> throws an error back out without ever calling the CreateFile.

How about calling CreateFile directly?

I think that Doron’s advice to use KMDF is excellent, and clearly the way to go in the big picture, though I think it would be a
good idea to figure out what’s wrong here first, both for the sake of learning, and moreover because the basic issues with KMDF,
like installation, are much, much worse, that is an absolutely fabulous product notwithstanding.

mm

Martin O’Brien wrote:

Good idea, Maxim.

This was is what I was going for the advice of not getting in to whether
to name the device object or not - let’s start with the basics, because
according to what I’ve read so far, the CreateFile call is even showing
in Process Explorer (or some tool), so there’s something more
fundamental at issue here.

Cheers,

mm

Maxim S. Shatskih wrote:
>> behavior I’ve witnessed. When fopen is called it appears that at some
>> point
>> another part of the process decides that my driver file is not proper
>> and
>> throws an error back out without ever calling the CreateFile.
>
> How about calling CreateFile directly?
>

I think that we need to see your user mode code that calls fopen/CreateFile, because you’ve got something very fundamental incorrect
here, or you’re not using the tools that you’ve used to determine that CreateFile is not being called correctly, which would be my
guess.

Thanks,

mm

Paul Ryan wrote:

Martin,

Thanks for the earlier naming advice (I’ll look into the article and
have already started to see the advantage to it). Yes I’m new to windows
device drivers however I’ve done a bit of linux kernel hacking and have
a pretty extensive windows background (writing low level network
protocols), but again this is really my first foray into windows drivers
(I’ve had the most windows experience in our group so I got tagged with
the task). So back to the other statement about the user mode call, yes
that is exactly the behavior I’ve witnessed. When fopen is called it
appears that at some point another part of the process decides that my
driver file is not proper and throws an error back out without ever
calling the CreateFile. I don’t have the source to the CreateFile so I
had to rely on the SysInternals Process Monitor so it may be reporting
wrong however when I run other devices I definitely see it run the
CreateFile. This is the reason I sent the INF along with the earlier
attached source code, it feels like a registry issue, but then again
this is my first time in this realm so I can’t be sure.

Thanks,

Paul Ryan

On Sat, Jun 7, 2008 at 8:39 PM, Martin O’Brien
> wrote:
>
> Let’s see the code that you’re using to try to open the device. If
> I understand you correctly, it sounds like you’re saying that you’re
> not seeing the user mode call, which is strange.
>
>
> Thanks,
>
> mm
>
> Paul Ryan wrote:
>
> Martin,
>
> Of course sorry, I can do that, below is the driver entry and
> create calls for the driver we’ve been trying to develop, as
> well as the inf for loading this driver (this is derived from an
> example from the code project at
> http://www.codeproject.com/KB/system/WDM_Driver_development.aspx),
> again thank you for your help with this. Of note with this
> posted code is that we at this point are just trying to get our
> test suite (written for unix) to talk to the device, then comes
> the fun (hard part) of porting the driver control from unix. If
> there is another peice of the code you think might be helpful I
> can provide that as well, I was trying to keep this down to the
> parts which I suspect are causing the problem so as not to send
> a giant email.
>
> From the driver:
>
> NTSTATUS
> DriverEntry(
> IN PDRIVER_OBJECT DriverObject,
> IN PUNICODE_STRING RegistryPath
> )
> {
> DbgPrint(“In driver entry: begin\n”);
> RtlInitUnicodeString(
> &Global_sz_Drv_RegInfo,
> RegistryPath->Buffer);
> // Initialize function pointers
>
> DriverObject->DriverUnload = DriverUnload;
> //DriverObject->DriverStartIo = (PVOID)StartIo;
> DriverObject->DriverExtension->AddDevice = AddDevice;
>
> DriverObject->MajorFunction[IRP_MJ_CREATE] = PsdoDispatchCreate;
> DriverObject->MajorFunction[IRP_MJ_CLOSE] = PsdoDispatchClose;
> DriverObject->MajorFunction[IRP_MJ_READ] = PsdoDispatchRead;
> DriverObject->MajorFunction[IRP_MJ_WRITE] = PsdoDispatchWrite;
> DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] =
> PsdoDispatchDeviceControl;
> DriverObject->MajorFunction[IRP_MJ_POWER] = PsdoDispatchPower;
> DriverObject->MajorFunction[IRP_MJ_PNP] = PsdoDispatchPnP;
> DbgPrint(“In driver entry: end\n”);
>
> return STATUS_SUCCESS;
> }
>
> NTSTATUS
> AddDevice(
> IN PDRIVER_OBJECT DriverObject,
> IN PDEVICE_OBJECT PhysicalDeviceObject
> )
> {
> ULONG DeviceExtensionSize;
> PDEVICE_EXTENSION p_DVCEXT;
> PDEVICE_OBJECT ptr_PDO;
> NTSTATUS status;
> UNICODE_STRING devname;
> UNICODE_STRING dosdevname;
> ULONG IdxPwrState;
> static long lastIndex = -1;
> long devIndex = InterlockedIncrement(&lastIndex);
> WCHAR name[32];
> WCHAR symname[32];
>
> DbgPrint(“*******************************Update 4\n”);
> _snwprintf(name, 32, L"\Device\OSEC%d", devIndex);
> _snwprintf(symname, 32, L"\DosDevices\OSEC%d", devIndex);
> RtlInitUnicodeString(&devname, name);
> RtlInitUnicodeString(&dosdevname, symname);
> // TODO (pryan) point at actual device location.
> DbgPrint(“Loading device in to \Device\OSEC%d file\n”,
> devIndex);
> //Get DEVICE_EXTENSION required memory space
> DeviceExtensionSize = sizeof(DEVICE_EXTENSION);
> status = IoCreateDevice(
> DriverObject,
> DeviceExtensionSize,
> &devname,
> FILE_DEVICE_UNKNOWN,
> FILE_DEVICE_SECURE_OPEN,
> TRUE,
> &ptr_PDO
> );
>
> if (NT_SUCCESS(status)) {
>
> ptr_PDO->Flags &= ~DO_DEVICE_INITIALIZING;
> ptr_PDO->Flags |= DO_DIRECT_IO;
> p_DVCEXT = ptr_PDO->DeviceExtension;
> p_DVCEXT->DeviceObject = ptr_PDO;
> RtlInitUnicodeString(
> &p_DVCEXT->Device_Description,
> L"This is a Direct I/O Driver for Pseudo Device\r\n"
> L"Created by mjtsai 2003/8/4\r\n");
> IoInitializeRemoveLock(
> &p_DVCEXT->RemoveLock,
> ‘KCOL’,
> 0,
> 0
> );
> p_DVCEXT->DataBuffer = ExAllocatePool(
> NonPagedPool, 1024);
> RtlZeroMemory(
> p_DVCEXT->DataBuffer,
> 1024);
> //Initialize driver power state
> p_DVCEXT->SysPwrState = PowerSystemWorking;
> p_DVCEXT->DevPwrState = PowerDeviceD0;
>
> //Initialize device power information
> Global_PowerInfo_Ptr = ExAllocatePool(
> NonPagedPool, sizeof(DEVICE_POWER_INFORMATION));
> RtlZeroMemory(
> Global_PowerInfo_Ptr,
> sizeof(DEVICE_POWER_INFORMATION));
> Global_PowerInfo_Ptr->SupportQueryCapability = FALSE;
> Global_PowerInfo_Ptr->DeviceD1 = 0;
> Global_PowerInfo_Ptr->DeviceD2 = 0;
> Global_PowerInfo_Ptr->WakeFromD0 = 0;
> Global_PowerInfo_Ptr->WakeFromD1 = 0;
> Global_PowerInfo_Ptr->WakeFromD2 = 0;
> Global_PowerInfo_Ptr->WakeFromD3 = 0;
> Global_PowerInfo_Ptr->DeviceWake = 0;
> Global_PowerInfo_Ptr->SystemWake = 0;
> for (IdxPwrState = 0;
> IdxPwrState < PowerSystemMaximum;
> IdxPwrState++)
> {
> Global_PowerInfo_Ptr->DeviceState[IdxPwrState] = 0;
> }
> //Store next-layered device object
> //Attach device object to device stack
> p_DVCEXT->NextDeviceObject =
> IoAttachDeviceToDeviceStack(ptr_PDO,
> PhysicalDeviceObject);
> }
> status = IoCreateSymbolicLink(&dosdevname, &devname);
> if (!NT_SUCCESS(status)) {
> DbgPrint(“Error creating symlink for device
> \Device\OSEC%d to \DosDevices\OSEC%d\n”, devIndex, devIndex);
> }
>
> return status;
> }
>
> ; A:\DevInst.inf
> ;
> ; Created by GenINF.
> ;
> ;
> [Version]
> Signature = “$Windows NT$”
> Class=System
> ClassGUID={4d36e97d-e325-11ce-bfc1-08002be10318}
> Provider=%osecrobotics%
> CatalogFile=MyCat.cat
> DriverVer= 8/4/2003
>
> [DestinationDirs]
> DirectIODriver.Files.x86_12 = 12
>
> [SourceDisksNames.x86]
> 0=%Desc_x860%
>
> [SourceDisksNames.ia64]
>
>
> [SourceDisksFiles.x86]
> DirectDrv.sys=0,
>
> [SourceDisksFiles.ia64]
>
>
> [Manufacturer]
> %osecrobotics%=osecrobotics
>
> [osecrobotics]
> %USB\VID_04d8&PID_fe2c.DeviceDesc%=DirectIODriver_Inst,USB\VID_04d8&PID_fe2c
>
> [DirectIODriver_Inst.ntx86]
> CopyFiles = DirectIODriver.Files.x86_12
>
> [DirectIODriver_Inst.ntx86.Services]
> AddService = DirectDrv,0x00000002,DirectIODriver_Service_Instx86,
>
> [DirectIODriver_Service_Instx86]
> ServiceType = %SERVICE_KERNEL_DRIVER%
> StartType = %SERVICE_DEMAND_START%
> ErrorControl = %SERVICE_ERROR_IGNORE%
> ServiceBinary = %12%\DirectDrv.sys
>
>
> [DirectIODriver.Files.x86_12]
> DirectDrv.sys
>
> [DirectIODriver_EventLog_Inst]
> AddReg = DirectIODriver_EventLog_Inst.AddReg
> [DirectIODriver_EventLog_Inst.AddReg]
> HKR,EventMessageFile,%REG_EXPAND_SZ%,“%%SystemRoot%%\System32\IoLogMsg.dll”
>
> HKR,TypesSupported,%REG_DWORD%,7
>
>
> [Strings]
>
> ;*******Localizable Strings
> mjtsai= “MjtsaiCorp”
> Desc_x860= “MjtsaiCorp Systemdrivers”
> DirectIODriverDesc= “Virtual Device 1.0.0.1 http:
> http: for Direct I/O Demo”
>
> USB\VID_04d8&PID_fe2c.DeviceDesc= “OSEC Robotics 2.0FS v2.3”
>
> ;
Non Localizable Strings *******
>
> SERVICE_BOOT_START = 0x0
> SERVICE_SYSTEM_START = 0x1
> SERVICE_AUTO_START = 0x2
> SERVICE_DEMAND_START = 0x3
> SERVICE_DISABLED = 0x4
>
> SERVICE_KERNEL_DRIVER = 0x1
> SERVICE_ERROR_IGNORE = 0x0
> SERVICE_ERROR_NORMAL = 0x1
> SERVICE_ERROR_SEVERE = 0x2
> SERVICE_ERROR_CRITICAL = 0x3
>
> REG_EXPAND_SZ = 0x00020000
> REG_DWORD = 0x00010001
>
> On Sat, Jun 7, 2008 at 4:52 PM, Martin O’Brien
>
> mailto:xxxxx> mailto:xxxxx>> wrote:
>
> How about you post your code.
>
>
> mm
>
> Paul Ryan wrote:
>
> After having gone down the suggested path for a couple of
> weeks
> I’m still no closer to finding the answer to my previous
> question. It was odd however that when running against the
> Process monitor, the Create file with my device name was
> never
> run. I’ve tried using the fopen that comes with Visual
> C++ 2008
> and mingw fopen port and both have a similar issue. When
> running
> with the mingw I don’t however get a Permission Denied
> message
> but rather an Invalid Argument. If I however pass a
> device like
> the LTP1 or COM1 devices to the fopen call there is no issue.
>
> Any help you can give on this issue would be greatly
> appreciated.
>
> Thanks,
>
> –
> Paul Ryan
> OSEC Robotics
> xxxxx@gmail.com mailto:xxxxx
> mailto:xxxxx>
> mailto:xxxxx
> mailto:xxxxx>>
>
>
>
> On Wed, Apr 30, 2008 at 12:13 PM, Paul Ryan
>
> mailto:xxxxx>
> mailto:xxxxx
>
> mailto:xxxxx>>>
> wrote:
>
> Thanks guys I’ll give those a try.
>
>
> On Wed, Apr 30, 2008 at 11:23 AM,
>
> mailto:xxxxx> mailto:xxxxx>
> mailto:xxxxx> mailto:xxxxx
> mailto:xxxxx> mailto:xxxxx>>> wrote:
>
> Or, if you don’t have the source of your runtime,
> Sysinternals’
> Process Monitor can capture the CreateFile flags
> for you too.
>
> -Stephen Cleary
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other
> seminars visit:
> http://www.osr.com/seminars
> http:
>
> To unsubscribe, visit the List Server section of OSR
> Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
> – Paul Ryan
> xxxxx@gmail.com mailto:xxxxx
> mailto:xxxxx>
> mailto:xxxxx
> mailto:xxxxx>>
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
> –
> Paul Ryan
> xxxxx@gmail.com mailto:xxxxx
> mailto:xxxxx>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
> –
> Paul Ryan
> xxxxx@gmail.com mailto:xxxxx</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></http:></http:>

Ok the user mode code is as follows:

#include <stdio.h>
#include <errno.h>
#include <string.h>

int main(int argc, char* argv)
{
//char* filename = argv[1];
char filename[256] = argv[1];
char* access = argv[2];
FILE* file = fopen(filename, access);

//while(true);

if (file == NULL)
{
printf(“Unable to open OSEC device %s for access %s - error %s\n”,
filename, access, strerror(errno));
return 1;
}

/HANDLE hdevice = CreateFile(filename, GENERIC_READ | GENERIC_WRITE, 0,
NULL, OPEN_EXISTING, 0, NULL);
if (hdevice == INVALID_HANDLE_VALUE)
{
printf(“Unable to open OSEC device %s for access %s - error %s\n”,
filename, access, strerror(GetLastError()));
return 1;
}
/
*/
//CloseHandle(hdevice);
fclose(file);
return 0;
}

As you can see it is really quite basic (I was just attempting to get the
basics to work first). There is a much more complex test suite for the
driver that we need to connect to once we get it talking to the device
correctly but with the problems I’m I having I decided to break it down into
the simplest case. Because the code above is so simple you may be correct
and I may just be looking at procmon incorrectly however I have it set to
show all calls from the client you see above.

Thanks,

Paul Ryan

On Sun, Jun 8, 2008 at 1:48 AM, Martin O’Brien
wrote:

> I think that we need to see your user mode code that calls
> fopen/CreateFile, because you’ve got something very fundamental incorrect
> here, or you’re not using the tools that you’ve used to determine that
> CreateFile is not being called correctly, which would be my guess.
>
> Thanks,
>
> mm
>
> Paul Ryan wrote:
>
>> Martin,
>>
>> Thanks for the earlier naming advice (I’ll look into the article and have
>> already started to see the advantage to it). Yes I’m new to windows device
>> drivers however I’ve done a bit of linux kernel hacking and have a pretty
>> extensive windows background (writing low level network protocols), but
>> again this is really my first foray into windows drivers (I’ve had the most
>> windows experience in our group so I got tagged with the task). So back to
>> the other statement about the user mode call, yes that is exactly the
>> behavior I’ve witnessed. When fopen is called it appears that at some point
>> another part of the process decides that my driver file is not proper and
>> throws an error back out without ever calling the CreateFile. I don’t have
>> the source to the CreateFile so I had to rely on the SysInternals Process
>> Monitor so it may be reporting wrong however when I run other devices I
>> definitely see it run the CreateFile. This is the reason I sent the INF
>> along with the earlier attached source code, it feels like a registry issue,
>> but then again this is my first time in this realm so I can’t be sure.
>>
>> Thanks,
>>
>> Paul Ryan
>>
>> On Sat, Jun 7, 2008 at 8:39 PM, Martin O’Brien >> xxxxx@evitechnology.com>> wrote:
>>
>> Let’s see the code that you’re using to try to open the device. If
>> I understand you correctly, it sounds like you’re saying that you’re
>> not seeing the user mode call, which is strange.
>>
>>
>> Thanks,
>>
>> mm
>>
>> Paul Ryan wrote:
>>
>> Martin,
>>
>> Of course sorry, I can do that, below is the driver entry and
>> create calls for the driver we’ve been trying to develop, as
>> well as the inf for loading this driver (this is derived from an
>> example from the code project at
>> http://www.codeproject.com/KB/system/WDM_Driver_development.aspx),
>> again thank you for your help with this. Of note with this
>> posted code is that we at this point are just trying to get our
>> test suite (written for unix) to talk to the device, then comes
>> the fun (hard part) of porting the driver control from unix. If
>> there is another peice of the code you think might be helpful I
>> can provide that as well, I was trying to keep this down to the
>> parts which I suspect are causing the problem so as not to send
>> a giant email.
>>
>> From the driver:
>>
>> NTSTATUS
>> DriverEntry(
>> IN PDRIVER_OBJECT DriverObject,
>> IN PUNICODE_STRING RegistryPath
>> )
>> {
>> DbgPrint(“In driver entry: begin\n”);
>> RtlInitUnicodeString(
>> &Global_sz_Drv_RegInfo,
>> RegistryPath->Buffer);
>> // Initialize function pointers
>>
>> DriverObject->DriverUnload = DriverUnload;
>> //DriverObject->DriverStartIo = (PVOID)StartIo;
>> DriverObject->DriverExtension->AddDevice = AddDevice;
>>
>> DriverObject->MajorFunction[IRP_MJ_CREATE] = PsdoDispatchCreate;
>> DriverObject->MajorFunction[IRP_MJ_CLOSE] = PsdoDispatchClose;
>> DriverObject->MajorFunction[IRP_MJ_READ] = PsdoDispatchRead;
>> DriverObject->MajorFunction[IRP_MJ_WRITE] = PsdoDispatchWrite;
>> DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] =
>> PsdoDispatchDeviceControl;
>> DriverObject->MajorFunction[IRP_MJ_POWER] = PsdoDispatchPower;
>> DriverObject->MajorFunction[IRP_MJ_PNP] = PsdoDispatchPnP;
>> DbgPrint(“In driver entry: end\n”);
>>
>> return STATUS_SUCCESS;
>> }
>>
>> NTSTATUS
>> AddDevice(
>> IN PDRIVER_OBJECT DriverObject,
>> IN PDEVICE_OBJECT PhysicalDeviceObject
>> )
>> {
>> ULONG DeviceExtensionSize;
>> PDEVICE_EXTENSION p_DVCEXT;
>> PDEVICE_OBJECT ptr_PDO;
>> NTSTATUS status;
>> UNICODE_STRING devname;
>> UNICODE_STRING dosdevname;
>> ULONG IdxPwrState;
>> static long lastIndex = -1;
>> long devIndex = InterlockedIncrement(&lastIndex);
>> WCHAR name[32];
>> WCHAR symname[32];
>>
>> DbgPrint(“*******************************Update 4\n”);
>> _snwprintf(name, 32, L"\Device\OSEC%d", devIndex);
>> _snwprintf(symname, 32, L"\DosDevices\OSEC%d", devIndex);
>> RtlInitUnicodeString(&devname, name);
>> RtlInitUnicodeString(&dosdevname, symname);
>> // TODO (pryan) point at actual device location.
>> DbgPrint(“Loading device in to \Device\OSEC%d file\n”,
>> devIndex);
>> //Get DEVICE_EXTENSION required memory space
>> DeviceExtensionSize = sizeof(DEVICE_EXTENSION);
>> status = IoCreateDevice(
>> DriverObject,
>> DeviceExtensionSize,
>> &devname,
>> FILE_DEVICE_UNKNOWN,
>> FILE_DEVICE_SECURE_OPEN,
>> TRUE,
>> &ptr_PDO
>> );
>>
>> if (NT_SUCCESS(status)) {
>>
>> ptr_PDO->Flags &= ~DO_DEVICE_INITIALIZING;
>> ptr_PDO->Flags |= DO_DIRECT_IO;
>> p_DVCEXT = ptr_PDO->DeviceExtension;
>> p_DVCEXT->DeviceObject = ptr_PDO;
>> RtlInitUnicodeString(
>> &p_DVCEXT->Device_Description,
>> L"This is a Direct I/O Driver for Pseudo Device\r\n"
>> L"Created by mjtsai 2003/8/4\r\n");
>> IoInitializeRemoveLock(
>> &p_DVCEXT->RemoveLock,
>> ‘KCOL’,
>> 0,
>> 0
>> );
>> p_DVCEXT->DataBuffer = ExAllocatePool(
>> NonPagedPool, 1024);
>> RtlZeroMemory(
>> p_DVCEXT->DataBuffer,
>> 1024);
>> //Initialize driver power state
>> p_DVCEXT->SysPwrState = PowerSystemWorking;
>> p_DVCEXT->DevPwrState = PowerDeviceD0;
>>
>> //Initialize device power information
>> Global_PowerInfo_Ptr = ExAllocatePool(
>> NonPagedPool, sizeof(DEVICE_POWER_INFORMATION));
>> RtlZeroMemory(
>> Global_PowerInfo_Ptr,
>> sizeof(DEVICE_POWER_INFORMATION));
>> Global_PowerInfo_Ptr->SupportQueryCapability = FALSE;
>> Global_PowerInfo_Ptr->DeviceD1 = 0;
>> Global_PowerInfo_Ptr->DeviceD2 = 0;
>> Global_PowerInfo_Ptr->WakeFromD0 = 0;
>> Global_PowerInfo_Ptr->WakeFromD1 = 0;
>> Global_PowerInfo_Ptr->WakeFromD2 = 0;
>> Global_PowerInfo_Ptr->WakeFromD3 = 0;
>> Global_PowerInfo_Ptr->DeviceWake = 0;
>> Global_PowerInfo_Ptr->SystemWake = 0;
>> for (IdxPwrState = 0;
>> IdxPwrState < PowerSystemMaximum;
>> IdxPwrState++)
>> {
>> Global_PowerInfo_Ptr->DeviceState[IdxPwrState] = 0;
>> }
>> //Store next-layered device object
>> //Attach device object to device stack
>> p_DVCEXT->NextDeviceObject =
>> IoAttachDeviceToDeviceStack(ptr_PDO,
>> PhysicalDeviceObject);
>> }
>> status = IoCreateSymbolicLink(&dosdevname, &devname);
>> if (!NT_SUCCESS(status)) {
>> DbgPrint(“Error creating symlink for device
>> \Device\OSEC%d to \DosDevices\OSEC%d\n”, devIndex, devIndex);
>> }
>>
>> return status;
>> }
>>
>> ; A:\DevInst.inf
>> ;
>> ; Created by GenINF.
>> ;
>> ;
>> [Version]
>> Signature = “$Windows NT$”
>> Class=System
>> ClassGUID={4d36e97d-e325-11ce-bfc1-08002be10318}
>> Provider=%osecrobotics%
>> CatalogFile=MyCat.cat
>> DriverVer= 8/4/2003
>>
>> [DestinationDirs]
>> DirectIODriver.Files.x86_12 = 12
>>
>> [SourceDisksNames.x86]
>> 0=%Desc_x860%
>>
>> [SourceDisksNames.ia64]
>>
>>
>> [SourceDisksFiles.x86]
>> DirectDrv.sys=0,
>>
>> [SourceDisksFiles.ia64]
>>
>>
>> [Manufacturer]
>> %osecrobotics%=osecrobotics
>>
>> [osecrobotics]
>>
>> %USB\VID_04d8&PID_fe2c.DeviceDesc%=DirectIODriver_Inst,USB\VID_04d8&PID_fe2c
>>
>> [DirectIODriver_Inst.ntx86]
>> CopyFiles = DirectIODriver.Files.x86_12
>>
>> [DirectIODriver_Inst.ntx86.Services]
>> AddService = DirectDrv,0x00000002,DirectIODriver_Service_Instx86,
>>
>> [DirectIODriver_Service_Instx86]
>> ServiceType = %SERVICE_KERNEL_DRIVER%
>> StartType = %SERVICE_DEMAND_START%
>> ErrorControl = %SERVICE_ERROR_IGNORE%
>> ServiceBinary = %12%\DirectDrv.sys
>>
>>
>> [DirectIODriver.Files.x86_12]
>> DirectDrv.sys
>>
>> [DirectIODriver_EventLog_Inst]
>> AddReg = DirectIODriver_EventLog_Inst.AddReg
>> [DirectIODriver_EventLog_Inst.AddReg]
>>
>> HKR,EventMessageFile,%REG_EXPAND_SZ%,“%%SystemRoot%%\System32\IoLogMsg.dll”
>>
>> HKR,TypesSupported,%REG_DWORD%,7
>>
>>
>> [Strings]
>>
>> ;*******Localizable Strings
>> mjtsai= “MjtsaiCorp”
>> Desc_x860= “MjtsaiCorp Systemdrivers”
>> DirectIODriverDesc= “Virtual Device 1.0.0.1 http:
>> http: for Direct I/O Demo”
>>
>> USB\VID_04d8&PID_fe2c.DeviceDesc= “OSEC Robotics 2.0FS v2.3”
>>
>> ;
Non Localizable Strings *******
>>
>> SERVICE_BOOT_START = 0x0
>> SERVICE_SYSTEM_START = 0x1
>> SERVICE_AUTO_START = 0x2
>> SERVICE_DEMAND_START = 0x3
>> SERVICE_DISABLED = 0x4
>>
>> SERVICE_KERNEL_DRIVER = 0x1
>> SERVICE_ERROR_IGNORE = 0x0
>> SERVICE_ERROR_NORMAL = 0x1
>> SERVICE_ERROR_SEVERE = 0x2
>> SERVICE_ERROR_CRITICAL = 0x3
>>
>> REG_EXPAND_SZ = 0x00020000
>> REG_DWORD = 0x00010001
>>
>> On Sat, Jun 7, 2008 at 4:52 PM, Martin O’Brien
>>
>> mailto:xxxxx>>
>> mailto:xxxxx>> wrote:
>>
>> How about you post your code.
>>
>>
>> mm
>>
>> Paul Ryan wrote:
>>
>> After having gone down the suggested path for a couple of
>> weeks
>> I’m still no closer to finding the answer to my previous
>> question. It was odd however that when running against the
>> Process monitor, the Create file with my device name was
>> never
>> run. I’ve tried using the fopen that comes with Visual
>> C++ 2008
>> and mingw fopen port and both have a similar issue. When
>> running
>> with the mingw I don’t however get a Permission Denied
>> message
>> but rather an Invalid Argument. If I however pass a
>> device like
>> the LTP1 or COM1 devices to the fopen call there is no
>> issue.
>>
>> Any help you can give on this issue would be greatly
>> appreciated.
>>
>> Thanks,
>>
>> –
>> Paul Ryan
>> OSEC Robotics
>> xxxxx@gmail.com mailto:xxxxx
>> mailto:xxxxx>
>> mailto:xxxxx
>> mailto:xxxxx>>
>>
>>
>>
>> On Wed, Apr 30, 2008 at 12:13 PM, Paul Ryan
>>
>> mailto:xxxxx>
>> mailto:xxxxx
>>
>> mailto:xxxxx>>>
>>
>> wrote:
>>
>> Thanks guys I’ll give those a try.
>>
>>
>> On Wed, Apr 30, 2008 at 11:23 AM,
>>
>> mailto:xxxxx>> mailto:xxxxx>
>> mailto:xxxxx>> mailto:xxxxx
>> mailto:xxxxx>> mailto:xxxxx>>> wrote:
>>
>> Or, if you don’t have the source of your runtime,
>> Sysinternals’
>> Process Monitor can capture the CreateFile flags
>> for you too.
>>
>> -Stephen Cleary
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other
>> seminars visit:
>> http://www.osr.com/seminars
>> http:
>>
>> To unsubscribe, visit the List Server section of OSR
>> Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>>
>> – Paul Ryan
>> xxxxx@gmail.com mailto:xxxxx
>> mailto:xxxxx>
>> mailto:xxxxx
>> mailto:xxxxx>>
>>
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars
>> visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>>
>> – Paul Ryan
>> xxxxx@gmail.com mailto:xxxxx
>> mailto:xxxxx>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>>
>> –
>> Paul Ryan
>> xxxxx@gmail.com mailto:xxxxx
>>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


Paul Ryan
xxxxx@gmail.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></http:></http:></string.h></errno.h></stdio.h>

Calling CreateFile directly works just fine as far as I can tell, however it
concerns me that a call as basic as fopen is failing (and with mutiple
implementations of fopen). I think this means there is something more
fundamentally wrong with my driver. Also as was stated in the original email
chain the point of using fopen is for portability of the user mode code.
Sorry if I’m just being a pain but I really do want to understand the
problem here.

Thanks,

Paul Ryan

On Sun, Jun 8, 2008 at 1:07 AM, Maxim S. Shatskih
wrote:

> > behavior I’ve witnessed. When fopen is called it appears that at some
> point
> > another part of the process decides that my driver file is not proper and
> > throws an error back out without ever calling the CreateFile.
>
> How about calling CreateFile directly?
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

OP (I assume you mean me but I’ve never seen that accronym)? However you are
correct that we need to send requests to the named device object thus the
reason for setting up the cyclic driver naming scheme with OSEC0 then OSEC1
etc. That code however is not complete in the driver I sent you, it will
contain an array of 0 to 256 allowing our users to connect up to 256 of our
boards. This was a design choice made by the gentleman who wrote the Linux
driver. Now back to you other statements, if I was to not do this I would
have to require my users to write a hundred or so lines of code just to
reference the individual devices correct vs just calling an fopen. Again
this comes back to a portability issue for our users that we are trying to
avoid. If we’ve made a horrible choice please explain why as your back and
forth above (while it makes sense that secondary device is more complicated
however may manage the requests better) is still a little confusing as to
what direction your suggesting I should take this code.

Thanks again for your time on this,

Paul Ryan

On Sun, Jun 8, 2008 at 12:50 AM, wrote:

> > Yes and if it is a conduit to hardware in the pnp state, you have to
> purge pending i/o when the pnp device >goes away. You potentially also have
> to coordinate power state as well. This can all be done…but why add >such
> complexity? Purely for a named devobj?
>
> Well, all the complexity that you have mentioned is implied not by the
> secondary device in itself but by the very fact that the OP wants to send
> PnP device the requests that are totally unrelated to PnP - this is why he
> needs a named devobj, in the first place. Therefore, even if he does not
> create a secondary device and, instead, just attaches the named devobj to
> the stack the way he currently does, it still does not save him from the
> pains that you have mentioned above. If you mean that accessing PnP device
> this way is not a very good idea… well, I do agree with you, but I am
> afraid this is his primary objective…
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>