Dear Scott,
Are you aware that packet writing software such as the one from my company
will still be able to use packet writing, as they send write10 and/or
write12 cdb directly, not using the IRP_MJ_WRITE?
Best regards,
David Burg
David Burg
Software Development,
InCD and Low Level Drivers Project Leader
Nero AG phone: +49 (0)7248 928 327 (room line) Internal VoIP
-363
Im Stoeckmaedle 18 fax: +49 (0)7248 928 299
76307 Karlsbad email: xxxxx@nero.com
Germany http://www.nero.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Windows System
Software Devs Interest List digest
Sent: Monday, May 23, 2005 7:00 AM
To: ntdev digest recipients
Subject: ntdev digest: May 22, 2005
NTDEV Digest for Sunday, May 22, 2005.
- CD /DVD read only filter
Subject: CD /DVD read only filter
From: =?ISO-2022-JP?B?GyRCJVYlaSUmJXMbKEIgGyRCJTklMyVDJUgbKEI=?=
Date: Mon, 23 May 2005 13:46:38 +0900 (JST)
X-Message-Number: 1
Dear Osrlist,
I am trying to write a filter driver which can block
attempts to copy data to a CD. For floppy disks and USB
thumbdrives I can use:
if(irpValue == IRP_MJ_WRITE){
NTSTATUS status = STATUS_MEDIA_WRITE_PROTECTED;
but this does not block attempts to burn data on to a CD
or DVD. Does anybody know what the CD equivalent of the
above code would be ?
Regards,
Scott
— Windows System Software Devs Interest List digest
$B$+$i$N%a%C%;!<%8!'(B
> NTDEV Digest for Saturday, May 21, 2005.
>
> 1. NO_MORE_IRP_STACK_LOCATIONS
> 2. Re: NO_MORE_IRP_STACK_LOCATIONS
> 3. RE: Complete Request in scsi miniport w/o
> timercall
> 4. RE: NO_MORE_IRP_STACK_LOCATIONS
>
>
----------------------------------------------------------------------
>
> Subject: NO_MORE_IRP_STACK_LOCATIONS
> From: “Cook, Mark” <mark.cook>
> Date: Sat, 21 May 2005 11:40:51 +0100
> X-Message-Number: 1
>
> This is a multi-part message in MIME format.
>
> ------=NextPart_001_01C55DF1.8EFEDF0A
> Content-Type: text/plain;
> charset=“us-ascii”
> Content-Transfer-Encoding: quoted-printable
>
> Hi all
>
> I’ve been developing a TDI filter driver that
> attaches to \Device\Tcp
> <file:> (among other things) using
> IoAttachDevice. It
> doesn’t currently do much apart from pass through
> any IRPs destined for
> the original device by calling IoCallDriver.
>
> =20
>
> Everything appears to work correctly until I attempt
> to make a NetBIOS
> call (in this case by typing net view at the command
> prompt). As soon as
> I do this, the system bugchecks with stop code 35
> (NO_MORE_IRP_STACK_LOCATIONS).
>
> =20
>
> Dumping the irp from the memory dump, I see the
> following (note that
> tdimon is my filter driver):
>
> =20
>
> Bugcheck code 00000035
>
> Arguments 862abc00 00000000 00000000 00000000
>
> =20
>
> kd> !irp 862abc00=20
>
> Irp is active with 2 stacks 0 is current (=3D
> 0x862baca0)
>
> No Mdl Thread 00000000: Irp stack trace. =20
>
> cmd flg cl Device File
> Completion-Context
>
> [f, 3] 0 e0 862baca0 86c6f170 f5162bf1-86af38c8
> Success Error
> Cancel=20
>
> \Driver\tdimon
> netbt!TcpConnectComplete
>
> Args: 00000000 86ca4578
> 00000000 f507bc50
>
> [f, 3] 0 e1 86ad8d30 86dffca0 f5165a8a-86c5d158
> Success Error
> Cancel pending
>
> \Driver\NetBT
> netbt!NbtpConnectCompletionRoutine
>
> Args: 00000000 86c5d168
> 00000000 f507bc50
>
> =20
>
> =20
>
> I have verified that when I call IoAttachDevice, the
> StackSize for my
> object increases to 2 (I am only attached to
> Device\TCP at this point
> which itself has a StackSize of 1) and I have
> verified that when the
> system bugchecks, this is still set to 2. In fact,
> if I dump the device
> stack for my device, it still appears to be correct:
>
> =20
>
> kd> !devstack 862baca0=20
>
> !DevObj !DrvObj !DevExt ObjectName
>
> > 862baca0 \Driver\tdimon 00000000 =20
>
> 86d29e50 \Driver\Tcpip 00000000 Tcp
>
> =20
>
> And using the dt against the DEVICE_OBJECTs for
> these two devices
> reveals that the stack sizes are set to 2 and 1
> respectively which also
> appears to be correct.
>
> =20
>
> =20
>
> From the IRP dump, it appears that one of the stack
> locations has been
> consumed by device 86ad8d30 but this device is not
> on my stack. In fact
> if I dump the device stack for this device, I see
> the following:
>
> =20
>
> kd> !devstack 86ad8d30=20
>
> !DevObj !DrvObj !DevExt ObjectName
>
> > 86ad8d30 \Driver\NetBT 86ad8de8
> NetBT_Tcpip{F941E083-3AC1-4540-883C-169D85D2FBD5}
>
> =20
>
> Curiously, when I run dt against this device, it
> also has a StackSize of
> 2 even though it doesn’t appear to be attached to
> anything.
>
> =20
>
> It appears to me that because this device has
> consumed one of the stack
> locations for my IRP, by the time it reaches my
> device the stack has
> been exhausted and when I call IoCallDriver, the
> system bugchecks. What
> I don’t see though is why this IRP would be going
> through the mysterious
> NetBT_Tcpip{F941E083-3AC1-4540-883C-169D85D2FBD5}
> device at all because
> it doesn’t seem to be in my driver stack.
>
> =20
>
> Does anybody have any ideas about why device
> NetBT_Tcpip_{F941E083-3AC1-4540-883C-169D85D2FBD5}
> is on my stack ??
>
> =20
>
> Kind Regards
>
> =20
>
> Mark
>
> =20
>
> =20
>
> =20
>
> =20
>
> =20
>
>
> ------_=_NextPart_001_01C55DF1.8EFEDF0A
> Content-Type: text/html;
> charset=“us-ascii”
> Content-Transfer-Encoding: quoted-printable
>
> > xmlns:o=3D"urn:schemas-microsoft-com:office:office"
> =
> xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
> xmlns=3D"http://www.w3.org/TR/REC-html40">
>
>
> > content=3D"text/html; =
> charset=3Dus-ascii">
> > (filtered medium)">
>
>
=== message truncated ==
__________________________________
Do You Yahoo!?
Upgrade Your Life
http://bb.yahoo.co.jp/
—
END OF DIGEST
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@nero.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</file:></mark.cook>