Hello.
These days I invent diagnostics for a living.
It’s commonplace for a storage device diagnostic to have a test that
involves writing to the media. For example, a read/write test on a
floppy or tests that write a data pattern to a USB flash memory “drive”
and then thence read it back and check that it was correctly written to
the media.
From WinNT through Win2k through WinXP and up through at least RC1
Vista, doing so has worked successfully by getting a handle to the
“physical drive” using “\.\A:” or “\.\PhysicalDrive0” or a
GUID_DEVINTERFACE_DISK “interface” symbolic name, etc.
This is now no longer so in RTM Vista. Such writes now fail with an
error of “access denied”.
I’ve empirically determined that the writes will succeed if the “volume”
is dismounted using FSCTL_DISMOUNT_VOLUME. On a floppy, this seems to be
sufficient. But on a USB flash memory “drive” something else is going on
in RTM Vista that results in a bus “reset” during the course of writing
to the “drive” and much mayhem happening thereafter that only a reboot
seems to sort out.
Again, all of this has worked successfully up through RC1 Vista (I
didn’t get a chance to try RC2 Vista).
Now, I don’t have anything against “progress”. I understand that things
change. But at the last minute before release to manufacturing? Without
giving any of us opportunity to “get ready” for it?
So, what happened? What’s changed in the drivers in RTM Vista that’s
causing this to happen? What’s the idea now; i.e., what’s the apropos
way of doing such things now in RTM Vista? Are such things as
diagnostics writing to the physical media now verboten in RTM Vista? If
so, then why (for “security” reasons)?
Comments? Ideas?
MikeC
Nope. I do it all day long every day, at least to our (Seagate and now
Maxtor) hard drives, whether IDE, SCSI, FC, SATA, or SAS. The trick is to
run your application as an administrator, and be sure that the disk which
you have opened as “physical” has does not have any open handles.
You can probably do this in the build, but the quickest way is to simply
open the properties of the application and either select RunAs, or the
Compatability tab and set it permanently.
Gary
“Mike Colandreo” wrote in message
news:xxxxx@ntdev…
> Hello.
>
> These days I invent diagnostics for a living.
>
> It’s commonplace for a storage device diagnostic to have a test that
> involves writing to the media. For example, a read/write test on a floppy
> or tests that write a data pattern to a USB flash memory “drive” and then
> thence read it back and check that it was correctly written to the media.
>
> From WinNT through Win2k through WinXP and up through at least RC1 Vista,
> doing so has worked successfully by getting a handle to the “physical
> drive” using “\.\A:” or “\.\PhysicalDrive0” or a GUID_DEVINTERFACE_DISK
> “interface” symbolic name, etc.
>
> This is now no longer so in RTM Vista. Such writes now fail with an error
> of “access denied”.
>
> I’ve empirically determined that the writes will succeed if the “volume”
> is dismounted using FSCTL_DISMOUNT_VOLUME. On a floppy, this seems to be
> sufficient. But on a USB flash memory “drive” something else is going on
> in RTM Vista that results in a bus “reset” during the course of writing to
> the “drive” and much mayhem happening thereafter that only a reboot seems
> to sort out.
>
> Again, all of this has worked successfully up through RC1 Vista (I didn’t
> get a chance to try RC2 Vista).
>
> Now, I don’t have anything against “progress”. I understand that things
> change. But at the last minute before release to manufacturing? Without
> giving any of us opportunity to “get ready” for it?
>
> So, what happened? What’s changed in the drivers in RTM Vista that’s
> causing this to happen? What’s the idea now; i.e., what’s the apropos way
> of doing such things now in RTM Vista? Are such things as diagnostics
> writing to the physical media now verboten in RTM Vista? If so, then why
> (for “security” reasons)?
>
> Comments? Ideas?
>
>
> MikeC
>
>
I have the same problem and tried to solve it in the kernel. But no way. Every write acces returns with ACCESS_DENIED. It only works in areas outside of volumes. Had someone solved this problem?
Andreas