Problem with a virtual disk driver

NTDEV
1

Greetings,

I’m having a problem with a virtual disk driver that I’m writing. At the
moment, the prototype is simply a pass-through driver to an underlying
disk device.

My driver currently does the following:
Creates a device object (vdisk01)
Creates a symbolic link to it (F:)
Calls IoGetDeviceObjectPointer on the target disk (HarddiskVolume2)
Calls IoAttachDeviceToDeviceStatck to attach vdisk01 to HarddiskVolume2

In the read and write functions it does:
IoCopyCurrentIrpStackLocation(Irp)
IoSetCompletionRoutine(…)
IoCallDriver(…)

On initial boot all is fine…

HarddiskVolume2 was not formatted and does not have a symbolic link of its
own.
F: is available (via my driver) and I formatted it as an NTFS file system
At this point I could copy files to it and access it normally via my
pass-through driver.

Then I reboot…

On the call to IoGetDeviceObjectPointer in my driver, we somehow end up in
Ntfs code that causes the system to crash.

I then reboot in safe mode to remove my driver and then reboot again to
normal mode.

I use Disk Manager to assign a drive letter to HarddiskVolume2 (Y:)
I can then access the ntfs file system without problem.

Anybody have any idea as to why the failure in ntfs happens on the call to
IoGetDeviceObjectPointer in my driver? It appears that the initial format
and file system activity via my pass-through driver was OK as the file
system mounts OK now without my driver. Could it be that ntfs is ‘seeing’
the disk twice and trying to automount it somehow and that causes a
problem…

Thanks in advance for any help.
-bob

2

Is your driver a PNP filter driver? Or did you write a non-PNP driver
that just attaches to HarddiskVolume2 by name.

In a storage stack the device with the name also needs to have the VPB.
Normally that would be the volume device. I would guess that adding
your storage driver with a different name managed to confuse the boot
process, but without a stack trace it’s hard to tell much of anything.

I would suggest that you create your vdisk0 device as a separate device
and open HarddiskVolume2 instead of attaching to the volume stack.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@dunstable.org
Sent: Friday, August 12, 2005 5:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Problem with a virtual disk driver

Greetings,

I’m having a problem with a virtual disk driver that I’m writing. At
the moment, the prototype is simply a pass-through driver to an
underlying disk device.

My driver currently does the following:
Creates a device object (vdisk01)
Creates a symbolic link to it (F:)
Calls IoGetDeviceObjectPointer on the target disk (HarddiskVolume2)
Calls IoAttachDeviceToDeviceStatck to attach vdisk01 to
HarddiskVolume2

In the read and write functions it does:
IoCopyCurrentIrpStackLocation(Irp)
IoSetCompletionRoutine(…)
IoCallDriver(…)

On initial boot all is fine…

HarddiskVolume2 was not formatted and does not have a symbolic link of
its own.
F: is available (via my driver) and I formatted it as an NTFS file
system At this point I could copy files to it and access it normally via
my pass-through driver.

Then I reboot…

On the call to IoGetDeviceObjectPointer in my driver, we somehow end up
in Ntfs code that causes the system to crash.

I then reboot in safe mode to remove my driver and then reboot again to
normal mode.

I use Disk Manager to assign a drive letter to HarddiskVolume2 (Y:) I
can then access the ntfs file system without problem.

Anybody have any idea as to why the failure in ntfs happens on the call
to IoGetDeviceObjectPointer in my driver? It appears that the initial
format and file system activity via my pass-through driver was OK as the
file system mounts OK now without my driver. Could it be that ntfs is
‘seeing’
the disk twice and trying to automount it somehow and that causes a
problem…

Thanks in advance for any help.
-bob

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Hi Peter,

Thanks for the info. This is a non-PNP driver that attaches to a disk.
I’m new to drivers, I
took this approach based on some earlier feedback from this forum. I’ve
included the debug
info below.

For a generic virtual disk driver, you’re recomendation would be to use
ZwCreateFile,
ZwReadFile, and ZwWriteFile to access the disk(s)? Would there be extra
overhead with
this approach?

-bob

EXCEPTION_RECORD: f9e65b68 – (.exr fffffffff9e65b68)
ExceptionAddress: f98db184 (Ntfs!NtfsRemovePrefix+0x00000009)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 000001fe
Attempt to read from address 000001fe

CONTEXT: f9e65864 – (.cxr fffffffff9e65864)
eax=f9e65c60 ebx=ff7bc420 ecx=00000000 edx=e162a850 esi=000001fa
edi=00000000
eip=f98db184 esp=f9e65c30 ebp=f9e65c34 iopl=0 nv up ei pl nz ac
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010216
Ntfs!NtfsRemovePrefix+0x9:
f98db184 f6460408 test byte ptr [esi+0x4],0x8
Resetting default scope

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0x24

LAST_CONTROL_TRANSFER: from f98e6613 to f98db184

STACK_TEXT:
f9e65c34 f98e6613 000001fa f9e65c88 f9e65c64 Ntfs!NtfsRemovePrefix+0x9
f9e65c44 f990aa6d 81a1da70 f9e65c60 e162a850 Ntfs!NtfsDeleteLcb+0x10
f9e65c64 f98dacb4 81a1da70 f9e60000 e162a880 Ntfs!NtfsDeleteScb+0x205
f9e65c7c f98b57a9 81a1da70 e1626b48 00000000 Ntfs!NtfsRemoveScb+0x88
f9e65c98 f98daa9b 81a1da70 e162a850 00000000
Ntfs!NtfsPrepareFcbForRemoval+0x52
f9e65ce0 f98f8e36 81a1da70 e162a850 00000000
Ntfs!NtfsTeardownStructures+0x5b
f9e65d6c f990db6f 81a1da70 ff7bc420 00000001 Ntfs!NtfsFlushVolume+0x481
f9e65e0c f98ec385 81a1da70 81af2e70 804e8a39 Ntfs!NtfsCommonVolumeOpen+0x18f
f9e65ee4 804e37f7 ff7bc340 81af2e70 f9e65f3c Ntfs!NtfsFsdCreate+0x154
f9e65ef4 f839c124 00000000 f9e65f3c ff80cfb8 nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available. Following frames may be
wrong.
f9e66048 8056316c 81b5cbe8 00000000 81bad970
SYMEVENT!SYMEvent_GetVMDataPtr+0x8764
f9e660d0 8056729a 00000000 f9e66110 00000240 nt!ObpLookupObjectName+0x56a
f9e66124 80570b73 00000000 00000000 00000000 nt!ObOpenObjectByName+0xeb
f9e661a0 80570c42 f9e6631c 00000001 f9e662f4 nt!IopCreateFile+0x407
f9e661fc 80570d0a f9e6631c 00000001 f9e662f4 nt!IoCreateFile+0x8e
f9e6623c 804de7ec f9e6631c 00000001 f9e662f4 nt!NtOpenFile+0x27
f9e6623c 804dcfdd f9e6631c 00000001 f9e662f4 nt!KiFastCallEntry+0xf8
f9e662cc 8059311c f9e6631c 00000001 f9e662f4 nt!ZwOpenFile+0x11
f9e66314 f9f6b92c f9e6632c 00000001 ff7bcf94
nt!IoGetDeviceObjectPointer+0x40
f9e66570 805a0799 ff7c41b8 81a36000 00000000 Virtdisk+0x92c
f9e66640 8069e729 0000011c 00000001 00000000 nt!IopLoadDriver+0x66c
f9e6669c 8069e4b1 00034000 00000000 00000000
nt!IopInitializeSystemDrivers+0x16c
f9e6683c 8069f7f8 80087000 00000000 81bcc788 nt!IoInitSystem+0x7a3
f9e66dac 8057be15 80087000 00000000 00000000 nt!Phase1Initialization+0x9b5
f9e66ddc 804fa4da 8069f086 80087000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
Ntfs!NtfsRemovePrefix+9
f98db184 f6460408 test byte ptr [esi+0x4],0x8

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Ntfs!NtfsRemovePrefix+9

MODULE_NAME: Ntfs

IMAGE_NAME: Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107eea

STACK_COMMAND: .cxr fffffffff9e65864 ; kb

FAILURE_BUCKET_ID: 0x24_Ntfs!NtfsRemovePrefix+9

BUCKET_ID: 0x24_Ntfs!NtfsRemovePrefix+9

Followup: MachineOwner

Peter Wieland wrote:

Is your driver a PNP filter driver? Or did you write a non-PNP driver
that just attaches to HarddiskVolume2 by name.

In a storage stack the device with the name also needs to have the VPB.
Normally that would be the volume device. I would guess that adding
your storage driver with a different name managed to confuse the boot
process, but without a stack trace it’s hard to tell much of anything.

I would suggest that you create your vdisk0 device as a separate device
and open HarddiskVolume2 instead of attaching to the volume stack.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@dunstable.org
Sent: Friday, August 12, 2005 5:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Problem with a virtual disk driver

Greetings,

I’m having a problem with a virtual disk driver that I’m writing. At
the moment, the prototype is simply a pass-through driver to an
underlying disk device.

My driver currently does the following:
Creates a device object (vdisk01)
Creates a symbolic link to it (F:)
Calls IoGetDeviceObjectPointer on the target disk (HarddiskVolume2)
Calls IoAttachDeviceToDeviceStatck to attach vdisk01 to
HarddiskVolume2

In the read and write functions it does:
IoCopyCurrentIrpStackLocation(Irp)
IoSetCompletionRoutine(…)
IoCallDriver(…)

On initial boot all is fine…

