ERROR_GEN_FAILURE when attempting CreateFile

Hello,

I’m a newbie at driver writing, and I’ve initially developed a file system
filter driver to do replication using the IFS filespy sample as the basis.
The DriverEntry call executes without error, but when my test user-mode
application attempts to get back a handle to the driver via CreateFile, I
get ERROR_GEN_FAILURE (0x1F). I can successfully load and get a handle
back from the native FileSpy driver. The error code ERROR_GEN_FAILURE
isn’t terribly useful. What am I doing wrong? What should I be looking
for? Thanks for any help.

I think you need to offer some more information.

(1) What device/file are you trying to open from your test app? The
filter device, a filter volume device.
(2) What is the name of your device (if you are opening your filter
device object) and how are you opening it? For example, if your
driver’s control device is “\device\foo” and you create a symbolic link
“myfoodriver”, are you opening the device from WIN32 using
\.\myfoodriver.
(3) Does you device object get a dos device symbolic link?
(4) Windows version and IFS kit version might be helpful - from the
perspective of providing some insight into what the filespy sample is
doing - assuming of course that you are using the filespy framework for
your filter’s control device object.

/TomH

-----Original Message-----
From: xxxxx@spursuits.com [mailto:xxxxx@spursuits.com]
Sent: Wednesday, January 29, 2003 7:22 PM
To: File Systems Developers
Subject: [ntfsd] ERROR_GEN_FAILURE when attempting CreateFile

Hello,

I’m a newbie at driver writing, and I’ve initially developed a file
system
filter driver to do replication using the IFS filespy sample as the
basis.
The DriverEntry call executes without error, but when my test user-mode
application attempts to get back a handle to the driver via CreateFile,
I
get ERROR_GEN_FAILURE (0x1F). I can successfully load and get a handle
back from the native FileSpy driver. The error code ERROR_GEN_FAILURE
isn’t terribly useful. What am I doing wrong? What should I be looking
for? Thanks for any help.


You are currently subscribed to ntfsd as: xxxxx@inflectionsystems.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Hi Tom,

Thanks for responding. In answer to your questions:

(1) The device I’m trying to open with the test app is a file system filter control device object. It is being opened the following way:

CHAR *sLinkName = “\\.\SPIFMon”;

hDevice = CreateFile(sLinkName,
GENERIC_READ | GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);

(2) The name of the control device is ‘\Device\SPIFmon’ and the symbolic link name is ‘\DosDevices\SPIFMon’. The device is being opened using the name ‘\.\SPIFMon’.

(3) Yes, using the API IoCreateSymbolicLink. This call succeeds.

(4) Windows version is 5.0.2195 (SP 2 Bld 2195) using the Windows 2000 IFS Kit.

Let me give you some more information that may or may not be useful. We brought in a contractor to initially build us a file system filter driver, and I’m now currently working with his results (he’s no longer available to support me…I’m *very* glad for ntfsd and people like you!). He’s based the DriverEntry routine from filespy almost to the letter. He assigned an initial device type to 0x1236, which I assume he just picked arbitrarily or just bumped up the filespy’s device type of 0x1235 by one. In any case, when I take the filespy code and assign it the same device names and types as I’ve specified above, and have it generate the same .sys name as my driver, my test app can successfully get back a handle from the device. If I take my driver and completely replace its DriverEntry routine with filespy’s, it still fails. I’ve tried the 0x1236 device type and tried a 0x8001 device type, with no luck. There are other objects that get compiled as part of the driver, and I’m at the point where I want to strip my driver down to just one object, to look more like filespy, and try that. Although I have no idea why other objects being compiled would have any effect on the success or failure of trying to get a device handle back.

Let me know if I can give you any more information, or if I haven’t sufficiently answered your questions, and thanks in advance for any help.

Regards,

Mike Wick
Developer; SPI

-----Original Message-----
From: Tom Hansen [mailto:xxxxx@inflectionsystems.com]
Sent: Thursday, January 30, 2003 7:17 AM
To: File Systems Developers
Subject: [ntfsd] RE: ERROR_GEN_FAILURE when attempting CreateFile

I think you need to offer some more information.

(1) What device/file are you trying to open from your test app? The
filter device, a filter volume device.
(2) What is the name of your device (if you are opening your filter
device object) and how are you opening it? For example, if your
driver’s control device is “\device\foo” and you create a symbolic link
“myfoodriver”, are you opening the device from WIN32 using
\.\myfoodriver.
(3) Does you device object get a dos device symbolic link?
(4) Windows version and IFS kit version might be helpful - from the
perspective of providing some insight into what the filespy sample is
doing - assuming of course that you are using the filespy framework for
your filter’s control device object.

/TomH

