Issue with DRIVER_VERIFIER_IOMANAGER_VIOLATION

Hey guys,

I am doing some testing with Driver Verifier enabled and I keep coming
across a “Bugcheck C9, {c, f789db34, 0, 0}”.

From the DDK docs I understand that this is telling me that:

Arg 1: 0x0C… Invalid IOSB in IRP at APC IopCompleteRequest (appears
to be on a stack that was unwound)

Arg 2: The actual IOSB pointer

So what does this actually mean? The stack backtrace shows this dieing
at the end of my Create() routine when I am doing a “return
IoCallDriver(…);”. I am not modifying the IOSB of the Irp, so why is
this triggering?

Anyone have any ideas how I would go about diagnosing this further?


Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]

You are most likely calling the file system with APCs disabled
(FsRtlEnterFileSystem). IoCompleteRequest queues an APC to fill in the
IOSB, but the APC cannot run immediately. By the time it does, the stack
has been unwound, and the IOSB is “gone”.

Enable APCs before calling IoCallDriver.

  • Dan.

At 06:25 PM 5/25/2004 -0700, you wrote:

Hey guys,

I am doing some testing with Driver Verifier enabled and I keep coming
across a “Bugcheck C9, {c, f789db34, 0, 0}”.

From the DDK docs I understand that this is telling me that:

Arg 1: 0x0C… Invalid IOSB in IRP at APC IopCompleteRequest (appears to
be on a stack that was unwound)

Arg 2: The actual IOSB pointer

So what does this actually mean? The stack backtrace shows this dieing at
the end of my Create() routine when I am doing a “return
IoCallDriver(…);”. I am not modifying the IOSB of the Irp, so why is this
triggering?

Anyone have any ideas how I would go about diagnosing this further?


Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

Dana,

I know this was posted a while ago but I am wondering if you resolved
this issue.

Are you generating your own IRP while processing the Create Operation?
Was this across a network share using DFS? If so I am guessing that you
are setting the OriginalFileObject field in that IRP. This can cause
the exact problem you describe.

Everyone, it is wrong for a filter, when generating their own IRP, to
set the OriginalFileObject field. This is a field that should only be
set by the IO Manager. If you have a product that is doing this please
fix it ASAP. It will cause these types of failures when interoperating
with DFS.

Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Wednesday, May 26, 2004 6:50 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Issue with DRIVER_VERIFIER_IOMANAGER_VIOLATION

You are most likely calling the file system with APCs disabled
(FsRtlEnterFileSystem). IoCompleteRequest queues an APC to fill in the
IOSB, but the APC cannot run immediately. By the time it does, the
stack
has been unwound, and the IOSB is “gone”.

Enable APCs before calling IoCallDriver.

  • Dan.

At 06:25 PM 5/25/2004 -0700, you wrote:

Hey guys,

I am doing some testing with Driver Verifier enabled and I keep coming
across a “Bugcheck C9, {c, f789db34, 0, 0}”.

From the DDK docs I understand that this is telling me that:

Arg 1: 0x0C… Invalid IOSB in IRP at APC IopCompleteRequest (appears
to
be on a stack that was unwound)

Arg 2: The actual IOSB pointer

So what does this actually mean? The stack backtrace shows this dieing
at
the end of my Create() routine when I am doing a “return
IoCallDriver(…);”. I am not modifying the IOSB of the Irp, so why is
this
triggering?

Anyone have any ideas how I would go about diagnosing this further?


Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

Neal,

Everyone, it is wrong for a filter, when generating their own IRP, to
set the OriginalFileObject field. This is a field that should only be
set by the IO Manager.

This is good to know. So this field should be set to NULL by the
filter which has rolled the IRP ?

L.

Yes – set this field to NULL if you are generating your own IRP.

Molly Brown
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Tuesday, June 22, 2004 12:39 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Issue with DRIVER_VERIFIER_IOMANAGER_VIOLATION

Neal,

Everyone, it is wrong for a filter, when generating their own IRP, to
set the OriginalFileObject field. This is a field that should only be
set by the IO Manager.

This is good to know. So this field should be set to NULL by the
filter which has rolled the IRP ?

L.


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