HarddiskVolume2 was not formatted and does not have a symbolic link of
its own.
F: is available (via my driver) and I formatted it as an NTFS file
system At this point I could copy files to it and access it normally via
my pass-through driver.

Then I reboot…

On the call to IoGetDeviceObjectPointer in my driver, we somehow end up
in Ntfs code that causes the system to crash.

I then reboot in safe mode to remove my driver and then reboot again to
normal mode.

I use Disk Manager to assign a drive letter to HarddiskVolume2 (Y:) I
can then access the ntfs file system without problem.

Anybody have any idea as to why the failure in ntfs happens on the call
to IoGetDeviceObjectPointer in my driver? It appears that the initial
format and file system activity via my pass-through driver was OK as the
file system mounts OK now without my driver. Could it be that ntfs is
‘seeing’
the disk twice and trying to automount it somehow and that causes a
problem…

Thanks in advance for any help.
-bob

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
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

4

NTFS is probably choking on one of the following (only speculation):

  • Mounting the same volume twice via two different file system paths via two
    different disks. This can confuse the cache and all sorts of things. First,
    if the volume you are passing through to is already in use and mounted, the
    dirty bit will be set. This means NTFS will try to do a check of the volume
    and try to fix it via your virtual disk; I.e. clearing the dirty bit,
    updating other meta-data, etc…

This would result in the original mount and the virtual mount to be out of
sync. This can corrupt your disk and even cause a BSOD

  1. Mounting the same serial number twice via a different disk driver can
    cause havoc with the IO manager.

Again, it is only speculation, but I would look at both of these points.

Jamey Kirby

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Nelson
Sent: Monday, August 15, 2005 5:20 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Problem with a virtual disk driver

Hi Peter,

Thanks for the info. This is a non-PNP driver that attaches to a disk.
I’m new to drivers, I
took this approach based on some earlier feedback from this forum. I’ve
included the debug
info below.

For a generic virtual disk driver, you’re recomendation would be to use
ZwCreateFile,
ZwReadFile, and ZwWriteFile to access the disk(s)? Would there be extra
overhead with
this approach?

-bob

EXCEPTION_RECORD: f9e65b68 – (.exr fffffffff9e65b68)
ExceptionAddress: f98db184 (Ntfs!NtfsRemovePrefix+0x00000009)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 000001fe
Attempt to read from address 000001fe

CONTEXT: f9e65864 – (.cxr fffffffff9e65864)
eax=f9e65c60 ebx=ff7bc420 ecx=00000000 edx=e162a850 esi=000001fa
edi=00000000
eip=f98db184 esp=f9e65c30 ebp=f9e65c34 iopl=0 nv up ei pl nz ac
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010216
Ntfs!NtfsRemovePrefix+0x9:
f98db184 f6460408 test byte ptr [esi+0x4],0x8
Resetting default scope

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0x24

LAST_CONTROL_TRANSFER: from f98e6613 to f98db184

STACK_TEXT:
f9e65c34 f98e6613 000001fa f9e65c88 f9e65c64 Ntfs!NtfsRemovePrefix+0x9
f9e65c44 f990aa6d 81a1da70 f9e65c60 e162a850 Ntfs!NtfsDeleteLcb+0x10
f9e65c64 f98dacb4 81a1da70 f9e60000 e162a880 Ntfs!NtfsDeleteScb+0x205
f9e65c7c f98b57a9 81a1da70 e1626b48 00000000 Ntfs!NtfsRemoveScb+0x88
f9e65c98 f98daa9b 81a1da70 e162a850 00000000
Ntfs!NtfsPrepareFcbForRemoval+0x52
f9e65ce0 f98f8e36 81a1da70 e162a850 00000000
Ntfs!NtfsTeardownStructures+0x5b
f9e65d6c f990db6f 81a1da70 ff7bc420 00000001 Ntfs!NtfsFlushVolume+0x481
f9e65e0c f98ec385 81a1da70 81af2e70 804e8a39 Ntfs!NtfsCommonVolumeOpen+0x18f
f9e65ee4 804e37f7 ff7bc340 81af2e70 f9e65f3c Ntfs!NtfsFsdCreate+0x154
f9e65ef4 f839c124 00000000 f9e65f3c ff80cfb8 nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available. Following frames may be
wrong.
f9e66048 8056316c 81b5cbe8 00000000 81bad970
SYMEVENT!SYMEvent_GetVMDataPtr+0x8764
f9e660d0 8056729a 00000000 f9e66110 00000240 nt!ObpLookupObjectName+0x56a
f9e66124 80570b73 00000000 00000000 00000000 nt!ObOpenObjectByName+0xeb
f9e661a0 80570c42 f9e6631c 00000001 f9e662f4 nt!IopCreateFile+0x407
f9e661fc 80570d0a f9e6631c 00000001 f9e662f4 nt!IoCreateFile+0x8e
f9e6623c 804de7ec f9e6631c 00000001 f9e662f4 nt!NtOpenFile+0x27
f9e6623c 804dcfdd f9e6631c 00000001 f9e662f4 nt!KiFastCallEntry+0xf8
f9e662cc 8059311c f9e6631c 00000001 f9e662f4 nt!ZwOpenFile+0x11
f9e66314 f9f6b92c f9e6632c 00000001 ff7bcf94
nt!IoGetDeviceObjectPointer+0x40
f9e66570 805a0799 ff7c41b8 81a36000 00000000 Virtdisk+0x92c
f9e66640 8069e729 0000011c 00000001 00000000 nt!IopLoadDriver+0x66c
f9e6669c 8069e4b1 00034000 00000000 00000000
nt!IopInitializeSystemDrivers+0x16c
f9e6683c 8069f7f8 80087000 00000000 81bcc788 nt!IoInitSystem+0x7a3
f9e66dac 8057be15 80087000 00000000 00000000 nt!Phase1Initialization+0x9b5
f9e66ddc 804fa4da 8069f086 80087000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
Ntfs!NtfsRemovePrefix+9
f98db184 f6460408 test byte ptr [esi+0x4],0x8

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Ntfs!NtfsRemovePrefix+9

MODULE_NAME: Ntfs

IMAGE_NAME: Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107eea

STACK_COMMAND: .cxr fffffffff9e65864 ; kb

FAILURE_BUCKET_ID: 0x24_Ntfs!NtfsRemovePrefix+9

BUCKET_ID: 0x24_Ntfs!NtfsRemovePrefix+9

Followup: MachineOwner

Peter Wieland wrote:

Is your driver a PNP filter driver? Or did you write a non-PNP driver
that just attaches to HarddiskVolume2 by name.

In a storage stack the device with the name also needs to have the VPB.
Normally that would be the volume device. I would guess that adding
your storage driver with a different name managed to confuse the boot
process, but without a stack trace it’s hard to tell much of anything.

I would suggest that you create your vdisk0 device as a separate device
and open HarddiskVolume2 instead of attaching to the volume stack.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@dunstable.org
Sent: Friday, August 12, 2005 5:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Problem with a virtual disk driver

Greetings,

I’m having a problem with a virtual disk driver that I’m writing. At
the moment, the prototype is simply a pass-through driver to an
underlying disk device.

My driver currently does the following:
Creates a device object (vdisk01)
Creates a symbolic link to it (F:)
Calls IoGetDeviceObjectPointer on the target disk (HarddiskVolume2)
Calls IoAttachDeviceToDeviceStatck to attach vdisk01 to
HarddiskVolume2

In the read and write functions it does:
IoCopyCurrentIrpStackLocation(Irp)
IoSetCompletionRoutine(…)
IoCallDriver(…)

On initial boot all is fine…

HarddiskVolume2 was not formatted and does not have a symbolic link of
its own.
F: is available (via my driver) and I formatted it as an NTFS file
system At this point I could copy files to it and access it normally via
my pass-through driver.

Then I reboot…

On the call to IoGetDeviceObjectPointer in my driver, we somehow end up
in Ntfs code that causes the system to crash.

I then reboot in safe mode to remove my driver and then reboot again to
normal mode.

I use Disk Manager to assign a drive letter to HarddiskVolume2 (Y:) I
can then access the ntfs file system without problem.

Anybody have any idea as to why the failure in ntfs happens on the call
to IoGetDeviceObjectPointer in my driver? It appears that the initial
format and file system activity via my pass-through driver was OK as the
file system mounts OK now without my driver. Could it be that ntfs is
‘seeing’
the disk twice and trying to automount it somehow and that causes a
problem…

Thanks in advance for any help.
-bob

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
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: xxxxx@rocketdivision.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

__________ NOD32 1.1193 (20050812) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com

5

Thanks Jamey. I did wonder about this…

Since I did not expose the underlying disk with a symlink (e.g. F:)… how
does one prevent a file system from mounting a disk (logical or physical)?
I want to eventually support mirroring which will mean (at least) three
entities (real or virtual disks) that will be seen as valid file
systems…

Thanks for your input.

-bob

NTFS is probably choking on one of the following (only speculation):

  • Mounting the same volume twice via two different file system paths via
    two
    different disks. This can confuse the cache and all sorts of things.
    First,
    if the volume you are passing through to is already in use and mounted,
    the
    dirty bit will be set. This means NTFS will try to do a check of the
    volume
    and try to fix it via your virtual disk; I.e. clearing the dirty bit,
    updating other meta-data, etc…

This would result in the original mount and the virtual mount to be out of
sync. This can corrupt your disk and even cause a BSOD

  1. Mounting the same serial number twice via a different disk driver can
    cause havoc with the IO manager.

