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.
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