> So what? They both use SPTI (either directly as IMAPI or thru ASPI wrapper
as Nero).
IMAPI has its own filter very low in the stack. Nero sends SPTI from user mode.
Did you test them all with your filter?
I install as the lowest just above the storage port PDO by playing with device
LowerFilters value.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
c000003c == STATUS_DATA_OVERRUN
This status is (I believe) auto-converted to STATUS_SUCCESS if you use
the IOCTL version. Check the DDK sources to see the
CdRomDeviceControlCompletion() and CdRomGetConfigCompletion() in the
CDROM sample for “proof” (or to prove me wrong ;)).
.
-----Original Message-----
From: Handal, Thomas [mailto:xxxxx@websense.com]
Sent: Tuesday, February 08, 2005 2:28 PM
Subject: RE: IOCTL_IS_DISK_WRITABLE Problem with CD’s
Quick Update…
Ok, I didn’t Zero the input buffer memory… that seemed to take care of
the invalid parameter problem. Now I am getting a C000003C error code
back. I am not sure why I am getting this…
Help please?
Thanks
Tom
Hi Aton,
This was seen during the development cycle of XP. The way we detect
it is not with a drive list, but rather dynamically (and then store in
the registry so we don’t do it again). You can look at the DDK source
for CDROM.SYS, specifically the function CdRomIsDeviceMmcDevice() in
MMC.C, to see how this is detected. I don’t recall the exact
model/firmware revision this was first found on, but it affected many
inquiry data (based on that one drive). I’m trying to keep away from
“drive lists”, as they’re rather person-time expensive.
I understand the filter driver problem; Unfortunately it’s actually
made worse by sending directly to the PDO, because then people start
messing with the PDO dispatch tables to “really” get stuff, and then to
workaround that, … Part of my work here at Microsoft is focusing on
fixing this filter driver problem for optical devices (and yes, I know
XP’s IMAPI.SYS is problematic – working on that too!).
You’re right.
Glad to see we do, indeed, agree. I’ll start a conversation off-thread
to see if we can help each other wrt these filter driver problems… 
.
-----Original Message-----
From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]
Sent: Monday, February 07, 2005 10:12 PM
Subject: RE: RE:IOCTL_IS_DISK_WRITABLE Problem with CD’s
Henry,
Selling CD/DVD burning software for past 6 years. Never seen single
device hanging with “get configuration” sent to it… I’m wonder - how
do you workaround this? )) Can you also tell device(s) INQUIRY data
(maybe in a private message, I don’t think other guys would be
interested).
About sending IRPs directly to PDO. It’s b/s there are too many ugly
SCSI filters (like the ones Adaptec has). Also we’re quite ofter
absolutely not happy with somebody else reverse-engineering our
applications beholding SCSI traffic. However I agree this is
“problematic” way.
In general every single application “talking” directly to hardware
would end with either own device database or at least with hardcoded
INQUIRY data into application. With all of the codepathes dirrerent
depending upon current device.
Regards,
Anton Kolomyeytsev
CEO, Rocket Division Software
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry Gabryjelski
Sent: Monday, February 07, 2005 8:26 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] RE:IOCTL_IS_DISK_WRITABLE Problem with CD’s
There are many reasons READ_DISC_INFO would fail. Worse, READ_DISC_INFO
does not indicate if you have writable media. This is not the correct
path to follow for all media types, although this will generally work if
you are looking at CD-R/RW media.
Handal, please see my previous post (I only get archives, so my
responses are delayed 24 hours) for a link to the MMC specification and
a nice IOCTL to use GET_CONFIGURATION. Also, be careful with sending
MODE_SENSE.
There’s a lot of problems in that:
(*) Some devices only support MODE_SENSE6 (now rare, legacy only)
(*) Some devices return a block header, even if DBD bit is set (now
rare, legacy only)
That’s just off the top of my head. Again, sending commands directly to
CD/DVD devices is inherently tricky. Although it may work well on a
brand-name drive, there are hundreds of models of drives on the market,
and many of them have little quirks that need to be worked around. It’s
very difficult and time-consuming to write code that works on all drives
on the market. If you only need to work with a known set of drives (for
internal corporate use, for example), then you can do this relatively
easily. If you want to release for the world to use, I’d suggest
staying in “beta” for a few years. 
Hth,
.
-----Original Message-----
From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]
Sent: Friday, February 04, 2005 12:51 PM
Subject: RE: RE:IOCTL_IS_DISK_WRITABLE Problem with CD’s
Bad idea. Device performing async command would fail READ DISC INFO.
Regards,
Anton Kolomyeytsev
CEO, Rocket Division Software
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Friday, February 04, 2005 10:36 PM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] IOCTL_IS_DISK_WRITABLE Problem with CD’s
READ DISC INFORMATION SCSI command will tell you whether the disk
inserted is writeable or not.
I know that CDFS supports writes. I also know on IMAPI feature.
Possibly (but not necessary) it is implemented as writes to CDFS, and
then commit to the media using IMAPI.SYS driver. Possibly not so.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Handal, Thomas mailto:xxxxx
To: Windows System Software Devs Interest List
mailto:xxxxx
Sent: Friday, February 04, 2005 10:28 PM
Subject: RE:[ntdev] IOCTL_IS_DISK_WRITABLE Problem with CD’s
Hi Henry,
Thanks for your reply. I don’t believe that there are any
third party apps on the CD/DVD stack. I have tried the driver I wrote on
3 or 4 machines and they all have the same result. Is there any other
way to determine if a CD drive is writable or not? How about detecting
if it is a CD-ROM or CD-R/RW, etc? Also for DVD-ROM or DVD-RAM? I’ve
tried everything so far that I can think of:
1. Getting description of device and looking for “ROM” -
that won’t work
2. IOCTL_IS_DISK_WRITABLE - doesn’t work for CDs…
3. Characteristics & FILE_READ_ONLY_VOLUME in kernel -
doesn’t work and also stated as “Unreliable” by Neil Christiansen
4. Tried asking it nicely… that doesn’t work either…
5. Whacked it with a baseball bat a few times… stopped
spinning-up… that wasn’t good… got a new one and asked it nicely…
but that didn’t work…
I am SOO lost here… and it seems that it should be such a
SIMPLE thing… I have run out of hair to pull… please help me!
Please tell me about some new undocumented saving function!!!
PLEASE!!!
Thanks
Tom
On 04 Feb 2005, you wrote in ntdev:
> Hi Tom,
>
> First question I would have to ask is, do you have any third
party
> software installed? If so, does this still happen when you
use a clean
> installation of Windows XP? Finally, is this restricted to a
single
> type of CD/DVD drive (i.e. only drives from one vendor)?
>
> This behavior certainly seems unusual, and is not what I would
expect
> either. Two possibilities are:
>
> (A) 3rd party software on the CD/DVD stack may modify the
results of
> this IOCTL.
>
> (B) The firmware on the device reports that it is always a
randomly
> writable, hardware defect managed media.
>
> Looking forward to hearing your results.
> .
>
> -----Original Message-----
> From: Handal, Thomas [mailto:xxxxx@websense.com]
> Sent: Thursday, February 03, 2005 1:59 PM
> Subject: IOCTL_IS_DISK_WRITABLE Problem with CD’s
>
> Hi all
>
>
>
> I am having a problem with the IOCTL_IS_DISK_WRITABLE
call. It
> works great with Floppy’s and Removable thumb drives, etc. But
for CD’s,
> I am having a problem. It does not matter if the drive is a
CD-ROM/RW/R
> or whatever. The problem that I am having is that regardless
of what CD
> media I am using, (burnt, stamped, etc.) it ALWAYS says it is
WRITABLE.
> I don’t understand why. Can anyone shed some light on this and
how to
> get around it?
>
>
>
> Thanks in advance… I truly appreciate any help…
>
> Tom
>
>
>
Tom Handal
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx>
This topic was discussed here some time ago. Try searching the archives.
What are you going to do with hook-based SCSI filters? Something like
BusHound f.e.? I know and agree SCSI and NDIS
hook-based filters are quite an evil but you cannot just ignore tons of the
software based on this design. Any ideas?
Regards,
Anton Kolomyeytsev
CEO, Rocket Division Software
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Wednesday, February 09, 2005 2:23 PM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] RE:IOCTL_IS_DISK_WRITABLE Problem with CD’s
So what? They both use SPTI (either directly as IMAPI or thru ASPI
wrapper as Nero).
IMAPI has its own filter very low in the stack. Nero sends SPTI from user
mode.
Did you test them all with your filter?
I install as the lowest just above the storage port PDO by playing with
device LowerFilters value.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@cooldev.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
Ok, I am now calling the IOCTL successfully and I get a STATUS_SUCCESS
back… That only took about 3 days… Now, I am having trouble parsing
the data that has come back. I get the GET_CONFIGURATION_HEADER and the
DataLength field is 16. That is wonderful. When I look at the feature
header, everything is 0. That is not good.
Please help
Thanks
Tom
Hi All Again
I really need to figure this out… the code is below… I am
getting STATUS_SUCCESS from IoCallDriver, so I know the IOCTL works. The
iosb.Information is = 8, which I believe is very small. Please, someone
help. I am using the functions from mmc.c file that I found in the DDK,
which apparently parse the Feature information, but they are not
working. It runs and gives me the first output about how there are so
many bytes at this address, blah blah… None of the features are
getting printed. I think it all has to do with the ioctl giving back 8
bytes. I am not getting all the information…
PLEASE HELP!!! AHH!!!
Thanks
Tom
PCHAR buffer;
GET_CONFIGURATION_IOCTL_INPUT
getConfIoctlInput;
PGET_CONFIGURATION_HEADER header;
PFEATURE_HEADER fheader;
ULONG count;
ULONG bufSize =
sizeof(GET_CONFIGURATION_HEADER);
BOOLEAN CdRomReadOnly = TRUE;
ULONG length;
USHORT feature;
buffer =
(PCHAR)ExAllocatePool(NonPagedPool, 1024);
if ( ! buffer )
return CdRomReadOnly;
memset((PVOID) &getConfIoctlInput,
0, sizeof(GET_CONFIGURATION_IOCTL_INPUT));
getConfIoctlInput.Feature =
FeatureProfileList;
getConfIoctlInput.RequestType =
SCSI_GET_CONFIGURATION_REQUEST_TYPE_CURRENT;
memset((PVOID) buffer, 0, 1024);
KeInitializeEvent( &event,
NotificationEvent, FALSE );
irp =
IoBuildDeviceIoControlRequest(IOCTL_CDROM_GET_CONFIGURATION,
diskDeviceObject,
&getConfIoctlInput,
sizeof(GET_CONFIGURATION_IOCTL_INPUT),
buffer,
bufSize,
FALSE,
&event,
&iosb);
//
// If we could not allocate an IRP,
return an error
//
if (irp == NULL)
{
goto EXIT_CDROM_CHECK;
}
//
// Call the storage stack and see
if this is readonly
//
status = IoCallDriver(
diskDeviceObject, irp );
if (status == STATUS_PENDING)
{
(VOID)KeWaitForSingleObject( &event,
Executive,
KernelMode,
FALSE,
NULL );
status = iosb.Status;
}
bufSize = iosb.Information;
KdPrint((“*** IOSB.Information =
%d\n”, bufSize));
KdPrint((“*** STATUS = %X\n”,
status));
// Return code of
STATUS_DATA_OVERRUN is NOT an error for this IOCTL
if ( ! ( NT_SUCCESS(status) ||
status == STATUS_DATA_OVERRUN ) )
{
// Most likely, if we
failed, this drive is not MMC compliant, which means
// that unless it is a
REALLY OLD burner drive, it is just a ROM.
goto EXIT_CDROM_CHECK;
}
header = (PGET_CONFIGURATION_HEADER)
buffer;
CdRompPrintAllFeaturePages(header,
64); // Just made up that 64… should be the iosb,Information I
think…
>
GET_CONFIGURATION_IOCTL_INPUT
getConfIoctlInput;PGET_CONFIGURATION_HEADER header;
PFEATURE_HEADER fheader;
ULONG count;
ULONG bufSize =
sizeof(GET_CONFIGURATION_HEADER);
Could this be the problem right here-- you
told IoBuildDeviceIoControlRequest() that your buffer
was only the size of the header…
buffer =
(PCHAR)ExAllocatePool(NonPagedPool, 1024);
Maybe bufSize should be 1024?
Thanks,
Joseph
DOH!!! Ok, I am revoking my Kernel-Programmer License…
Thanks Joseph…
Tom
Subject: Re: IOCTL_IS_DISK_WRITABLE Problem with CD’s
From: Joseph Galbraith
Newsgroups: ntdev
To: Windows System Software Devs Interest List
>
> GET_CONFIGURATION_IOCTL_INPUT
> getConfIoctlInput;
>
> PGET_CONFIGURATION_HEADER header;
>
> PFEATURE_HEADER fheader;
>
> ULONG count;
>
> ULONG bufSize =
> sizeof(GET_CONFIGURATION_HEADER);
Could this be the problem right here-- you
told IoBuildDeviceIoControlRequest() that your buffer
was only the size of the header…
> buffer =
> (PCHAR)ExAllocatePool(NonPagedPool, 1024);
Maybe bufSize should be 1024?
Thanks,
Joseph
Ok, all… the IOCTL is working… The problem I am having now is
weird:
I keep getting C000003C returned (STATUS_DATA_OVERRUN). If I change the
error goes away, but I don’t get all of the profiles. So, if I change
to 1024, it gives me the DATA_OVERRUN again. I was told DATA_OVERRUN is
ok, but I am not sure because the iosb.Information field is 0 and the
buffer with the returned data is all zeroed out… so, no go on that
one…
There must be some sort of requirement on the actual size of the buffer
for this thing to work. Anyone know what it is? I keep trying different
sizes, but none of them work and give me all the data. I need major help
with this. There must be a size requirement, a multiple of something? I
don’t know. I also heard that you have to have the EXACT buffer size,
but how the hell do I find this? I tried calling it and seeing if it
passes back somewhere how much buffer size I need, but I don’t see it.
HELP!
Thanks
Tom
how many bytes are you requesting in the CDB? How does this compare to
the size of your buffer overall?
the fact that you’re seeing an overrun suggest to me that you’re telling
the drive to transfer more data back then you’ve allocated space for.
Typically the header of a SCSI command response gives you enough
information to compute the exact amount of data you should try to
transfer back. Not always though.
-p
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Handal, Thomas
Sent: Wednesday, February 09, 2005 5:36 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IOCTL_IS_DISK_WRITABLE Problem with CD’s
Ok, all… the IOCTL is working… The problem I am having now
is weird:
I keep getting C000003C returned (STATUS_DATA_OVERRUN). If I
change the # of bytes of the buffer I allocate slightly, say from 128 to
64, this error goes away, but I don’t get all of the profiles. So, if I
change to 1024, it gives me the DATA_OVERRUN again. I was told
DATA_OVERRUN is ok, but I am not sure because the iosb.Information field
is 0 and the buffer with the returned data is all zeroed out… so, no
go on that one…
There must be some sort of requirement on the actual size of the
buffer for this thing to work. Anyone know what it is? I keep trying
different sizes, but none of them work and give me all the data. I need
major help with this. There must be a size requirement, a multiple of
something? I don’t know. I also heard that you have to have the EXACT
buffer size, but how the hell do I find this? I tried calling it and
seeing if it passes back somewhere how much buffer size I need, but I
don’t see it.
HELP!
Thanks
Tom
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com
Henry,
I’ve checked the registry on my machines and it seems not to contain any
“non-MMC compatible” device references. Who’s
maintaining this key for cdrom.sys?
Don’t you think it would be a good idea to provide some at least basic
filter driver verification and signing at Microsoft side?
I mean: if improperly written filters would get warning pop-up message
during installation it would make our life easier. B/s now in
filter driver issues usually larger company name wins. And not properly
written software. Some time ago we had extermely hard times
telling to our customer it’s not we who’s guilty, it’s their NDIS hook based
firewall. All of their responses very much the same - “other”
company has well known name and it’s you guys who’ll be fixing not working
but properly written software. And this situation happens
quite often…
Regards,
Anton Kolomyeytsev
CEO, Rocket Division Software
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry Gabryjelski
Sent: Wednesday, February 09, 2005 8:10 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] RE:IOCTL_IS_DISK_WRITABLE Problem with CD’s
Hi Aton,
This was seen during the development cycle of XP. The way we detect it
is not with a drive list, but rather dynamically (and then store in the
registry so we don’t do it again). You can look at the DDK source for
CDROM.SYS, specifically the function CdRomIsDeviceMmcDevice() in MMC.C, to
see how this is detected. I don’t recall the exact model/firmware revision
this was first found on, but it affected many inquiry data (based on that
one drive). I’m trying to keep away from “drive lists”, as they’re rather
person-time expensive.
I understand the filter driver problem; Unfortunately it’s actually made
worse by sending directly to the PDO, because then people start messing with
the PDO dispatch tables to “really” get stuff, and then to workaround that,
… Part of my work here at Microsoft is focusing on fixing this filter
driver problem for optical devices (and yes, I know XP’s IMAPI.SYS is
problematic – working on that too!).
You’re right.
Glad to see we do, indeed, agree. I’ll start a conversation off-thread to
see if we can help each other wrt these filter driver problems…
.
-----Original Message-----
From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]
Sent: Monday, February 07, 2005 10:12 PM
Subject: RE: RE:IOCTL_IS_DISK_WRITABLE Problem with CD’s
Henry,
Selling CD/DVD burning software for past 6 years. Never seen single
device hanging with “get configuration” sent to it… I’m wonder - how do
you workaround this? )) Can you also tell device(s) INQUIRY data (maybe in a
private message, I don’t think other guys would be interested).
About sending IRPs directly to PDO. It’s b/s there are too many ugly SCSI
filters (like the ones Adaptec has). Also we’re quite ofter absolutely not
happy with somebody else reverse-engineering our applications beholding SCSI
traffic. However I agree this is “problematic” way.
In general every single application “talking” directly to hardware would
end with either own device database or at least with hardcoded INQUIRY data
into application. With all of the codepathes dirrerent depending upon
current device.
Regards,
Anton Kolomyeytsev
CEO, Rocket Division Software
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry Gabryjelski
Sent: Monday, February 07, 2005 8:26 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] RE:IOCTL_IS_DISK_WRITABLE Problem with CD’s
There are many reasons READ_DISC_INFO would fail. Worse, READ_DISC_INFO
does not indicate if you have writable media. This is not the correct path
to follow for all media types, although this will generally work if you are
looking at CD-R/RW media.
Handal, please see my previous post (I only get archives, so my responses
are delayed 24 hours) for a link to the MMC specification and a nice IOCTL
to use GET_CONFIGURATION. Also, be careful with sending MODE_SENSE.
There’s a lot of problems in that:
(*) Some devices only support MODE_SENSE6 (now rare, legacy only)
(*) Some devices return a block header, even if DBD bit is set (now rare,
legacy only)
That’s just off the top of my head. Again, sending commands directly to
CD/DVD devices is inherently tricky. Although it may work well on a
brand-name drive, there are hundreds of models of drives on the market, and
many of them have little quirks that need to be worked around. It’s very
difficult and time-consuming to write code that works on all drives on the
market. If you only need to work with a known set of drives (for internal
corporate use, for example), then you can do this relatively easily. If you
want to release for the world to use, I’d suggest staying in “beta” for a
few years.
Hth,
.
-----Original Message-----
From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]
Sent: Friday, February 04, 2005 12:51 PM
Subject: RE: RE:IOCTL_IS_DISK_WRITABLE Problem with CD’s
Bad idea. Device performing async command would fail READ DISC INFO.
Regards,
Anton Kolomyeytsev
CEO, Rocket Division Software
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Friday, February 04, 2005 10:36 PM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] IOCTL_IS_DISK_WRITABLE Problem with CD’s
READ DISC INFORMATION SCSI command will tell you whether the disk
inserted is writeable or not.
I know that CDFS supports writes. I also know on IMAPI feature.
Possibly (but not necessary) it is implemented as writes to CDFS, and then
commit to the media using IMAPI.SYS driver. Possibly not so.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Handal, Thomas mailto:xxxxx
To: Windows System Software Devs Interest List
mailto:xxxxx
Sent: Friday, February 04, 2005 10:28 PM
Subject: RE:[ntdev] IOCTL_IS_DISK_WRITABLE Problem with CD’s
Hi Henry,
Thanks for your reply. I don’t believe that there are any third
party apps on the CD/DVD stack. I have tried the driver I wrote on
3 or 4 machines and they all have the same result. Is there any other way to
determine if a CD drive is writable or not? How about detecting if it is a
CD-ROM or CD-R/RW, etc? Also for DVD-ROM or DVD-RAM? I’ve tried everything
so far that I can think of:
1. Getting description of device and looking for “ROM” -
that won’t work
2. IOCTL_IS_DISK_WRITABLE - doesn’t work for CDs…
3. Characteristics & FILE_READ_ONLY_VOLUME in kernel -
doesn’t work and also stated as “Unreliable” by Neil Christiansen
4. Tried asking it nicely… that doesn’t work either…
5. Whacked it with a baseball bat a few times… stopped
spinning-up… that wasn’t good… got a new one and asked it nicely…
but that didn’t work…
I am SOO lost here… and it seems that it should be such a
SIMPLE thing… I have run out of hair to pull… please help me!
Please tell me about some new undocumented saving function!!!
PLEASE!!!
Thanks
Tom
On 04 Feb 2005, you wrote in ntdev:
> Hi Tom,
>
> First question I would have to ask is, do you have any third
party
> software installed? If so, does this still happen when you use a
clean
> installation of Windows XP? Finally, is this restricted to a
single
> type of CD/DVD drive (i.e. only drives from one vendor)?
>
> This behavior certainly seems unusual, and is not what I would
expect
> either. Two possibilities are:
>
> (A) 3rd party software on the CD/DVD stack may modify the results
of
> this IOCTL.
>
> (B) The firmware on the device reports that it is always a
randomly
> writable, hardware defect managed media.
>
> Looking forward to hearing your results.
> .
>
> -----Original Message-----
> From: Handal, Thomas [mailto:xxxxx@websense.com]
> Sent: Thursday, February 03, 2005 1:59 PM
> Subject: IOCTL_IS_DISK_WRITABLE Problem with CD’s
>
> Hi all
>
>
>
> I am having a problem with the IOCTL_IS_DISK_WRITABLE
call. It
> works great with Floppy’s and Removable thumb drives, etc. But for
CD’s,
> I am having a problem. It does not matter if the drive is a
CD-ROM/RW/R
> or whatever. The problem that I am having is that regardless of
what CD
> media I am using, (burnt, stamped, etc.) it ALWAYS says it is
WRITABLE.
> I don’t understand why. Can anyone shed some light on this and how
to
> get around it?
>
>
>
> Thanks in advance… I truly appreciate any help…
>
> Tom
>
>
>
Tom Handal
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx>
> 2) What are you going to do with hook-based SCSI filters? Something like
Frow now on, I had no customer requirements about supporting such stuff.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> telling to our customer it’s not we who’s guilty, it’s their NDIS hook based
firewall.
Shit. Why people not use NDIS IMs, which are well-supported and have a great
debugged and stable PASSTHRU template?
company has well known name and it’s you guys who’ll be fixing not working
but properly written software.
I had a similar interop with Kaspersky antivirus. At least their developer was
responsive.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
First call, get only the header. The header contains the number of
bytes available from the command at a given point in time (see
GET_CONFIGURATION command in spec). Allocate the exact number of bytes,
resend.
This is a fairly common way to get information from CD/DVD devices. It
all stems from the fact that IDE in DMA mode doesn’t (can’t) inform the
host how many bytes of a transfer were actually sent, so the command set
was designed to include this information (typically in the first two to
four bytes) for most commands – the notable exceptions being read/write
of course.
Hth,
.
-----Original Message-----
From: Handal, Thomas [mailto:xxxxx@websense.com]
Sent: Wednesday, February 09, 2005 5:36 PM
Subject: Re: IOCTL_IS_DISK_WRITABLE Problem with CD’s
Ok, all… the IOCTL is working… The problem I am having now is
weird:
I keep getting C000003C returned (STATUS_DATA_OVERRUN). If I change the
error goes away, but I don’t get all of the profiles. So, if I change
to 1024, it gives me the DATA_OVERRUN again. I was told DATA_OVERRUN is
ok, but I am not sure because the iosb.Information field is 0 and the
buffer with the returned data is all zeroed out… so, no go on that
one…
There must be some sort of requirement on the actual size of the buffer
for this thing to work. Anyone know what it is? I keep trying different
sizes, but none of them work and give me all the data. I need major help
with this. There must be a size requirement, a multiple of something? I
don’t know. I also heard that you have to have the EXACT buffer size,
but how the hell do I find this? I tried calling it and seeing if it
passes back somewhere how much buffer size I need, but I don’t see it.
HELP!
Thanks
Tom
>First call, get only the header. The header contains the number of
bytes available from the command at a given point in time (see
Yes, most SCSI commands are such. Nevertheless, the better way is - first time,
ask with, say, 32byte buffer. If this will be not enough (and there are chances
it will be enough) - allocate the really-size buffer and retry.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
WOOOHOOO!!! IT WORKS!!! IT ACTUALLY WORKS!!!
Thanks to everyone who helped me fix this problem.
You do have to run the IOCTL twice, once with the bufsize =
sizeof(GET_CONFIGURATION_HEADER), then again after u get the length from
header->DataLength.
Thanks again everyone!!!
Tom
Hi all,
Ok, yes it worked… but only on XP… I am still having a problem
with 2000. This IOCTL (IOCTL_CDROM_GET_CONFIGURATION) does not work on
2000. Does anyone have a way to accomplish basically the same call on
2000? I just need to know if the drive is a CD-ROM or CD-R/RW/DVD-RW,
etc. Basically I need to know if it is just a ROM, or is writable also.
Please someone help me. This is working for XP using the IOCTL, but
doesn’t work on 2000.
Any code snippets or anything for 2000 would be greatly appreciated,
because there is nothing about this for 2000. I know there is apparently
some SCSI command I can send down, etc. But I have no idea how to do
this, so a little code snippet or example would be tremendously helpful.
Thanks
Tom
Usual SCSI_PASSTHRU will help with READ DISC INFORMATION.
It returns a structure, and some bits in it say you - is it a non-writeable disc in the drive or writeable one.
The details are in MMC-4 spec.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Handal, Thomas
To: Windows System Software Devs Interest List
Sent: Friday, February 11, 2005 5:05 AM
Subject: RE:[ntdev] IOCTL_IS_DISK_WRITABLE Problem with CD’s
Hi all,
Ok, yes it worked. but only on XP. I am still having a problem with 2000. This IOCTL (IOCTL_CDROM_GET_CONFIGURATION) does not work on 2000. Does anyone have a way to accomplish basically the same call on 2000? I just need to know if the drive is a CD-ROM or CD-R/RW/DVD-RW, etc. Basically I need to know if it is just a ROM, or is writable also. Please someone help me. This is working for XP using the IOCTL, but doesn’t work on 2000.
Any code snippets or anything for 2000 would be greatly appreciated, because there is nothing about this for 2000. I know there is apparently some SCSI command I can send down, etc. But I have no idea how to do this, so a little code snippet or example would be tremendously helpful.
Thanks
Tom
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Based on previous threads, it seems like you are writing a driver.
Steps I’d suggest in your driver:
after StartDevice() succeeds below you, but before you complete it,
send IOCTL_CDROM_GET_CONFIGURATION (for the header only) to see if the
stack supports it. Save in your device extension whether you can use
the IOCTL method or not. (Use the IOCTL when possible, as we will
continue to add fixes and workarounds for firmware issues.)
When needing to determine if writable, branch to one of two functions
based on the above saved info.
If can use the IOCTL, great.
For the non-IOCTL case, look at the CDROM.SYS code sample in the DDK,
and see how it handles IOCTL_CDROM_GET_CONFIGURATION. Use the basic
method to setup the SRB. Handle all the same error cases.
You have source code available to you, which is a luxury that you should
take advantage of.
.
-----Original Message-----
From: Handal, Thomas [mailto:xxxxx@websense.com]
Sent: Thursday, February 10, 2005 6:05 PM
Subject: RE:IOCTL_IS_DISK_WRITABLE Problem with CD’s
Hi all,
Ok, yes it worked… but only on XP… I am still having a problem
with 2000. This IOCTL (IOCTL_CDROM_GET_CONFIGURATION) does not work on
2000. Does anyone have a way to accomplish basically the same call on
2000? I just need to know if the drive is a CD-ROM or CD-R/RW/DVD-RW,
etc. Basically I need to know if it is just a ROM, or is writable also.
Please someone help me. This is working for XP using the IOCTL, but
doesn’t work on 2000.
Any code snippets or anything for 2000 would be greatly appreciated,
because there is nothing about this for 2000. I know there is apparently
some SCSI command I can send down, etc. But I have no idea how to do
this, so a little code snippet or example would be tremendously helpful.
Thanks
Tom
Hi All, Again,
Ok, as you know, I have the IOCTL_CDROM_GET_CONFIGURATION working
for XP in the kernel. Now I need to get it working for 2000. Please
help.
Here is some of the code that I pulled from the DDK regarding the
GET_CONFIGURATION. I tried compiling this, but the
SCSIOP_GET_CONFIGURATION is not known in the W2K DDK. This apparently
was added in XP. What I don’t understand is that the SCSI commands I
thought were all supported by the drives, so can’t I just use the XP
definition of this to use in my W2K driver?
Also, the GET_CONFIGURATION part of the cdb structure also does NOT
exist on W2K. So, I am at a loss here. Is there anyway I can implement
the following code on W2K, so I can get the same results as with calling
IOCTL_CDROM_GET_CONFIGURATION on XP?
Any help would be greatly appreciated. I am at a deadline here that I
need to finish, so any help and/or code snippets are appreciated.
Thanks
Tom
P.S. The following code was partially taken from the XP DDK.
PCHAR Buffer;
SCSI_REQUEST_BLOCK srb = {0};
PCDB cdb;
ULONG_PTR returned;
NTSTATUS status;
BOOLEAN CdRomReadOnly = TRUE;
USHORT BufferSize = 256;
ULONG ValidBytes = 0;
PAGED_CODE();
returned = 0;
Buffer =
(PCHAR)ExAllocatePool(NonPagedPool, BufferSize);
if ( ! Buffer )
return CdRomReadOnly;
RtlZeroMemory(&srb,
sizeof(SCSI_REQUEST_BLOCK));
RtlZeroMemory(Buffer, BufferSize);
srb.TimeOutValue = 0x4; // This was
found to be 4 in the XP SCSI.H
srb.CdbLength = 10;
cdb = (PCDB)srb.Cdb;
cdb->GET_CONFIGURATION.OperationCode
= SCSIOP_GET_CONFIGURATION;
cdb->GET_CONFIGURATION.RequestType =
(UCHAR)0x0; // Get all configurations
cdb->GET_CONFIGURATION.StartingFeature[0] = (UCHAR)(0x0); // Get profile
type stuff
cdb->GET_CONFIGURATION.StartingFeature[1] = (UCHAR)(0x0);
cdb->GET_CONFIGURATION.AllocationLength[0] = (UCHAR)(BufferSize >> 8);
cdb->GET_CONFIGURATION.AllocationLength[1] = (UCHAR)(BufferSize & 0xff);
status =
ClassSendSrbSynchronous(diskDeviceObject, &srb, Buffer,
BufferSize, FALSE);
returned = srb.DataTransferLength;
KdPrint((“*** CdromGetConfiguration:
Status was %x\n”, status));
if (NT_SUCCESS(status) || status ==
STATUS_BUFFER_OVERFLOW)
{
KdPrint((“*** We are
GOOD …\n”));
//
// if returned more than
can be stored in a ULONG, return false
//
if (returned >
(ULONG)(-1)) {
return
STATUS_UNSUCCESSFUL;
}
ValidBytes =
(ULONG)returned;
return STATUS_SUCCESS;
}
else
{
KdPrint((“***
CdromGetConfiguration: failed %x\n”, status));
return status;
}
return STATUS_UNSUCCESSFUL;