Again, it is only speculation, but I would look at both of these points.

Jamey Kirby

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Nelson
Sent: Monday, August 15, 2005 5:20 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Problem with a virtual disk driver

Hi Peter,

Thanks for the info. This is a non-PNP driver that attaches to a disk.
I’m new to drivers, I
took this approach based on some earlier feedback from this forum. I’ve
included the debug
info below.

For a generic virtual disk driver, you’re recomendation would be to use
ZwCreateFile,
ZwReadFile, and ZwWriteFile to access the disk(s)? Would there be extra
overhead with
this approach?

-bob

EXCEPTION_RECORD: f9e65b68 – (.exr fffffffff9e65b68)
ExceptionAddress: f98db184 (Ntfs!NtfsRemovePrefix+0x00000009)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 000001fe
Attempt to read from address 000001fe

CONTEXT: f9e65864 – (.cxr fffffffff9e65864)
eax=f9e65c60 ebx=ff7bc420 ecx=00000000 edx=e162a850 esi=000001fa
edi=00000000
eip=f98db184 esp=f9e65c30 ebp=f9e65c34 iopl=0 nv up ei pl nz ac
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010216
Ntfs!NtfsRemovePrefix+0x9:
f98db184 f6460408 test byte ptr [esi+0x4],0x8
Resetting default scope

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0x24

LAST_CONTROL_TRANSFER: from f98e6613 to f98db184

STACK_TEXT:
f9e65c34 f98e6613 000001fa f9e65c88 f9e65c64 Ntfs!NtfsRemovePrefix+0x9
f9e65c44 f990aa6d 81a1da70 f9e65c60 e162a850 Ntfs!NtfsDeleteLcb+0x10
f9e65c64 f98dacb4 81a1da70 f9e60000 e162a880 Ntfs!NtfsDeleteScb+0x205
f9e65c7c f98b57a9 81a1da70 e1626b48 00000000 Ntfs!NtfsRemoveScb+0x88
f9e65c98 f98daa9b 81a1da70 e162a850 00000000
Ntfs!NtfsPrepareFcbForRemoval+0x52
f9e65ce0 f98f8e36 81a1da70 e162a850 00000000
Ntfs!NtfsTeardownStructures+0x5b
f9e65d6c f990db6f 81a1da70 ff7bc420 00000001 Ntfs!NtfsFlushVolume+0x481
f9e65e0c f98ec385 81a1da70 81af2e70 804e8a39
Ntfs!NtfsCommonVolumeOpen+0x18f
f9e65ee4 804e37f7 ff7bc340 81af2e70 f9e65f3c Ntfs!NtfsFsdCreate+0x154
f9e65ef4 f839c124 00000000 f9e65f3c ff80cfb8 nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available. Following frames may be
wrong.
f9e66048 8056316c 81b5cbe8 00000000 81bad970
SYMEVENT!SYMEvent_GetVMDataPtr+0x8764
f9e660d0 8056729a 00000000 f9e66110 00000240 nt!ObpLookupObjectName+0x56a
f9e66124 80570b73 00000000 00000000 00000000 nt!ObOpenObjectByName+0xeb
f9e661a0 80570c42 f9e6631c 00000001 f9e662f4 nt!IopCreateFile+0x407
f9e661fc 80570d0a f9e6631c 00000001 f9e662f4 nt!IoCreateFile+0x8e
f9e6623c 804de7ec f9e6631c 00000001 f9e662f4 nt!NtOpenFile+0x27
f9e6623c 804dcfdd f9e6631c 00000001 f9e662f4 nt!KiFastCallEntry+0xf8
f9e662cc 8059311c f9e6631c 00000001 f9e662f4 nt!ZwOpenFile+0x11
f9e66314 f9f6b92c f9e6632c 00000001 ff7bcf94
nt!IoGetDeviceObjectPointer+0x40
f9e66570 805a0799 ff7c41b8 81a36000 00000000 Virtdisk+0x92c
f9e66640 8069e729 0000011c 00000001 00000000 nt!IopLoadDriver+0x66c
f9e6669c 8069e4b1 00034000 00000000 00000000
nt!IopInitializeSystemDrivers+0x16c
f9e6683c 8069f7f8 80087000 00000000 81bcc788 nt!IoInitSystem+0x7a3
f9e66dac 8057be15 80087000 00000000 00000000 nt!Phase1Initialization+0x9b5
f9e66ddc 804fa4da 8069f086 80087000 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
Ntfs!NtfsRemovePrefix+9
f98db184 f6460408 test byte ptr [esi+0x4],0x8

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Ntfs!NtfsRemovePrefix+9

MODULE_NAME: Ntfs

IMAGE_NAME: Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107eea

STACK_COMMAND: .cxr fffffffff9e65864 ; kb

FAILURE_BUCKET_ID: 0x24_Ntfs!NtfsRemovePrefix+9

BUCKET_ID: 0x24_Ntfs!NtfsRemovePrefix+9

Followup: MachineOwner

Peter Wieland wrote:

>Is your driver a PNP filter driver? Or did you write a non-PNP driver
>that just attaches to HarddiskVolume2 by name.
>
>In a storage stack the device with the name also needs to have the VPB.
>Normally that would be the volume device. I would guess that adding
>your storage driver with a different name managed to confuse the boot
>process, but without a stack trace it’s hard to tell much of anything.
>
>I would suggest that you create your vdisk0 device as a separate device
>and open HarddiskVolume2 instead of attaching to the volume stack.
>
>-p
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@dunstable.org
>Sent: Friday, August 12, 2005 5:48 AM
>To: Windows System Software Devs Interest List
>Subject: [ntdev] Problem with a virtual disk driver
>
>Greetings,
>
>I’m having a problem with a virtual disk driver that I’m writing. At
>the moment, the prototype is simply a pass-through driver to an
>underlying disk device.
>
>My driver currently does the following:
> Creates a device object (vdisk01)
> Creates a symbolic link to it (F:)
> Calls IoGetDeviceObjectPointer on the target disk (HarddiskVolume2)
> Calls IoAttachDeviceToDeviceStatck to attach vdisk01 to
>HarddiskVolume2
>
> In the read and write functions it does:
> IoCopyCurrentIrpStackLocation(Irp)
> IoSetCompletionRoutine(…)
> IoCallDriver(…)
>
>On initial boot all is fine…
>
>HarddiskVolume2 was not formatted and does not have a symbolic link of
>its own.
>F: is available (via my driver) and I formatted it as an NTFS file
>system At this point I could copy files to it and access it normally via
>my pass-through driver.
>
>Then I reboot…
>
>On the call to IoGetDeviceObjectPointer in my driver, we somehow end up
>in Ntfs code that causes the system to crash.
>
>I then reboot in safe mode to remove my driver and then reboot again to
>normal mode.
>
>I use Disk Manager to assign a drive letter to HarddiskVolume2 (Y:) I
>can then access the ntfs file system without problem.
>
>Anybody have any idea as to why the failure in ntfs happens on the call
>to IoGetDeviceObjectPointer in my driver? It appears that the initial
>format and file system activity via my pass-through driver was OK as the
>file system mounts OK now without my driver. Could it be that ntfs is
>‘seeing’
>the disk twice and trying to automount it somehow and that causes a
>problem…
>
>Thanks in advance for any help.
>-bob
>
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
>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: xxxxx@rocketdivision.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

__________ NOD32 1.1193 (20050812) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.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@dunstable.org
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

You will need to mark the virtual volumes a read-only and give them a new
volume serial number. Again, synchronizing the cache so that all three
volumes are the same while one of the volumes has write access is going to
be tough. As with hardware mirrors, you will have to break the mirror to
interrogate (mount) it. Maybe there is something “tricky” you can do with
VolSnap and VSS.

Maybe on all reads, you get data from the main disk and the mirror and
compare the data. If the comparison fails, then fail the disk request and
let the file system handle the rest. This would prevent you from having to
mount virtual volumes. I see no real reason for mounting a mirror while it
is active.

I do not know all of the specifics of your requirements, so I will stop
there. I do not want to stray off into irrelevancy.

Jamey Kirby

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@dunstable.org
Sent: Monday, August 15, 2005 10:59 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Problem with a virtual disk driver

Thanks Jamey. I did wonder about this…

Since I did not expose the underlying disk with a symlink (e.g. F:)… how
does one prevent a file system from mounting a disk (logical or physical)?
I want to eventually support mirroring which will mean (at least) three
entities (real or virtual disks) that will be seen as valid file
systems…

Thanks for your input.

-bob

NTFS is probably choking on one of the following (only speculation):

  • Mounting the same volume twice via two different file system paths via
    two
    different disks. This can confuse the cache and all sorts of things.
    First,
    if the volume you are passing through to is already in use and mounted,
    the
    dirty bit will be set. This means NTFS will try to do a check of the
    volume
    and try to fix it via your virtual disk; I.e. clearing the dirty bit,
    updating other meta-data, etc…

This would result in the original mount and the virtual mount to be out of
sync. This can corrupt your disk and even cause a BSOD

  1. Mounting the same serial number twice via a different disk driver can
    cause havoc with the IO manager.

Again, it is only speculation, but I would look at both of these points.

Jamey Kirby

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Nelson
Sent: Monday, August 15, 2005 5:20 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Problem with a virtual disk driver

Hi Peter,

Thanks for the info. This is a non-PNP driver that attaches to a disk.
I’m new to drivers, I
took this approach based on some earlier feedback from this forum. I’ve
included the debug
info below.