Neal,
Is this true of every kind of IRP (Create, Query, Read, Write) etc?
Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neal Christiansen
Sent: Monday, June 21, 2004 2:59 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Issue with DRIVER_VERIFIER_IOMANAGER_VIOLATION

Dana,

I know this was posted a while ago but I am wondering if you resolved
this issue.

Are you generating your own IRP while processing the Create Operation?
Was this across a network share using DFS? If so I am guessing that you
are setting the OriginalFileObject field in that IRP. This can cause
the exact problem you describe.

Everyone, it is wrong for a filter, when generating their own IRP, to
set the OriginalFileObject field. This is a field that should only be
set by the IO Manager. If you have a product that is doing this please
fix it ASAP. It will cause these types of failures when interoperating
with DFS.

Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Wednesday, May 26, 2004 6:50 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Issue with DRIVER_VERIFIER_IOMANAGER_VIOLATION

You are most likely calling the file system with APCs disabled
(FsRtlEnterFileSystem). IoCompleteRequest queues an APC to fill in the
IOSB, but the APC cannot run immediately. By the time it does, the
stack
has been unwound, and the IOSB is “gone”.

Enable APCs before calling IoCallDriver.

  • Dan.

At 06:25 PM 5/25/2004 -0700, you wrote:

Hey guys,

I am doing some testing with Driver Verifier enabled and I keep coming
across a “Bugcheck C9, {c, f789db34, 0, 0}”.

From the DDK docs I understand that this is telling me that:

Arg 1: 0x0C… Invalid IOSB in IRP at APC IopCompleteRequest (appears
to
be on a stack that was unwound)

Arg 2: The actual IOSB pointer

So what does this actually mean? The stack backtrace shows this dieing
at
the end of my Create() routine when I am doing a “return
IoCallDriver(…);”. I am not modifying the IOSB of the Irp, so why is
this
triggering?

Anyone have any ideas how I would go about diagnosing this further?


Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

Hi Ken,

Yes, this is true for every type of IRP. It wasn’t always this way, but
at some point in the distant past it became true (the usage pattern here
changed).

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Tuesday, June 22, 2004 3:40 PM
To: ntfsd redirect
Subject: RE: [ntfsd] Issue with DRIVER_VERIFIER_IOMANAGER_VIOLATION

Neal,
Is this true of every kind of IRP (Create, Query, Read, Write) etc?
Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neal Christiansen

Sent: Monday, June 21, 2004 2:59 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Issue with DRIVER_VERIFIER_IOMANAGER_VIOLATION

Dana,

I know this was posted a while ago but I am wondering if you resolved
this issue.

Are you generating your own IRP while processing the Create Operation?
Was this across a network share using DFS? If so I am guessing that you

are setting the OriginalFileObject field in that IRP. This can cause
the exact problem you describe.

Everyone, it is wrong for a filter, when generating their own IRP, to
set the OriginalFileObject field. This is a field that should only be
set by the IO Manager. If you have a product that is doing this please
fix it ASAP. It will cause these types of failures when interoperating
with DFS.

Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Wednesday, May 26, 2004 6:50 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Issue with DRIVER_VERIFIER_IOMANAGER_VIOLATION

You are most likely calling the file system with APCs disabled
(FsRtlEnterFileSystem). IoCompleteRequest queues an APC to fill in the
IOSB, but the APC cannot run immediately. By the time it does, the
stack
has been unwound, and the IOSB is “gone”.

Enable APCs before calling IoCallDriver.

  • Dan.

At 06:25 PM 5/25/2004 -0700, you wrote:

Hey guys,

I am doing some testing with Driver Verifier enabled and I keep coming
across a “Bugcheck C9, {c, f789db34, 0, 0}”.

From the DDK docs I understand that this is telling me that:

Arg 1: 0x0C… Invalid IOSB in IRP at APC IopCompleteRequest (appears
to
be on a stack that was unwound)

Arg 2: The actual IOSB pointer

So what does this actually mean? The stack backtrace shows this dieing
at
the end of my Create() routine when I am doing a “return
IoCallDriver(…);”. I am not modifying the IOSB of the Irp, so why is
this
triggering?

Anyone have any ideas how I would go about diagnosing this further?


Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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