How to prevent auto fixing of corrupted GPT partition metadata when a disk is attached

Hi,

I’m working on a disk filter driver that is blocking writing to all disks except the boot one. The problem is that the system is loading the partition info and trying to fix it if it is corrupted (GPT in particular), writing to the disk before the filter driver has a chance to block the operation. The write operation happens during the handling of IRP_MN_START_DEVICE function (from the IRP_MJ_PNP callback), more exactly when sending the irp to the next driver in line. The culprit seems to be the function IoReadDiskSignature that the physical disk driver calls. Please see the call stack below for details. It does not seem to make a difference if the filter driver (diskdrv) is above or below the partition manager (partmgr) in the UpperFilters list. Is there a way to prevent this from happening? I’m hoping there is some registry key or something that would let Windows know to not try to load the partitions or at least to not try to fix them.

OsrSVMStor!OsrUserWriteData+0x10a […\osrvmsample\osrvmuserutil.cpp @ 1941] C/C++/ASM
OsrSVMStor!OsrUserHandleSrb+0x410 […\osrvmsample\osrvmuserintf.cpp @ 847] C/C++/ASM
OsrSVMStor!OsrVmExecuteScsi+0x1c4 […\osrvmsample\osrvmscsi.cpp @ 129] C/C++/ASM
OsrSVMStor!OsrHwStartIo+0xb7 […\osrvmsample\osrvminipt.cpp @ 663] C/C++/ASM
storport!RaidAdapterPostScatterGatherExecute+0x299 C/C++/ASM
storport!RaUnitStartIo+0x18d C/C++/ASM
storport!RaidStartIoPacket+0x452 C/C++/ASM
storport!RaidUnitSubmitRequest+0x83 C/C++/ASM
storport!RaUnitScsiIrp+0x133 C/C++/ASM
storport!RaDriverScsiIrp+0x40 C/C++/ASM
nt!IopfCallDriver+0x34 C/C++/ASM
nt!IofCallDriver+0x1a C/C++/ASM
CLASSPNP!SubmitTransferPacket+0x1dc C/C++/ASM
CLASSPNP!ServiceTransferRequest+0x251 C/C++/ASM
CLASSPNP!ClassReadWrite+0x4ac C/C++/ASM
CLASSPNP!ClassGlobalDispatch+0x23 C/C++/ASM
nt!IopfCallDriver+0x34 C/C++/ASM
nt!IofCallDriver+0x1a C/C++/ASM
nt!IoSynchronousCallDriver+0x38 C/C++/ASM
nt!PC_ENVIRONMENT::Write+0x37 C/C++/ASM
nt!PC_DISK::WriteSectors+0x3e C/C++/ASM
nt!PC_GPT::WritePartitionTable+0x373 C/C++/ASM
nt!PC_GPT::ReadPartitionTable+0x250 C/C++/ASM
nt!PC_DISK::ReadPartitionTable+0x67012 C/C++/ASM
nt!PcReadPartitionTable+0x62 C/C++/ASM
nt!IoReadDiskSignature+0x16 C/C++/ASM
disk!DiskReadSignature+0x2b C/C++/ASM
disk!DiskInitFdo+0x14e C/C++/ASM
CLASSPNP!ClassPnpStartDevice+0x48a C/C++/ASM
CLASSPNP!ClassDispatchPnp+0x552 C/C++/ASM
CLASSPNP!ClassGlobalDispatch+0x23 C/C++/ASM
nt!IopfCallDriver+0x34 C/C++/ASM
nt!IofCallDriver+0x1a C/C++/ASM
diskdrv!PNPForwardToNextDriver+0x6d […\diskdrv\diskpnp.cpp @ 107] C/C++/ASM
diskdrv!DispatchPnp+0x1e8 […\diskdrv\diskpnp.cpp @ 1118] C/C++/ASM
nt!IopfCallDriver+0x34 C/C++/ASM
nt!IofCallDriver+0x1a C/C++/ASM
nt!IoSynchronousCallDriver+0x38 C/C++/ASM
nt!IoForwardIrpSynchronously+0x2a C/C++/ASM
partmgr!PmStartDevice+0x5f C/C++/ASM
partmgr!PmPnp+0xdc C/C++/ASM
partmgr!PmGlobalDispatch+0x2e C/C++/ASM
nt!IopfCallDriver+0x34 C/C++/ASM
nt!IofCallDriver+0x1a C/C++/ASM
nt!PnpAsynchronousCall+0x9e C/C++/ASM
nt!PnpSendIrp+0x67 C/C++/ASM
nt!PnpStartDevice+0x60 C/C++/ASM
nt!PnpStartDeviceNode+0xc3 C/C++/ASM
nt!PipProcessStartPhase1+0x46 C/C++/ASM
nt!PipProcessDevNodeTree+0x386 C/C++/ASM
nt!PiProcessReenumeration+0x8f C/C++/ASM
nt!PnpDeviceActionWorker+0x148 C/C++/ASM
nt!ExpWorkerThread+0xc0 C/C++/ASM
nt!PspSystemThreadStartup+0x4a C/C++/ASM
nt!KiThreadStartup+0x15 C/C++/ASM

Thanks!

Adrian

You probably need a lower filter as well.

To be honest, I don’t know what the implications would be if you fail any
write request befo

Hi,