For a generic virtual disk driver, you’re recomendation would be to use
ZwCreateFile,
ZwReadFile, and ZwWriteFile to access the disk(s)? Would there be extra
overhead with
this approach?

-bob

EXCEPTION_RECORD: f9e65b68 – (.exr fffffffff9e65b68)
ExceptionAddress: f98db184 (Ntfs!NtfsRemovePrefix+0x00000009)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 000001fe
Attempt to read from address 000001fe

CONTEXT: f9e65864 – (.cxr fffffffff9e65864)
eax=f9e65c60 ebx=ff7bc420 ecx=00000000 edx=e162a850 esi=000001fa
edi=00000000
eip=f98db184 esp=f9e65c30 ebp=f9e65c34 iopl=0 nv up ei pl nz ac
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010216
Ntfs!NtfsRemovePrefix+0x9:
f98db184 f6460408 test byte ptr [esi+0x4],0x8
Resetting default scope

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0x24

LAST_CONTROL_TRANSFER: from f98e6613 to f98db184

STACK_TEXT:
f9e65c34 f98e6613 000001fa f9e65c88 f9e65c64 Ntfs!NtfsRemovePrefix+0x9
f9e65c44 f990aa6d 81a1da70 f9e65c60 e162a850 Ntfs!NtfsDeleteLcb+0x10
f9e65c64 f98dacb4 81a1da70 f9e60000 e162a880 Ntfs!NtfsDeleteScb+0x205
f9e65c7c f98b57a9 81a1da70 e1626b48 00000000 Ntfs!NtfsRemoveScb+0x88
f9e65c98 f98daa9b 81a1da70 e162a850 00000000
Ntfs!NtfsPrepareFcbForRemoval+0x52
f9e65ce0 f98f8e36 81a1da70 e162a850 00000000
Ntfs!NtfsTeardownStructures+0x5b
f9e65d6c f990db6f 81a1da70 ff7bc420 00000001 Ntfs!NtfsFlushVolume+0x481
f9e65e0c f98ec385 81a1da70 81af2e70 804e8a39
Ntfs!NtfsCommonVolumeOpen+0x18f
f9e65ee4 804e37f7 ff7bc340 81af2e70 f9e65f3c Ntfs!NtfsFsdCreate+0x154
f9e65ef4 f839c124 00000000 f9e65f3c ff80cfb8 nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available. Following frames may be
wrong.
f9e66048 8056316c 81b5cbe8 00000000 81bad970
SYMEVENT!SYMEvent_GetVMDataPtr+0x8764
f9e660d0 8056729a 00000000 f9e66110 00000240 nt!ObpLookupObjectName+0x56a
f9e66124 80570b73 00000000 00000000 00000000 nt!ObOpenObjectByName+0xeb
f9e661a0 80570c42 f9e6631c 00000001 f9e662f4 nt!IopCreateFile+0x407
f9e661fc 80570d0a f9e6631c 00000001 f9e662f4 nt!IoCreateFile+0x8e
f9e6623c 804de7ec f9e6631c 00000001 f9e662f4 nt!NtOpenFile+0x27
f9e6623c 804dcfdd f9e6631c 00000001 f9e662f4 nt!KiFastCallEntry+0xf8
f9e662cc 8059311c f9e6631c 00000001 f9e662f4 nt!ZwOpenFile+0x11
f9e66314 f9f6b92c f9e6632c 00000001 ff7bcf94
nt!IoGetDeviceObjectPointer+0x40
f9e66570 805a0799 ff7c41b8 81a36000 00000000 Virtdisk+0x92c
f9e66640 8069e729 0000011c 00000001 00000000 nt!IopLoadDriver+0x66c
f9e6669c 8069e4b1 00034000 00000000 00000000
nt!IopInitializeSystemDrivers+0x16c
f9e6683c 8069f7f8 80087000 00000000 81bcc788 nt!IoInitSystem+0x7a3
f9e66dac 8057be15 80087000 00000000 00000000 nt!Phase1Initialization+0x9b5
f9e66ddc 804fa4da 8069f086 80087000 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
Ntfs!NtfsRemovePrefix+9
f98db184 f6460408 test byte ptr [esi+0x4],0x8

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Ntfs!NtfsRemovePrefix+9

MODULE_NAME: Ntfs

IMAGE_NAME: Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107eea

STACK_COMMAND: .cxr fffffffff9e65864 ; kb

FAILURE_BUCKET_ID: 0x24_Ntfs!NtfsRemovePrefix+9

BUCKET_ID: 0x24_Ntfs!NtfsRemovePrefix+9

Followup: MachineOwner

Peter Wieland wrote:

>Is your driver a PNP filter driver? Or did you write a non-PNP driver
>that just attaches to HarddiskVolume2 by name.
>
>In a storage stack the device with the name also needs to have the VPB.
>Normally that would be the volume device. I would guess that adding
>your storage driver with a different name managed to confuse the boot
>process, but without a stack trace it’s hard to tell much of anything.
>
>I would suggest that you create your vdisk0 device as a separate device
>and open HarddiskVolume2 instead of attaching to the volume stack.
>
>-p
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@dunstable.org
>Sent: Friday, August 12, 2005 5:48 AM
>To: Windows System Software Devs Interest List
>Subject: [ntdev] Problem with a virtual disk driver
>
>Greetings,
>
>I’m having a problem with a virtual disk driver that I’m writing. At
>the moment, the prototype is simply a pass-through driver to an
>underlying disk device.
>
>My driver currently does the following:
> Creates a device object (vdisk01)
> Creates a symbolic link to it (F:)
> Calls IoGetDeviceObjectPointer on the target disk (HarddiskVolume2)
> Calls IoAttachDeviceToDeviceStatck to attach vdisk01 to
>HarddiskVolume2
>
> In the read and write functions it does:
> IoCopyCurrentIrpStackLocation(Irp)
> IoSetCompletionRoutine(…)
> IoCallDriver(…)
>
>On initial boot all is fine…
>
>HarddiskVolume2 was not formatted and does not have a symbolic link of
>its own.
>F: is available (via my driver) and I formatted it as an NTFS file
>system At this point I could copy files to it and access it normally via
>my pass-through driver.
>
>Then I reboot…
>
>On the call to IoGetDeviceObjectPointer in my driver, we somehow end up
>in Ntfs code that causes the system to crash.
>
>I then reboot in safe mode to remove my driver and then reboot again to
>normal mode.
>
>I use Disk Manager to assign a drive letter to HarddiskVolume2 (Y:) I
>can then access the ntfs file system without problem.
>
>Anybody have any idea as to why the failure in ntfs happens on the call
>to IoGetDeviceObjectPointer in my driver? It appears that the initial
>format and file system activity via my pass-through driver was OK as the
>file system mounts OK now without my driver. Could it be that ntfs is
>‘seeing’
>the disk twice and trying to automount it somehow and that causes a
>problem…
>
>Thanks in advance for any help.
>-bob
>
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
>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: xxxxx@rocketdivision.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

__________ NOD32 1.1193 (20050812) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.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@dunstable.org
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: xxxxx@rocketdivision.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

__________ NOD32 1.1193 (20050812) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com

7

You should be able to use ZwCreateFile to open a file, then
ObReferenceObjectByHandle to get a pointer to the file object, then
build your own IRPs to send through I/O Call Driver (either with
IoAllocateIrp or IoBuildAsynchronousFsdRequest).

I’m assuming you’re working towards building a disk-in-file sort of
driver. You definitely don’t want to attach this sort of driver to any
existing disk stack.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Nelson
Sent: Monday, August 15, 2005 5:20 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Problem with a virtual disk driver

Hi Peter,

Thanks for the info. This is a non-PNP driver that attaches to a disk.

I’m new to drivers, I
took this approach based on some earlier feedback from this forum. I’ve
included the debug info below.

For a generic virtual disk driver, you’re recomendation would be to use
ZwCreateFile, ZwReadFile, and ZwWriteFile to access the disk(s)? Would
there be extra overhead with this approach?

-bob

EXCEPTION_RECORD: f9e65b68 – (.exr fffffffff9e65b68)
ExceptionAddress: f98db184 (Ntfs!NtfsRemovePrefix+0x00000009)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 000001fe
Attempt to read from address 000001fe

CONTEXT: f9e65864 – (.cxr fffffffff9e65864) eax=f9e65c60 ebx=ff7bc420
ecx=00000000 edx=e162a850 esi=000001fa edi=00000000
eip=f98db184 esp=f9e65c30 ebp=f9e65c34 iopl=0 nv up ei pl nz ac
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010216
Ntfs!NtfsRemovePrefix+0x9:
f98db184 f6460408 test byte ptr [esi+0x4],0x8
Resetting default scope

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0x24

LAST_CONTROL_TRANSFER: from f98e6613 to f98db184