-----Original Message-----
From: xxxxx@spursuits.com [mailto:xxxxx@spursuits.com]
Sent: Wednesday, January 29, 2003 7:22 PM
To: File Systems Developers
Subject: [ntfsd] ERROR_GEN_FAILURE when attempting CreateFile

Hello,

I’m a newbie at driver writing, and I’ve initially developed a file
system
filter driver to do replication using the IFS filespy sample as the
basis.
The DriverEntry call executes without error, but when my test user-mode
application attempts to get back a handle to the driver via CreateFile,
I
get ERROR_GEN_FAILURE (0x1F). I can successfully load and get a handle
back from the native FileSpy driver. The error code ERROR_GEN_FAILURE
isn’t terribly useful. What am I doing wrong? What should I be looking
for? Thanks for any help.


You are currently subscribed to ntfsd as: xxxxx@inflectionsystems.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@spursuits.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Two more questions … do you have the kernel debugger setup so you can
set a breakpoint in your IRP_MJ_CREATE handler? It will become useful
to know whether the error is actually being returned by your driver or
by the i/o subsystem.

Also, have you tried looking at the object names on your target
computer? www.sysinternals.com provides a good object viewer that will
display the entire list of device and symbolic link object names on your
machine. The program is winobj.exe.

/TomH

-----Original Message-----
From: Mike Wick [mailto:xxxxx@spursuits.com]
Sent: Thursday, January 30, 2003 11:52 AM
To: File Systems Developers
Subject: [ntfsd] RE: ERROR_GEN_FAILURE when attempting CreateFile

Hi Tom,

Thanks for responding. In answer to your questions:

(1) The device I’m trying to open with the test app is a file system
filter control device object. It is being opened the following way:

CHAR *sLinkName = “\\.\SPIFMon”;

hDevice = CreateFile(sLinkName,
GENERIC_READ | GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);

(2) The name of the control device is ‘\Device\SPIFmon’ and the symbolic
link name is ‘\DosDevices\SPIFMon’. The device is being opened using
the name ‘\.\SPIFMon’.

(3) Yes, using the API IoCreateSymbolicLink. This call succeeds.

(4) Windows version is 5.0.2195 (SP 2 Bld 2195) using the Windows 2000
IFS Kit.

Let me give you some more information that may or may not be useful. We
brought in a contractor to initially build us a file system filter
driver, and I’m now currently working with his results (he’s no longer
available to support me…I’m *very* glad for ntfsd and people like
you!). He’s based the DriverEntry routine from filespy almost to the
letter. He assigned an initial device type to 0x1236, which I assume he
just picked arbitrarily or just bumped up the filespy’s device type of
0x1235 by one. In any case, when I take the filespy code and assign it
the same device names and types as I’ve specified above, and have it
generate the same .sys name as my driver, my test app can successfully
get back a handle from the device. If I take my driver and completely
replace its DriverEntry routine with filespy’s, it still fails. I’ve
tried the 0x1236 device type and tried a 0x8001 device type, with no
luck. There are other objects that get compiled as part of the driver,
and I’m at the point where I want to strip my driver down to just one
object, to look more like filespy, and try that. Although I have no
idea why other objects being compiled would have any effect on the
success or failure of trying to get a device handle back.

Let me know if I can give you any more information, or if I haven’t
sufficiently answered your questions, and thanks in advance for any
help.

Regards,

Mike Wick
Developer; SPI

-----Original Message-----
From: Tom Hansen [mailto:xxxxx@inflectionsystems.com]
Sent: Thursday, January 30, 2003 7:17 AM
To: File Systems Developers
Subject: [ntfsd] RE: ERROR_GEN_FAILURE when attempting CreateFile

I think you need to offer some more information.

(1) What device/file are you trying to open from your test app? The
filter device, a filter volume device.
(2) What is the name of your device (if you are opening your filter
device object) and how are you opening it? For example, if your
driver’s control device is “\device\foo” and you create a symbolic link
“myfoodriver”, are you opening the device from WIN32 using
\.\myfoodriver.
(3) Does you device object get a dos device symbolic link?
(4) Windows version and IFS kit version might be helpful - from the
perspective of providing some insight into what the filespy sample is
doing - assuming of course that you are using the filespy framework for
your filter’s control device object.

/TomH

-----Original Message-----
From: xxxxx@spursuits.com [mailto:xxxxx@spursuits.com]
Sent: Wednesday, January 29, 2003 7:22 PM
To: File Systems Developers
Subject: [ntfsd] ERROR_GEN_FAILURE when attempting CreateFile

Hello,

I’m a newbie at driver writing, and I’ve initially developed a file
system
filter driver to do replication using the IFS filespy sample as the
basis.
The DriverEntry call executes without error, but when my test user-mode
application attempts to get back a handle to the driver via CreateFile,
I
get ERROR_GEN_FAILURE (0x1F). I can successfully load and get a handle
back from the native FileSpy driver. The error code ERROR_GEN_FAILURE
isn’t terribly useful. What am I doing wrong? What should I be looking
for? Thanks for any help.