I’m working on a disk filter driver that is blocking writing to all
disks except the boot one. The problem is that the system is loading the
partition info and trying to fix it if it is corrupted (GPT in particular),
writing to the disk before the filter driver has a chance to block the
operation. The write operation happens during the handling of
IRP_MN_START_DEVICE function (from the IRP_MJ_PNP callback), more exactly
when sending the irp to the next driver in line. The culprit seems to be
the function IoReadDiskSignature that the physical disk driver calls.
Please see the call stack below for details. It does not seem to make a
difference if the filter driver (diskdrv) is above or below the partition
manager (partmgr) in the UpperFilters list. Is there a way to prevent this
from happening? I’m hoping there is some registry key or something that
would let Windows know to not try to load the partitions or at least to not
try to fix them.

OsrSVMStor!OsrUserWriteData+0x10a […\osrvmsample\osrvmuserutil.cpp
@ 1941] C/C++/ASM

OsrSVMStor!OsrUserHandleSrb+0x410 […\osrvmsample\osrvmuserintf.cpp
@ 847] C/C++/ASM

OsrSVMStor!OsrVmExecuteScsi+0x1c4
[…\osrvmsample\osrvmscsi.cpp @ 129] C/C++/ASM

OsrSVMStor!OsrHwStartIo+0xb7 […\osrvmsample\osrvminipt.cpp
@ 663] C/C++/ASM

storport!RaidAdapterPostScatterGatherExecute+0x299
C/C++/ASM

storport!RaUnitStartIo+0x18d C/C++/ASM

storport!RaidStartIoPacket+0x452 C/C++/ASM

storport!RaidUnitSubmitRequest+0x83 C/C++/ASM

storport!RaUnitScsiIrp+0x133 C/C++/ASM

storport!RaDriverScsiIrp+0x40 C/C++/ASM

nt!IopfCallDriver+0x34 C/C++/ASM

nt!IofCallDriver+0x1a C/C++/ASM

CLASSPNP!SubmitTransferPacket+0x1dc C/C++/ASM

CLASSPNP!ServiceTransferRequest+0x251 C/C++/ASM

CLASSPNP!ClassReadWrite+0x4ac C/C++/ASM

CLASSPNP!ClassGlobalDispatch+0x23 C/C++/ASM

nt!IopfCallDriver+0x34 C/C++/ASM

nt!IofCallDriver+0x1a C/C++/ASM

nt!IoSynchronousCallDriver+0x38 C/C++/ASM

nt!PC_ENVIRONMENT::Write+0x37 C/C++/ASM

nt!PC_DISK::WriteSectors+0x3e C/C++/ASM

nt!PC_GPT::WritePartitionTable+0x373 C/C++/ASM

nt!PC_GPT::ReadPartitionTable+0x250 C/C++/ASM

nt!PC_DISK::ReadPartitionTable+0x67012 C/C++/ASM

nt!PcReadPartitionTable+0x62 C/C++/ASM

nt!IoReadDiskSignature+0x16 C/C++/ASM

disk!DiskReadSignature+0x2b C/C++/ASM

disk!DiskInitFdo+0x14e C/C++/ASM

CLASSPNP!ClassPnpStartDevice+0x48a C/C++/ASM

CLASSPNP!ClassDispatchPnp+0x552 C/C++/ASM

CLASSPNP!ClassGlobalDispatch+0x23 C/C++/ASM

nt!IopfCallDriver+0x34 C/C++/ASM

nt!IofCallDriver+0x1a C/C++/ASM

diskdrv!PNPForwardToNextDriver+0x6d
[…\diskdrv\diskpnp.cpp @ 107] C/C++/ASM

diskdrv!DispatchPnp+0x1e8 […\diskdrv\diskpnp.cpp @
1118] C/C++/ASM

nt!IopfCallDriver+0x34 C/C++/ASM

nt!IofCallDriver+0x1a C/C++/ASM

nt!IoSynchronousCallDriver+0x38 C/C++/ASM

nt!IoForwardIrpSynchronously+0x2a C/C++/ASM

partmgr!PmStartDevice+0x5f C/C++/ASM

partmgr!PmPnp+0xdc C/C++/ASM

partmgr!PmGlobalDispatch+0x2e C/C++/ASM

nt!IopfCallDriver+0x34 C/C++/ASM

nt!IofCallDriver+0x1a C/C++/ASM

nt!PnpAsynchronousCall+0x9e C/C++/ASM

nt!PnpSendIrp+0x67 C/C++/ASM

nt!PnpStartDevice+0x60 C/C++/ASM

nt!PnpStartDeviceNode+0xc3 C/C++/ASM

nt!PipProcessStartPhase1+0x46 C/C++/ASM

nt!PipProcessDevNodeTree+0x386 C/C++/ASM

nt!PiProcessReenumeration+0x8f C/C++/ASM

nt!PnpDeviceActionWorker+0x148 C/C++/ASM

nt!ExpWorkerThread+0xc0 C/C++/ASM

nt!PspSystemThreadStartup+0x4a C/C++/ASM

nt!KiThreadStartup+0x15 C/C++/ASM

Thanks!

Adrian


NTDEV is sponsored by OSR

Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

Thank you for the suggestion! Moving the driver at lower filter level actually fixes the issue, and we can now block all the write calls. The system is showing the drive as uninitialized, but otherwise work fine and with the right tools we can access the drive data. The caveat is that instead of intercepting IRP_MJ_WRITE we have to intercept IRP_MJ_INTERNAL_DEVICE_CONTROL => SRB_FUNCTION_EXECUTE_SCSI => SCSIOP_WRITE, SCSIOP_WRITE6, SCSIOP_WRITE12 and SCSIOP_WRITE16.