STACK_TEXT:
f9e65c34 f98e6613 000001fa f9e65c88 f9e65c64 Ntfs!NtfsRemovePrefix+0x9
f9e65c44 f990aa6d 81a1da70 f9e65c60 e162a850 Ntfs!NtfsDeleteLcb+0x10
f9e65c64 f98dacb4 81a1da70 f9e60000 e162a880 Ntfs!NtfsDeleteScb+0x205
f9e65c7c f98b57a9 81a1da70 e1626b48 00000000 Ntfs!NtfsRemoveScb+0x88
f9e65c98 f98daa9b 81a1da70 e162a850 00000000
Ntfs!NtfsPrepareFcbForRemoval+0x52
f9e65ce0 f98f8e36 81a1da70 e162a850 00000000
Ntfs!NtfsTeardownStructures+0x5b f9e65d6c f990db6f 81a1da70 ff7bc420
00000001 Ntfs!NtfsFlushVolume+0x481 f9e65e0c f98ec385 81a1da70 81af2e70
804e8a39 Ntfs!NtfsCommonVolumeOpen+0x18f
f9e65ee4 804e37f7 ff7bc340 81af2e70 f9e65f3c Ntfs!NtfsFsdCreate+0x154
f9e65ef4 f839c124 00000000 f9e65f3c ff80cfb8 nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available. Following frames may be
wrong.
f9e66048 8056316c 81b5cbe8 00000000 81bad970
SYMEVENT!SYMEvent_GetVMDataPtr+0x8764
f9e660d0 8056729a 00000000 f9e66110 00000240
nt!ObpLookupObjectName+0x56a
f9e66124 80570b73 00000000 00000000 00000000 nt!ObOpenObjectByName+0xeb
f9e661a0 80570c42 f9e6631c 00000001 f9e662f4 nt!IopCreateFile+0x407
f9e661fc 80570d0a f9e6631c 00000001 f9e662f4 nt!IoCreateFile+0x8e
f9e6623c 804de7ec f9e6631c 00000001 f9e662f4 nt!NtOpenFile+0x27 f9e6623c
804dcfdd f9e6631c 00000001 f9e662f4 nt!KiFastCallEntry+0xf8 f9e662cc
8059311c f9e6631c 00000001 f9e662f4 nt!ZwOpenFile+0x11
f9e66314 f9f6b92c f9e6632c 00000001 ff7bcf94
nt!IoGetDeviceObjectPointer+0x40 f9e66570 805a0799 ff7c41b8 81a36000
00000000 Virtdisk+0x92c f9e66640 8069e729 0000011c 00000001 00000000
nt!IopLoadDriver+0x66c f9e6669c 8069e4b1 00034000 00000000 00000000
nt!IopInitializeSystemDrivers+0x16c
f9e6683c 8069f7f8 80087000 00000000 81bcc788 nt!IoInitSystem+0x7a3
f9e66dac 8057be15 80087000 00000000 00000000
nt!Phase1Initialization+0x9b5 f9e66ddc 804fa4da 8069f086 80087000
00000000 nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000
00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
Ntfs!NtfsRemovePrefix+9
f98db184 f6460408 test byte ptr [esi+0x4],0x8

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Ntfs!NtfsRemovePrefix+9

MODULE_NAME: Ntfs

IMAGE_NAME: Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107eea

STACK_COMMAND: .cxr fffffffff9e65864 ; kb

FAILURE_BUCKET_ID: 0x24_Ntfs!NtfsRemovePrefix+9

BUCKET_ID: 0x24_Ntfs!NtfsRemovePrefix+9

Followup: MachineOwner

Peter Wieland wrote:

Is your driver a PNP filter driver? Or did you write a non-PNP driver
that just attaches to HarddiskVolume2 by name.

In a storage stack the device with the name also needs to have the VPB.
Normally that would be the volume device. I would guess that adding
your storage driver with a different name managed to confuse the boot
process, but without a stack trace it’s hard to tell much of anything.

I would suggest that you create your vdisk0 device as a separate device

and open HarddiskVolume2 instead of attaching to the volume stack.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@dunstable.org
Sent: Friday, August 12, 2005 5:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Problem with a virtual disk driver

Greetings,

I’m having a problem with a virtual disk driver that I’m writing. At
the moment, the prototype is simply a pass-through driver to an
underlying disk device.

My driver currently does the following:
Creates a device object (vdisk01)
Creates a symbolic link to it (F:)
Calls IoGetDeviceObjectPointer on the target disk (HarddiskVolume2)
Calls IoAttachDeviceToDeviceStatck to attach vdisk01 to
HarddiskVolume2

In the read and write functions it does:
IoCopyCurrentIrpStackLocation(Irp)
IoSetCompletionRoutine(…)
IoCallDriver(…)

On initial boot all is fine…

HarddiskVolume2 was not formatted and does not have a symbolic link of
its own.
F: is available (via my driver) and I formatted it as an NTFS file
system At this point I could copy files to it and access it normally
via my pass-through driver.

Then I reboot…

On the call to IoGetDeviceObjectPointer in my driver, we somehow end up

in Ntfs code that causes the system to crash.

I then reboot in safe mode to remove my driver and then reboot again to

normal mode.

I use Disk Manager to assign a drive letter to HarddiskVolume2 (Y:) I
can then access the ntfs file system without problem.

Anybody have any idea as to why the failure in ntfs happens on the call

to IoGetDeviceObjectPointer in my driver? It appears that the initial
format and file system activity via my pass-through driver was OK as
the file system mounts OK now without my driver. Could it be that ntfs

is ‘seeing’
the disk twice and trying to automount it somehow and that causes a
problem…

Thanks in advance for any help.
-bob

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@windows.microsoft.com 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: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

8

“…the prototype is simply a pass-through driver to an underlying disk
device.”

This is exactly what he is doing :slight_smile:

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, August 15, 2005 11:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Problem with a virtual disk driver

You should be able to use ZwCreateFile to open a file, then
ObReferenceObjectByHandle to get a pointer to the file object, then
build your own IRPs to send through I/O Call Driver (either with
IoAllocateIrp or IoBuildAsynchronousFsdRequest).

I’m assuming you’re working towards building a disk-in-file sort of
driver. You definitely don’t want to attach this sort of driver to any
existing disk stack.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Nelson
Sent: Monday, August 15, 2005 5:20 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Problem with a virtual disk driver

Hi Peter,

Thanks for the info. This is a non-PNP driver that attaches to a disk.

I’m new to drivers, I
took this approach based on some earlier feedback from this forum. I’ve
included the debug info below.

For a generic virtual disk driver, you’re recomendation would be to use
ZwCreateFile, ZwReadFile, and ZwWriteFile to access the disk(s)? Would
there be extra overhead with this approach?

-bob

EXCEPTION_RECORD: f9e65b68 – (.exr fffffffff9e65b68)
ExceptionAddress: f98db184 (Ntfs!NtfsRemovePrefix+0x00000009)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 000001fe
Attempt to read from address 000001fe

CONTEXT: f9e65864 – (.cxr fffffffff9e65864) eax=f9e65c60 ebx=ff7bc420
ecx=00000000 edx=e162a850 esi=000001fa edi=00000000
eip=f98db184 esp=f9e65c30 ebp=f9e65c34 iopl=0 nv up ei pl nz ac
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010216
Ntfs!NtfsRemovePrefix+0x9:
f98db184 f6460408 test byte ptr [esi+0x4],0x8
Resetting default scope

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0x24

LAST_CONTROL_TRANSFER: from f98e6613 to f98db184

STACK_TEXT:
f9e65c34 f98e6613 000001fa f9e65c88 f9e65c64 Ntfs!NtfsRemovePrefix+0x9
f9e65c44 f990aa6d 81a1da70 f9e65c60 e162a850 Ntfs!NtfsDeleteLcb+0x10
f9e65c64 f98dacb4 81a1da70 f9e60000 e162a880 Ntfs!NtfsDeleteScb+0x205
f9e65c7c f98b57a9 81a1da70 e1626b48 00000000 Ntfs!NtfsRemoveScb+0x88
f9e65c98 f98daa9b 81a1da70 e162a850 00000000
Ntfs!NtfsPrepareFcbForRemoval+0x52
f9e65ce0 f98f8e36 81a1da70 e162a850 00000000
Ntfs!NtfsTeardownStructures+0x5b f9e65d6c f990db6f 81a1da70 ff7bc420
00000001 Ntfs!NtfsFlushVolume+0x481 f9e65e0c f98ec385 81a1da70 81af2e70
804e8a39 Ntfs!NtfsCommonVolumeOpen+0x18f
f9e65ee4 804e37f7 ff7bc340 81af2e70 f9e65f3c Ntfs!NtfsFsdCreate+0x154
f9e65ef4 f839c124 00000000 f9e65f3c ff80cfb8 nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available. Following frames may be
wrong.
f9e66048 8056316c 81b5cbe8 00000000 81bad970
SYMEVENT!SYMEvent_GetVMDataPtr+0x8764
f9e660d0 8056729a 00000000 f9e66110 00000240
nt!ObpLookupObjectName+0x56a
f9e66124 80570b73 00000000 00000000 00000000 nt!ObOpenObjectByName+0xeb
f9e661a0 80570c42 f9e6631c 00000001 f9e662f4 nt!IopCreateFile+0x407
f9e661fc 80570d0a f9e6631c 00000001 f9e662f4 nt!IoCreateFile+0x8e
f9e6623c 804de7ec f9e6631c 00000001 f9e662f4 nt!NtOpenFile+0x27 f9e6623c
804dcfdd f9e6631c 00000001 f9e662f4 nt!KiFastCallEntry+0xf8 f9e662cc
8059311c f9e6631c 00000001 f9e662f4 nt!ZwOpenFile+0x11
f9e66314 f9f6b92c f9e6632c 00000001 ff7bcf94
nt!IoGetDeviceObjectPointer+0x40 f9e66570 805a0799 ff7c41b8 81a36000
00000000 Virtdisk+0x92c f9e66640 8069e729 0000011c 00000001 00000000
nt!IopLoadDriver+0x66c f9e6669c 8069e4b1 00034000 00000000 00000000
nt!IopInitializeSystemDrivers+0x16c
f9e6683c 8069f7f8 80087000 00000000 81bcc788 nt!IoInitSystem+0x7a3
f9e66dac 8057be15 80087000 00000000 00000000
nt!Phase1Initialization+0x9b5 f9e66ddc 804fa4da 8069f086 80087000
00000000 nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000
00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
Ntfs!NtfsRemovePrefix+9
f98db184 f6460408 test byte ptr [esi+0x4],0x8

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Ntfs!NtfsRemovePrefix+9