You are currently subscribed to ntfsd as: xxxxx@inflectionsystems.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@spursuits.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@inflectionsystems.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

In your filter’s create handler are you checking for requests to open
your filter’s control device object and succeeding those requests?
Generally what is done is a filter will identify the device objects it
creates by placing a constant somewhere in the device extension it
allocated when it called IoCreateDevice. Requests against the volume
filter device objects should be passed down to the lower device, while
requests against the control device are generally failed for everything
but create, cleanup, and close (all three which you succeed), and device
IO control (in which you process whatever IOCTLs your app sends you).

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Wick
Sent: Thursday, January 30, 2003 8:52 AM
To: File Systems Developers
Subject: [ntfsd] RE: ERROR_GEN_FAILURE when attempting CreateFile

Hi Tom,

Thanks for responding. In answer to your questions:

(1) The device I’m trying to open with the test app is a file
system filter control device object. It is being opened the
following way:

CHAR *sLinkName = “\\.\SPIFMon”;

hDevice = CreateFile(sLinkName,
GENERIC_READ | GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);

(2) The name of the control device is ‘\Device\SPIFmon’ and
the symbolic link name is ‘\DosDevices\SPIFMon’. The device
is being opened using the name ‘\.\SPIFMon’.

(3) Yes, using the API IoCreateSymbolicLink. This call succeeds.

(4) Windows version is 5.0.2195 (SP 2 Bld 2195) using the
Windows 2000 IFS Kit.

Let me give you some more information that may or may not be
useful. We brought in a contractor to initially build us a
file system filter driver, and I’m now currently working with
his results (he’s no longer available to support me…I’m
*very* glad for ntfsd and people like you!). He’s based the
DriverEntry routine from filespy almost to the letter. He
assigned an initial device type to 0x1236, which I assume he
just picked arbitrarily or just bumped up the filespy’s
device type of 0x1235 by one. In any case, when I take the
filespy code and assign it the same device names and types as
I’ve specified above, and have it generate the same .sys name
as my driver, my test app can successfully get back a handle
from the device. If I take my driver and completely replace
its DriverEntry routine with filespy’s, it still fails. I’ve
tried the 0x1236 device type and tried a 0x8001 device type,
with no luck. There are other objects that get compiled as
part of the driver, and I’m at the point where I want to
strip my driver down to just one object, to look more like
filespy, and try that. Although I have no idea why other
objects being compiled would have any effect on the success
or failure of trying to get a device handle back.

Let me know if I can give you any more information, or if I
haven’t sufficiently answered your questions, and thanks in
advance for any help.

Regards,

Mike Wick
Developer; SPI

-----Original Message-----
From: Tom Hansen [mailto:xxxxx@inflectionsystems.com]
Sent: Thursday, January 30, 2003 7:17 AM
To: File Systems Developers
Subject: [ntfsd] RE: ERROR_GEN_FAILURE when attempting CreateFile

I think you need to offer some more information.

(1) What device/file are you trying to open from your test
app? The filter device, a filter volume device.
(2) What is the name of your device (if you are opening your
filter device object) and how are you opening it? For
example, if your driver’s control device is “\device\foo” and
you create a symbolic link “myfoodriver”, are you opening the
device from WIN32 using \.\myfoodriver.
(3) Does you device object get a dos device symbolic link?
(4) Windows version and IFS kit version might be helpful -
from the perspective of providing some insight into what the
filespy sample is doing - assuming of course that you are
using the filespy framework for your filter’s control device object.

/TomH

-----Original Message-----
From: xxxxx@spursuits.com [mailto:xxxxx@spursuits.com]
Sent: Wednesday, January 29, 2003 7:22 PM
To: File Systems Developers
Subject: [ntfsd] ERROR_GEN_FAILURE when attempting CreateFile

Hello,

I’m a newbie at driver writing, and I’ve initially developed
a file system filter driver to do replication using the IFS
filespy sample as the basis. The DriverEntry call executes
without error, but when my test user-mode application
attempts to get back a handle to the driver via CreateFile, I
get ERROR_GEN_FAILURE (0x1F). I can successfully load and
get a handle back from the native FileSpy driver. The error
code ERROR_GEN_FAILURE isn’t terribly useful. What am I
doing wrong? What should I be looking for? Thanks for any help.


You are currently subscribed to ntfsd as:
xxxxx@inflectionsystems.com To unsubscribe send a blank
email to xxxxx@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@spursuits.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Tom,

After taking your advice and setting a breakpoint at the IRP_MJ_CREATE handler, I can see that I’m actually entering the driver’s handler and that the driver itself is returning back the error code. So that was it. Thank you very much.