MODULE_NAME: Ntfs

IMAGE_NAME: Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107eea

STACK_COMMAND: .cxr fffffffff9e65864 ; kb

FAILURE_BUCKET_ID: 0x24_Ntfs!NtfsRemovePrefix+9

BUCKET_ID: 0x24_Ntfs!NtfsRemovePrefix+9

Followup: MachineOwner

Peter Wieland wrote:

Is your driver a PNP filter driver? Or did you write a non-PNP driver
that just attaches to HarddiskVolume2 by name.

In a storage stack the device with the name also needs to have the VPB.
Normally that would be the volume device. I would guess that adding
your storage driver with a different name managed to confuse the boot
process, but without a stack trace it’s hard to tell much of anything.

I would suggest that you create your vdisk0 device as a separate device

and open HarddiskVolume2 instead of attaching to the volume stack.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@dunstable.org
Sent: Friday, August 12, 2005 5:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Problem with a virtual disk driver

Greetings,

I’m having a problem with a virtual disk driver that I’m writing. At
the moment, the prototype is simply a pass-through driver to an
underlying disk device.

My driver currently does the following:
Creates a device object (vdisk01)
Creates a symbolic link to it (F:)
Calls IoGetDeviceObjectPointer on the target disk (HarddiskVolume2)
Calls IoAttachDeviceToDeviceStatck to attach vdisk01 to
HarddiskVolume2

In the read and write functions it does:
IoCopyCurrentIrpStackLocation(Irp)
IoSetCompletionRoutine(…)
IoCallDriver(…)

On initial boot all is fine…

HarddiskVolume2 was not formatted and does not have a symbolic link of
its own.
F: is available (via my driver) and I formatted it as an NTFS file
system At this point I could copy files to it and access it normally
via my pass-through driver.

Then I reboot…

On the call to IoGetDeviceObjectPointer in my driver, we somehow end up

in Ntfs code that causes the system to crash.

I then reboot in safe mode to remove my driver and then reboot again to

normal mode.

I use Disk Manager to assign a drive letter to HarddiskVolume2 (Y:) I
can then access the ntfs file system without problem.

Anybody have any idea as to why the failure in ntfs happens on the call

to IoGetDeviceObjectPointer in my driver? It appears that the initial
format and file system activity via my pass-through driver was OK as
the file system mounts OK now without my driver. Could it be that ntfs

is ‘seeing’
the disk twice and trying to automount it somehow and that causes a
problem…

Thanks in advance for any help.
-bob

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@windows.microsoft.com 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: xxxxx@windows.microsoft.com
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

__________ NOD32 1.1193 (20050812) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com

9

Not a disk-in-file driver… More like a traditional volume manger that
will ‘manage’ many physical disks and then present one or more virtual
disks for file system use.

-bob

You should be able to use ZwCreateFile to open a file, then
ObReferenceObjectByHandle to get a pointer to the file object, then
build your own IRPs to send through I/O Call Driver (either with
IoAllocateIrp or IoBuildAsynchronousFsdRequest).

I’m assuming you’re working towards building a disk-in-file sort of
driver. You definitely don’t want to attach this sort of driver to any
existing disk stack.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Nelson
Sent: Monday, August 15, 2005 5:20 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Problem with a virtual disk driver

Hi Peter,

Thanks for the info. This is a non-PNP driver that attaches to a disk.

I’m new to drivers, I
took this approach based on some earlier feedback from this forum. I’ve
included the debug info below.

For a generic virtual disk driver, you’re recomendation would be to use
ZwCreateFile, ZwReadFile, and ZwWriteFile to access the disk(s)? Would
there be extra overhead with this approach?

-bob

EXCEPTION_RECORD: f9e65b68 – (.exr fffffffff9e65b68)
ExceptionAddress: f98db184 (Ntfs!NtfsRemovePrefix+0x00000009)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 000001fe
Attempt to read from address 000001fe

CONTEXT: f9e65864 – (.cxr fffffffff9e65864) eax=f9e65c60 ebx=ff7bc420
ecx=00000000 edx=e162a850 esi=000001fa edi=00000000
eip=f98db184 esp=f9e65c30 ebp=f9e65c34 iopl=0 nv up ei pl nz ac
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010216
Ntfs!NtfsRemovePrefix+0x9:
f98db184 f6460408 test byte ptr [esi+0x4],0x8
Resetting default scope

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0x24

LAST_CONTROL_TRANSFER: from f98e6613 to f98db184

STACK_TEXT:
f9e65c34 f98e6613 000001fa f9e65c88 f9e65c64 Ntfs!NtfsRemovePrefix+0x9
f9e65c44 f990aa6d 81a1da70 f9e65c60 e162a850 Ntfs!NtfsDeleteLcb+0x10
f9e65c64 f98dacb4 81a1da70 f9e60000 e162a880 Ntfs!NtfsDeleteScb+0x205
f9e65c7c f98b57a9 81a1da70 e1626b48 00000000 Ntfs!NtfsRemoveScb+0x88
f9e65c98 f98daa9b 81a1da70 e162a850 00000000
Ntfs!NtfsPrepareFcbForRemoval+0x52
f9e65ce0 f98f8e36 81a1da70 e162a850 00000000
Ntfs!NtfsTeardownStructures+0x5b f9e65d6c f990db6f 81a1da70 ff7bc420
00000001 Ntfs!NtfsFlushVolume+0x481 f9e65e0c f98ec385 81a1da70 81af2e70
804e8a39 Ntfs!NtfsCommonVolumeOpen+0x18f
f9e65ee4 804e37f7 ff7bc340 81af2e70 f9e65f3c Ntfs!NtfsFsdCreate+0x154
f9e65ef4 f839c124 00000000 f9e65f3c ff80cfb8 nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available. Following frames may be
wrong.
f9e66048 8056316c 81b5cbe8 00000000 81bad970
SYMEVENT!SYMEvent_GetVMDataPtr+0x8764
f9e660d0 8056729a 00000000 f9e66110 00000240
nt!ObpLookupObjectName+0x56a
f9e66124 80570b73 00000000 00000000 00000000 nt!ObOpenObjectByName+0xeb
f9e661a0 80570c42 f9e6631c 00000001 f9e662f4 nt!IopCreateFile+0x407
f9e661fc 80570d0a f9e6631c 00000001 f9e662f4 nt!IoCreateFile+0x8e
f9e6623c 804de7ec f9e6631c 00000001 f9e662f4 nt!NtOpenFile+0x27 f9e6623c
804dcfdd f9e6631c 00000001 f9e662f4 nt!KiFastCallEntry+0xf8 f9e662cc
8059311c f9e6631c 00000001 f9e662f4 nt!ZwOpenFile+0x11
f9e66314 f9f6b92c f9e6632c 00000001 ff7bcf94
nt!IoGetDeviceObjectPointer+0x40 f9e66570 805a0799 ff7c41b8 81a36000
00000000 Virtdisk+0x92c f9e66640 8069e729 0000011c 00000001 00000000
nt!IopLoadDriver+0x66c f9e6669c 8069e4b1 00034000 00000000 00000000
nt!IopInitializeSystemDrivers+0x16c
f9e6683c 8069f7f8 80087000 00000000 81bcc788 nt!IoInitSystem+0x7a3
f9e66dac 8057be15 80087000 00000000 00000000
nt!Phase1Initialization+0x9b5 f9e66ddc 804fa4da 8069f086 80087000
00000000 nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000
00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
Ntfs!NtfsRemovePrefix+9
f98db184 f6460408 test byte ptr [esi+0x4],0x8

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Ntfs!NtfsRemovePrefix+9

MODULE_NAME: Ntfs

IMAGE_NAME: Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107eea

STACK_COMMAND: .cxr fffffffff9e65864 ; kb

FAILURE_BUCKET_ID: 0x24_Ntfs!NtfsRemovePrefix+9

BUCKET_ID: 0x24_Ntfs!NtfsRemovePrefix+9

Followup: MachineOwner

Peter Wieland wrote:

>Is your driver a PNP filter driver? Or did you write a non-PNP driver
>that just attaches to HarddiskVolume2 by name.
>
>In a storage stack the device with the name also needs to have the VPB.
>Normally that would be the volume device. I would guess that adding
>your storage driver with a different name managed to confuse the boot
>process, but without a stack trace it’s hard to tell much of anything.
>
>I would suggest that you create your vdisk0 device as a separate device

>and open HarddiskVolume2 instead of attaching to the volume stack.
>
>-p
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of
>xxxxx@dunstable.org
>Sent: Friday, August 12, 2005 5:48 AM
>To: Windows System Software Devs Interest List
>Subject: [ntdev] Problem with a virtual disk driver
>
>Greetings,
>
>I’m having a problem with a virtual disk driver that I’m writing. At
>the moment, the prototype is simply a pass-through driver to an
>underlying disk device.
>
>My driver currently does the following:
> Creates a device object (vdisk01)
> Creates a symbolic link to it (F:)
> Calls IoGetDeviceObjectPointer on the target disk (HarddiskVolume2)
> Calls IoAttachDeviceToDeviceStatck to attach vdisk01 to
>HarddiskVolume2
>
> In the read and write functions it does:
> IoCopyCurrentIrpStackLocation(Irp)
> IoSetCompletionRoutine(…)
> IoCallDriver(…)
>
>On initial boot all is fine…
>
>HarddiskVolume2 was not formatted and does not have a symbolic link of
>its own.
>F: is available (via my driver) and I formatted it as an NTFS file
>system At this point I could copy files to it and access it normally
>via my pass-through driver.
>
>Then I reboot…
>
>On the call to IoGetDeviceObjectPointer in my driver, we somehow end up

>in Ntfs code that causes the system to crash.
>
>I then reboot in safe mode to remove my driver and then reboot again to

>normal mode.
>
>I use Disk Manager to assign a drive letter to HarddiskVolume2 (Y:) I
>can then access the ntfs file system without problem.
>
>Anybody have any idea as to why the failure in ntfs happens on the call

>to IoGetDeviceObjectPointer in my driver? It appears that the initial
>format and file system activity via my pass-through driver was OK as
>the file system mounts OK now without my driver. Could it be that ntfs

>is ‘seeing’
>the disk twice and trying to automount it somehow and that causes a
>problem…
>
>Thanks in advance for any help.
>-bob
>
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as:
>xxxxx@windows.microsoft.com 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: xxxxx@windows.microsoft.com
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

10

Then you also need to figure out how to hide the existing devices so
that they aren’t exposed as drives.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@dunstable.org
Sent: Monday, August 15, 2005 11:55 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Problem with a virtual disk driver

Not a disk-in-file driver… More like a traditional volume manger that
will ‘manage’ many physical disks and then present one or more virtual
disks for file system use.

-bob

You should be able to use ZwCreateFile to open a file, then
ObReferenceObjectByHandle to get a pointer to the file object, then
build your own IRPs to send through I/O Call Driver (either with
IoAllocateIrp or IoBuildAsynchronousFsdRequest).

I’m assuming you’re working towards building a disk-in-file sort of
driver. You definitely don’t want to attach this sort of driver to
any existing disk stack.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Nelson
Sent: Monday, August 15, 2005 5:20 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Problem with a virtual disk driver

Hi Peter,

Thanks for the info. This is a non-PNP driver that attaches to a
disk.

I’m new to drivers, I
took this approach based on some earlier feedback from this forum.
I’ve included the debug info below.

For a generic virtual disk driver, you’re recomendation would be to
use ZwCreateFile, ZwReadFile, and ZwWriteFile to access the disk(s)?
Would there be extra overhead with this approach?

-bob

EXCEPTION_RECORD: f9e65b68 – (.exr fffffffff9e65b68)
ExceptionAddress: f98db184 (Ntfs!NtfsRemovePrefix+0x00000009)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 000001fe
Attempt to read from address 000001fe

CONTEXT: f9e65864 – (.cxr fffffffff9e65864) eax=f9e65c60
ebx=ff7bc420 ecx=00000000 edx=e162a850 esi=000001fa edi=00000000
eip=f98db184 esp=f9e65c30 ebp=f9e65c34 iopl=0 nv up ei pl nz
ac
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010216
Ntfs!NtfsRemovePrefix+0x9:
f98db184 f6460408 test byte ptr [esi+0x4],0x8
Resetting default scope

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0x24

LAST_CONTROL_TRANSFER: from f98e6613 to f98db184

STACK_TEXT:
f9e65c34 f98e6613 000001fa f9e65c88 f9e65c64 Ntfs!NtfsRemovePrefix+0x9
f9e65c44 f990aa6d 81a1da70 f9e65c60 e162a850 Ntfs!NtfsDeleteLcb+0x10
f9e65c64 f98dacb4 81a1da70 f9e60000 e162a880 Ntfs!NtfsDeleteScb+0x205
f9e65c7c f98b57a9 81a1da70 e1626b48 00000000 Ntfs!NtfsRemoveScb+0x88
f9e65c98 f98daa9b 81a1da70 e162a850 00000000
Ntfs!NtfsPrepareFcbForRemoval+0x52
f9e65ce0 f98f8e36 81a1da70 e162a850 00000000
Ntfs!NtfsTeardownStructures+0x5b f9e65d6c f990db6f 81a1da70 ff7bc420
00000001 Ntfs!NtfsFlushVolume+0x481 f9e65e0c f98ec385 81a1da70
81af2e70
804e8a39 Ntfs!NtfsCommonVolumeOpen+0x18f
f9e65ee4 804e37f7 ff7bc340 81af2e70 f9e65f3c Ntfs!NtfsFsdCreate+0x154
f9e65ef4 f839c124 00000000 f9e65f3c ff80cfb8 nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available. Following frames may
be wrong.
f9e66048 8056316c 81b5cbe8 00000000 81bad970
SYMEVENT!SYMEvent_GetVMDataPtr+0x8764
f9e660d0 8056729a 00000000 f9e66110 00000240
nt!ObpLookupObjectName+0x56a
f9e66124 80570b73 00000000 00000000 00000000
nt!ObOpenObjectByName+0xeb f9e661a0 80570c42 f9e6631c 00000001
f9e662f4 nt!IopCreateFile+0x407 f9e661fc 80570d0a f9e6631c 00000001
f9e662f4 nt!IoCreateFile+0x8e f9e6623c 804de7ec f9e6631c 00000001
f9e662f4 nt!NtOpenFile+0x27 f9e6623c 804dcfdd f9e6631c 00000001
f9e662f4 nt!KiFastCallEntry+0xf8 f9e662cc 8059311c f9e6631c 00000001
f9e662f4 nt!ZwOpenFile+0x11
f9e66314 f9f6b92c f9e6632c 00000001 ff7bcf94
nt!IoGetDeviceObjectPointer+0x40 f9e66570 805a0799 ff7c41b8 81a36000
00000000 Virtdisk+0x92c f9e66640 8069e729 0000011c 00000001 00000000
nt!IopLoadDriver+0x66c f9e6669c 8069e4b1 00034000 00000000 00000000
nt!IopInitializeSystemDrivers+0x16c
f9e6683c 8069f7f8 80087000 00000000 81bcc788 nt!IoInitSystem+0x7a3
f9e66dac 8057be15 80087000 00000000 00000000
nt!Phase1Initialization+0x9b5 f9e66ddc 804fa4da 8069f086 80087000
00000000 nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000
00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
Ntfs!NtfsRemovePrefix+9
f98db184 f6460408 test byte ptr [esi+0x4],0x8

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Ntfs!NtfsRemovePrefix+9

MODULE_NAME: Ntfs

IMAGE_NAME: Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107eea

STACK_COMMAND: .cxr fffffffff9e65864 ; kb

FAILURE_BUCKET_ID: 0x24_Ntfs!NtfsRemovePrefix+9

BUCKET_ID: 0x24_Ntfs!NtfsRemovePrefix+9

Followup: MachineOwner

Peter Wieland wrote:

>Is your driver a PNP filter driver? Or did you write a non-PNP driver

>that just attaches to HarddiskVolume2 by name.
>
>In a storage stack the device with the name also needs to have the
VPB.
>Normally that would be the volume device. I would guess that adding
>your storage driver with a different name managed to confuse the boot
>process, but without a stack trace it’s hard to tell much of anything.
>
>I would suggest that you create your vdisk0 device as a separate
>device

>and open HarddiskVolume2 instead of attaching to the volume stack.
>
>-p
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of
>xxxxx@dunstable.org
>Sent: Friday, August 12, 2005 5:48 AM
>To: Windows System Software Devs Interest List
>Subject: [ntdev] Problem with a virtual disk driver
>
>Greetings,
>
>I’m having a problem with a virtual disk driver that I’m writing. At
>the moment, the prototype is simply a pass-through driver to an
>underlying disk device.
>
>My driver currently does the following:
> Creates a device object (vdisk01)
> Creates a symbolic link to it (F:)
> Calls IoGetDeviceObjectPointer on the target disk (HarddiskVolume2)
> Calls IoAttachDeviceToDeviceStatck to attach vdisk01 to
>HarddiskVolume2
>
> In the read and write functions it does:
> IoCopyCurrentIrpStackLocation(Irp)
> IoSetCompletionRoutine(…)
> IoCallDriver(…)
>
>On initial boot all is fine…
>
>HarddiskVolume2 was not formatted and does not have a symbolic link of

>its own.
>F: is available (via my driver) and I formatted it as an NTFS file
>system At this point I could copy files to it and access it normally
>via my pass-through driver.
>
>Then I reboot…
>
>On the call to IoGetDeviceObjectPointer in my driver, we somehow end
>up

>in Ntfs code that causes the system to crash.
>
>I then reboot in safe mode to remove my driver and then reboot again
>to

>normal mode.
>
>I use Disk Manager to assign a drive letter to HarddiskVolume2 (Y:) I
>can then access the ntfs file system without problem.
>
>Anybody have any idea as to why the failure in ntfs happens on the
>call

>to IoGetDeviceObjectPointer in my driver? It appears that the initial

>format and file system activity via my pass-through driver was OK as
>the file system mounts OK now without my driver. Could it be that
>ntfs

>is ‘seeing’
>the disk twice and trying to automount it somehow and that causes a
>problem…
>
>Thanks in advance for any help.
>-bob
>
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as:
>xxxxx@windows.microsoft.com 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:
xxxxx@windows.microsoft.com 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: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

11

It would be ideal to be able to hide the physical devices that I’m managing,
but at the moment I’d settle for a way to prevent mounts of the
filesystem… Any ideas?