Regards,

Mike Wick
Developer; SPI

-----Original Message-----
From: Tom Hansen [mailto:xxxxx@inflectionsystems.com]
Sent: Thursday, January 30, 2003 10:00 AM
To: File Systems Developers
Subject: ***SPAM***[ntfsd] RE: ERROR_GEN_FAILURE when attempting
CreateFile

Two more questions … do you have the kernel debugger setup so you can
set a breakpoint in your IRP_MJ_CREATE handler? It will become useful
to know whether the error is actually being returned by your driver or
by the i/o subsystem.

Also, have you tried looking at the object names on your target
computer? www.sysinternals.com provides a good object viewer that will
display the entire list of device and symbolic link object names on your
machine. The program is winobj.exe.

/TomH

-----Original Message-----
From: Mike Wick [mailto:xxxxx@spursuits.com]
Sent: Thursday, January 30, 2003 11:52 AM
To: File Systems Developers
Subject: [ntfsd] RE: ERROR_GEN_FAILURE when attempting CreateFile

Hi Tom,

Thanks for responding. In answer to your questions:

(1) The device I’m trying to open with the test app is a file system
filter control device object. It is being opened the following way:

CHAR *sLinkName = “\\.\SPIFMon”;

hDevice = CreateFile(sLinkName,
GENERIC_READ | GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);

(2) The name of the control device is ‘\Device\SPIFmon’ and the symbolic
link name is ‘\DosDevices\SPIFMon’. The device is being opened using
the name ‘\.\SPIFMon’.

(3) Yes, using the API IoCreateSymbolicLink. This call succeeds.

(4) Windows version is 5.0.2195 (SP 2 Bld 2195) using the Windows 2000
IFS Kit.

Let me give you some more information that may or may not be useful. We
brought in a contractor to initially build us a file system filter
driver, and I’m now currently working with his results (he’s no longer
available to support me…I’m *very* glad for ntfsd and people like
you!). He’s based the DriverEntry routine from filespy almost to the
letter. He assigned an initial device type to 0x1236, which I assume he
just picked arbitrarily or just bumped up the filespy’s device type of
0x1235 by one. In any case, when I take the filespy code and assign it
the same device names and types as I’ve specified above, and have it
generate the same .sys name as my driver, my test app can successfully
get back a handle from the device. If I take my driver and completely
replace its DriverEntry routine with filespy’s, it still fails. I’ve
tried the 0x1236 device type and tried a 0x8001 device type, with no
luck. There are other objects that get compiled as part of the driver,
and I’m at the point where I want to strip my driver down to just one
object, to look more like filespy, and try that. Although I have no
idea why other objects being compiled would have any effect on the
success or failure of trying to get a device handle back.

Let me know if I can give you any more information, or if I haven’t
sufficiently answered your questions, and thanks in advance for any
help.

Regards,

Mike Wick
Developer; SPI

-----Original Message-----
From: Tom Hansen [mailto:xxxxx@inflectionsystems.com]
Sent: Thursday, January 30, 2003 7:17 AM
To: File Systems Developers
Subject: [ntfsd] RE: ERROR_GEN_FAILURE when attempting CreateFile

I think you need to offer some more information.

(1) What device/file are you trying to open from your test app? The
filter device, a filter volume device.
(2) What is the name of your device (if you are opening your filter
device object) and how are you opening it? For example, if your
driver’s control device is “\device\foo” and you create a symbolic link
“myfoodriver”, are you opening the device from WIN32 using
\.\myfoodriver.
(3) Does you device object get a dos device symbolic link?
(4) Windows version and IFS kit version might be helpful - from the
perspective of providing some insight into what the filespy sample is
doing - assuming of course that you are using the filespy framework for
your filter’s control device object.

/TomH

-----Original Message-----
From: xxxxx@spursuits.com [mailto:xxxxx@spursuits.com]
Sent: Wednesday, January 29, 2003 7:22 PM
To: File Systems Developers
Subject: [ntfsd] ERROR_GEN_FAILURE when attempting CreateFile

Hello,

I’m a newbie at driver writing, and I’ve initially developed a file
system
filter driver to do replication using the IFS filespy sample as the
basis.
The DriverEntry call executes without error, but when my test user-mode
application attempts to get back a handle to the driver via CreateFile,
I
get ERROR_GEN_FAILURE (0x1F). I can successfully load and get a handle
back from the native FileSpy driver. The error code ERROR_GEN_FAILURE
isn’t terribly useful. What am I doing wrong? What should I be looking
for? Thanks for any help.


You are currently subscribed to ntfsd as: xxxxx@inflectionsystems.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@spursuits.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@inflectionsystems.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@spursuits.com
To unsubscribe send a blank email to xxxxx@lists.osr.com