Thanks again,
-bob
----- Original Message -----
From: “Peter Wieland”
To: “Windows System Software Devs Interest List”
Sent: Monday, August 15, 2005 3:49 PM
Subject: RE: [ntdev] Problem with a virtual disk driver

Then you also need to figure out how to hide the existing devices so
that they aren’t exposed as drives.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@dunstable.org
Sent: Monday, August 15, 2005 11:55 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Problem with a virtual disk driver

Not a disk-in-file driver… More like a traditional volume manger that
will ‘manage’ many physical disks and then present one or more virtual
disks for file system use.

-bob

> You should be able to use ZwCreateFile to open a file, then
> ObReferenceObjectByHandle to get a pointer to the file object, then
> build your own IRPs to send through I/O Call Driver (either with
> IoAllocateIrp or IoBuildAsynchronousFsdRequest).
>
> I’m assuming you’re working towards building a disk-in-file sort of
> driver. You definitely don’t want to attach this sort of driver to
> any existing disk stack.
>
> -p
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Bob Nelson
> Sent: Monday, August 15, 2005 5:20 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Problem with a virtual disk driver
>
> Hi Peter,
>
> Thanks for the info. This is a non-PNP driver that attaches to a
disk.
>
> I’m new to drivers, I
> took this approach based on some earlier feedback from this forum.
> I’ve included the debug info below.
>
> For a generic virtual disk driver, you’re recomendation would be to
> use ZwCreateFile, ZwReadFile, and ZwWriteFile to access the disk(s)?
> Would there be extra overhead with this approach?
>
> -bob
>
> EXCEPTION_RECORD: f9e65b68 – (.exr fffffffff9e65b68)
> ExceptionAddress: f98db184 (Ntfs!NtfsRemovePrefix+0x00000009)
> ExceptionCode: c0000005 (Access violation)
> ExceptionFlags: 00000000
> NumberParameters: 2
> Parameter[0]: 00000000
> Parameter[1]: 000001fe
> Attempt to read from address 000001fe
>
> CONTEXT: f9e65864 – (.cxr fffffffff9e65864) eax=f9e65c60
> ebx=ff7bc420 ecx=00000000 edx=e162a850 esi=000001fa edi=00000000
> eip=f98db184 esp=f9e65c30 ebp=f9e65c34 iopl=0 nv up ei pl nz
ac
> po nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010216
> Ntfs!NtfsRemovePrefix+0x9:
> f98db184 f6460408 test byte ptr [esi+0x4],0x8
> Resetting default scope
>
> DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO
>
> BUGCHECK_STR: 0x24
>
> LAST_CONTROL_TRANSFER: from f98e6613 to f98db184
>
> STACK_TEXT:
> f9e65c34 f98e6613 000001fa f9e65c88 f9e65c64 Ntfs!NtfsRemovePrefix+0x9
> f9e65c44 f990aa6d 81a1da70 f9e65c60 e162a850 Ntfs!NtfsDeleteLcb+0x10
> f9e65c64 f98dacb4 81a1da70 f9e60000 e162a880 Ntfs!NtfsDeleteScb+0x205
> f9e65c7c f98b57a9 81a1da70 e1626b48 00000000 Ntfs!NtfsRemoveScb+0x88
> f9e65c98 f98daa9b 81a1da70 e162a850 00000000
> Ntfs!NtfsPrepareFcbForRemoval+0x52
> f9e65ce0 f98f8e36 81a1da70 e162a850 00000000
> Ntfs!NtfsTeardownStructures+0x5b f9e65d6c f990db6f 81a1da70 ff7bc420
> 00000001 Ntfs!NtfsFlushVolume+0x481 f9e65e0c f98ec385 81a1da70
> 81af2e70
> 804e8a39 Ntfs!NtfsCommonVolumeOpen+0x18f
> f9e65ee4 804e37f7 ff7bc340 81af2e70 f9e65f3c Ntfs!NtfsFsdCreate+0x154
> f9e65ef4 f839c124 00000000 f9e65f3c ff80cfb8 nt!IopfCallDriver+0x31
> WARNING: Stack unwind information not available. Following frames may
> be wrong.
> f9e66048 8056316c 81b5cbe8 00000000 81bad970
> SYMEVENT!SYMEvent_GetVMDataPtr+0x8764
> f9e660d0 8056729a 00000000 f9e66110 00000240
> nt!ObpLookupObjectName+0x56a
> f9e66124 80570b73 00000000 00000000 00000000
> nt!ObOpenObjectByName+0xeb f9e661a0 80570c42 f9e6631c 00000001
> f9e662f4 nt!IopCreateFile+0x407 f9e661fc 80570d0a f9e6631c 00000001
> f9e662f4 nt!IoCreateFile+0x8e f9e6623c 804de7ec f9e6631c 00000001
> f9e662f4 nt!NtOpenFile+0x27 f9e6623c 804dcfdd f9e6631c 00000001
> f9e662f4 nt!KiFastCallEntry+0xf8 f9e662cc 8059311c f9e6631c 00000001
> f9e662f4 nt!ZwOpenFile+0x11
> f9e66314 f9f6b92c f9e6632c 00000001 ff7bcf94
> nt!IoGetDeviceObjectPointer+0x40 f9e66570 805a0799 ff7c41b8 81a36000
> 00000000 Virtdisk+0x92c f9e66640 8069e729 0000011c 00000001 00000000
> nt!IopLoadDriver+0x66c f9e6669c 8069e4b1 00034000 00000000 00000000
> nt!IopInitializeSystemDrivers+0x16c
> f9e6683c 8069f7f8 80087000 00000000 81bcc788 nt!IoInitSystem+0x7a3
> f9e66dac 8057be15 80087000 00000000 00000000
> nt!Phase1Initialization+0x9b5 f9e66ddc 804fa4da 8069f086 80087000
> 00000000 nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000
> 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> FOLLOWUP_IP:
> Ntfs!NtfsRemovePrefix+9
> f98db184 f6460408 test byte ptr [esi+0x4],0x8
>
> SYMBOL_STACK_INDEX: 0
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: Ntfs!NtfsRemovePrefix+9
>
> MODULE_NAME: Ntfs
>
> IMAGE_NAME: Ntfs.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 41107eea
>
> STACK_COMMAND: .cxr fffffffff9e65864 ; kb
>
> FAILURE_BUCKET_ID: 0x24_Ntfs!NtfsRemovePrefix+9
>
> BUCKET_ID: 0x24_Ntfs!NtfsRemovePrefix+9
>
> Followup: MachineOwner
> ---------
>
>
> Peter Wieland wrote:
>
>>Is your driver a PNP filter driver? Or did you write a non-PNP driver

>>that just attaches to HarddiskVolume2 by name.
>>
>>In a storage stack the device with the name also needs to have the
VPB.
>>Normally that would be the volume device. I would guess that adding
>>your storage driver with a different name managed to confuse the boot
>>process, but without a stack trace it’s hard to tell much of anything.
>>
>>I would suggest that you create your vdisk0 device as a separate
>>device
>
>>and open HarddiskVolume2 instead of attaching to the volume stack.
>>
>>-p
>>
>>-----Original Message-----
>>From: xxxxx@lists.osr.com
>>[mailto:xxxxx@lists.osr.com] On Behalf Of
>>xxxxx@dunstable.org
>>Sent: Friday, August 12, 2005 5:48 AM
>>To: Windows System Software Devs Interest List
>>Subject: [ntdev] Problem with a virtual disk driver
>>
>>Greetings,
>>
>>I’m having a problem with a virtual disk driver that I’m writing. At
>>the moment, the prototype is simply a pass-through driver to an
>>underlying disk device.
>>
>>My driver currently does the following:
>> Creates a device object (vdisk01)
>> Creates a symbolic link to it (F:)
>> Calls IoGetDeviceObjectPointer on the target disk (HarddiskVolume2)
>> Calls IoAttachDeviceToDeviceStatck to attach vdisk01 to
>>HarddiskVolume2
>>
>> In the read and write functions it does:
>> IoCopyCurrentIrpStackLocation(Irp)
>> IoSetCompletionRoutine(…)
>> IoCallDriver(…)
>>
>>On initial boot all is fine…
>>
>>HarddiskVolume2 was not formatted and does not have a symbolic link of

>>its own.
>>F: is available (via my driver) and I formatted it as an NTFS file
>>system At this point I could copy files to it and access it normally
>>via my pass-through driver.
>>
>>Then I reboot…
>>
>>On the call to IoGetDeviceObjectPointer in my driver, we somehow end
>>up
>
>>in Ntfs code that causes the system to crash.
>>
>>I then reboot in safe mode to remove my driver and then reboot again
>>to
>
>>normal mode.
>>
>>I use Disk Manager to assign a drive letter to HarddiskVolume2 (Y:) I
>>can then access the ntfs file system without problem.
>>
>>Anybody have any idea as to why the failure in ntfs happens on the
>>call
>
>>to IoGetDeviceObjectPointer in my driver? It appears that the initial

>>format and file system activity via my pass-through driver was OK as
>>the file system mounts OK now without my driver. Could it be that
>>ntfs
>
>>is ‘seeing’
>>the disk twice and trying to automount it somehow and that causes a
>>problem…
>>
>>Thanks in advance for any help.
>>-bob
>>
>>
>>—
>>Questions? First check the Kernel Driver FAQ at
>>http://www.osronline.com/article.cfm?id=256
>>
>>You are currently subscribed to ntdev as:
>>xxxxx@windows.microsoft.com 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:
> xxxxx@windows.microsoft.com 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: xxxxx@windows.microsoft.com
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