BSOD REFERENCE_BY_POINTER

NTFSD
41

Dear All,

How can I print the contents of the incoming write request buffer if I am using DIRECT_IO. In other words I want to see the contents of the incoming write request MdlAddress in case of DIRECT_IO.

On one of the links on the list I had seen something like this:
PCHAR pWriteBuff;

pWriteBuff=MmGetSystemAddressForMdlSafe(Irp->MdlAddress, NormalPagePriority);
DbgPrint(“Write IRP (Direct): %wZ\n”,&pWriteBuff);

In my case it is giving DRIVER_IRQL_NOT_LESS_OR_EQUAL.

What can be the problem?

Thanks,
Uzair Lakhani

42

Well, first is the MDL locked to memory? And second what is the IRQL
when you make this call? One of those is probably the failure.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“xxxxx@gmail.com” wrote in message
news:xxxxx@ntfsd:

> Dear All,
>
> How can I print the contents of the incoming write request buffer if I am using DIRECT_IO. In other words I want to see the contents of the incoming write request MdlAddress in case of DIRECT_IO.
>
> On one of the links on the list I had seen something like this:
> PCHAR pWriteBuff;
>
> pWriteBuff=MmGetSystemAddressForMdlSafe(Irp->MdlAddress, NormalPagePriority);
> DbgPrint(“Write IRP (Direct): %wZ\n”,&pWriteBuff);
>
> In my case it is giving DRIVER_IRQL_NOT_LESS_OR_EQUAL.
>
> What can be the problem?
>
> Thanks,
> Uzair Lakhani

43

> Dear All,

How can I print the contents of the incoming write request buffer if I am
using DIRECT_IO. In other words I want to see the contents of the incoming
write request MdlAddress in case of DIRECT_IO.

On one of the links on the list I had seen something like this:
PCHAR pWriteBuff;

pWriteBuff=MmGetSystemAddressForMdlSafe(Irp->MdlAddress,
NormalPagePriority);
DbgPrint(“Write IRP (Direct): %wZ\n”,&pWriteBuff);

In my case it is giving DRIVER_IRQL_NOT_LESS_OR_EQUAL.

Well, since you have waved your hands and basically said “My program
doesn’t work, what did I do wrong?” te answer is “you have a bug” and the
correct solution is “fix it”. Had you provided USEFUL information, such
as the place where that code appears, the !analyze -v output, and an
indication of which line of your code was being executed when this crash
occurred, there is a possibility you might get a meaningful answer.

Also, you failed to test the value stored in pWriteBuff is NULL; why would
you assume this call succeeded?

You also seem to assume that %wZ will print the data properly. How did
you arrive at this conclusion? Do you know the IRQL level you are running
at? Did you RTFM the part about %wZ can only be executed at
PASSIVE_LEVEL? Did you read about where %wZ is used to print a
UNICODE_STRING? You failed to pass a pointer to a UNICODE_STRING, so how,
exactly, did you arrive at the conclusion that %wZ was the correct format
specification to a PWCHAR, which, most certainly, is not a UNICODE_STRING?
Why is it you think the data that is being passed is actually a text
buffer of Unicode characters? Well, you have so many errors there that it
could not possibly work, let alone at elevated IRQL. When all else fails,
RTFM.

Fix every one of these problems, and it might work. Leave any of them,
you are pretty much guarantted it will fail catastrophically. Had you
read the !analyze -v output, much of this tould have been obvious.

Also, the last I looked, DbgPrint had a maximum of 512 characters, so how
do you handle the case where the buffer contains non-Unicode characters or
more than 512 of them?
joe

Note that I discovered all these problems just by reading the documentation!

What can be the problem?

Thanks,
Uzair Lakhani

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

44

Dear Members,

Thanks for the input. I am doing this in my dispatch write routine. The IRQL at this is PASSIVE_LEVEL. I think the MDL will be locked by the kernel first and then the IRP given to my dispatch routine for writing to the device. I myself have not locked the MDL.

Sometimes DRIVER_IRQL_NOT_LESS_OR_EQUAL and sometimes IRQL_NOT_LESS_OR_EQUAL are coming.

If a DbgPrint viewer is open then this bug check occurs if the viewer is not running then bug check does not come. The sys file mentioned on BSD is DbgPrnHk.sys

Below is the output of !analyze -v command:

Crash Dump Analysis provided by OSR Open Systems Resources, Inc. (http://www.osr.com)
Online Crash Dump Analysis Service
See http://www.osronline.com for more information
Windows 7 Kernel Version 7600 MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.x86fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0x82a47000 PsLoadedModuleList = 0x82b8f810
Debug session time: Wed May 15 01:05:50.191 2013 (UTC - 4:00)
System Uptime: 0 days 0:02:50.204
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 87801000, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: aa8b11bb, address which referenced memory

Debugging Details:

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

READ_ADDRESS: GetPointerFromAddress: unable to read from 82baf718
Unable to read MiSystemVaType memory at 82b8f160
87801000

CURRENT_IRQL: 0

FAULTING_IP:
DbgPrnHk+31bb
aa8b11bb f3a5 rep movs dword ptr es:[edi],dword ptr [esi]

ADDITIONAL_DEBUG_TEXT: The trap occurred when interrupts are disabled on the target.

BUGCHECK_STR: DISABLED_INTERRUPT_FAULT

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: System

TRAP_FRAME: b88bcb14 – (.trap 0xffffffffb88bcb14)
ErrCode = 00000000
eax=00000068 ebx=852cde80 ecx=00000018 edx=00000068 esi=87801000 edi=852cdea0
eip=aa8b11bb esp=b88bcb88 ebp=b88bcc64 iopl=0 nv up di pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010002
DbgPrnHk+0x31bb:
aa8b11bb f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
Resetting default scope

LAST_CONTROL_TRANSFER: from aa8b11bb to 82a8d7eb

STACK_TEXT:
b88bcb14 aa8b11bb badb0d00 00000068 00010000 nt!KiTrap0E+0x2cf
WARNING: Stack unwind information not available. Following frames may be wrong.
b88bcc64 aa8b1525 00000000 87800ff8 fda1b00f DbgPrnHk+0x31bb
b88bcc88 aa8b158c 00000065 00000003 8fd180cc DbgPrnHk+0x3525
b88bccb8 82a4828e 00000065 00000003 8fd180cc DbgPrnHk+0x358c
b88bccd8 8fd14725 8fd180cc b88bcd04 b88bcd28 nt!DbgPrint+0x1d
b88bccf8 82a834bc 864b0e00 8520a000 8ab0f0c0 DTSC4Own+0x1725
b88bcd10 88a2991c 8ab0f020 b88bcd34 82ab710e nt!IofCallDriver+0x63
b88bcd1c 82ab710e 8ab0f0c0 00000000 ffffffff Ntfs!NtfsStorageDriverCallout+0x14
b88bcd1c 82ab7205 8ab0f0c0 00000000 ffffffff nt!KiSwapKernelStackAndExit+0x15a
8ab0f030 00000000 00000000 00000000 00000000 nt!KiSwitchKernelStackAndCallout+0x31

STACK_COMMAND: kb

FOLLOWUP_IP:
DbgPrnHk+31bb
aa8b11bb f3a5 rep movs dword ptr es:[edi],dword ptr [esi]

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: DbgPrnHk+31bb

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: DbgPrnHk

IMAGE_NAME: DbgPrnHk.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d871ac0

FAILURE_BUCKET_ID: DISABLED_INTERRUPT_FAULT_DbgPrnHk+31bb

BUCKET_ID: DISABLED_INTERRUPT_FAULT_DbgPrnHk+31bb

Followup: MachineOwner

This free analysis is provided by OSR Open Systems Resources, Inc.
Want a deeper understanding of crash dump analysis? Check out our Windows Kernel Debugging and Crash Dump Analysis Seminar (opens in new tab/window)

I want to see the contents of the write request.

Thanks,
Uzair Lakhani

45

> Dear Members,

Thanks for the input. I am doing this in my dispatch write routine. The
IRQL at this is PASSIVE_LEVEL. I think the MDL will be locked by the
kernel first and then the IRP given to my dispatch routine for writing to
the device. I myself have not locked the MDL.

Sometimes DRIVER_IRQL_NOT_LESS_OR_EQUAL and sometimes
IRQL_NOT_LESS_OR_EQUAL are coming.

If a DbgPrint viewer is open then this bug check occurs if the viewer is
not running then bug check does not come. The sys file mentioned on BSD is
DbgPrnHk.sys

Not surprising; if the viewer is not running, it won’t bother to call the
%wZ passing an erroneous argument. You have to deal with that problem,
too; calling it from PASSIVE_LEVEL with the same arguments you use now
will still crash.
joe

Below is the output of !analyze -v command:

Crash Dump Analysis provided by OSR Open Systems Resources, Inc.
(http://www.osr.com)
Online Crash Dump Analysis Service
See http://www.osronline.com for more information
Windows 7 Kernel Version 7600 MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.x86fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0x82a47000 PsLoadedModuleList = 0x82b8f810
Debug session time: Wed May 15 01:05:50.191 2013 (UTC - 4:00)
System Uptime: 0 days 0:02:50.204
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address
at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 87801000, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: aa8b11bb, address which referenced memory

Debugging Details:

TRIAGER: Could not open triage file :
e:\dump_analysis\program\triage\modclass.ini, error 2

READ_ADDRESS: GetPointerFromAddress: unable to read from 82baf718
Unable to read MiSystemVaType memory at 82b8f160
87801000

CURRENT_IRQL: 0

FAULTING_IP:
DbgPrnHk+31bb
aa8b11bb f3a5 rep movs dword ptr es:[edi],dword ptr [esi]

ADDITIONAL_DEBUG_TEXT: The trap occurred when interrupts are disabled on
the target.

BUGCHECK_STR: DISABLED_INTERRUPT_FAULT

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: System

TRAP_FRAME: b88bcb14 – (.trap 0xffffffffb88bcb14)
ErrCode = 00000000
eax=00000068 ebx=852cde80 ecx=00000018 edx=00000068 esi=87801000
edi=852cdea0
eip=aa8b11bb esp=b88bcb88 ebp=b88bcc64 iopl=0 nv up di pl nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010002
DbgPrnHk+0x31bb:
aa8b11bb f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
Resetting default scope

LAST_CONTROL_TRANSFER: from aa8b11bb to 82a8d7eb

STACK_TEXT:
b88bcb14 aa8b11bb badb0d00 00000068 00010000 nt!KiTrap0E+0x2cf
WARNING: Stack unwind information not available. Following frames may be
wrong.
b88bcc64 aa8b1525 00000000 87800ff8 fda1b00f DbgPrnHk+0x31bb
b88bcc88 aa8b158c 00000065 00000003 8fd180cc DbgPrnHk+0x3525
b88bccb8 82a4828e 00000065 00000003 8fd180cc DbgPrnHk+0x358c
b88bccd8 8fd14725 8fd180cc b88bcd04 b88bcd28 nt!DbgPrint+0x1d
b88bccf8 82a834bc 864b0e00 8520a000 8ab0f0c0 DTSC4Own+0x1725
b88bcd10 88a2991c 8ab0f020 b88bcd34 82ab710e nt!IofCallDriver+0x63
b88bcd1c 82ab710e 8ab0f0c0 00000000 ffffffff
Ntfs!NtfsStorageDriverCallout+0x14
b88bcd1c 82ab7205 8ab0f0c0 00000000 ffffffff
nt!KiSwapKernelStackAndExit+0x15a
8ab0f030 00000000 00000000 00000000 00000000
nt!KiSwitchKernelStackAndCallout+0x31

STACK_COMMAND: kb

FOLLOWUP_IP:
DbgPrnHk+31bb
aa8b11bb f3a5 rep movs dword ptr es:[edi],dword ptr [esi]

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: DbgPrnHk+31bb

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: DbgPrnHk

IMAGE_NAME: DbgPrnHk.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d871ac0

FAILURE_BUCKET_ID: DISABLED_INTERRUPT_FAULT_DbgPrnHk+31bb

BUCKET_ID: DISABLED_INTERRUPT_FAULT_DbgPrnHk+31bb

Followup: MachineOwner

This free analysis is provided by OSR Open Systems Resources, Inc.
Want a deeper understanding of crash dump analysis? Check out our Windows
Kernel Debugging and Crash Dump Analysis Seminar (opens in new tab/window)

I want to see the contents of the write request.

Thanks,
Uzair Lakhani

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

46

> Dear Members,

Thanks for the input. I am doing this in my dispatch write routine. The
IRQL at this is PASSIVE_LEVEL. I think the MDL will be locked by the
kernel first and then the IRP given to my dispatch routine for writing to
the device. I myself have not locked the MDL.

Sometimes DRIVER_IRQL_NOT_LESS_OR_EQUAL and sometimes
IRQL_NOT_LESS_OR_EQUAL are coming.

Sorry, I meant to check the IRQL level. It is 0, which is PASSIVE_LEVEL.
So the problem was passing a pointer to a nonsensical type to be formatted
with %wZ.

I think you said this was a filter driver. Unless it is called directly
from the I/O Manager, in the context of the user thread, you have to
assume that the IRQL level is unknowable, and can be anything < DIRQL.
Only the topmost driver is guaranteed to be called in the thread context
of the application thread. That guarantee, AFAIK, does not carry to the
dispatch routine of any lower-level driver. If it is running at
PASSIVE_LEVEL in your dispatch routine, you should probably consider that
at best a fortuitous accident, one you CANNOT rely on. You have no idea
what drivers might end up above you, and how tey might behave. So I’m not
sure why you are asserting that your dispaatch-write routine is guaranteed
to be at PASSIVE_LEVEL, even if, in the one case shown here, it actually
is.

joe

If a DbgPrint viewer is open then this bug check occurs if the viewer is
not running then bug check does not come. The sys file mentioned on BSD is
DbgPrnHk.sys

Below is the output of !analyze -v command:

Crash Dump Analysis provided by OSR Open Systems Resources, Inc.
(http://www.osr.com)
Online Crash Dump Analysis Service
See http://www.osronline.com for more information
Windows 7 Kernel Version 7600 MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.x86fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0x82a47000 PsLoadedModuleList = 0x82b8f810
Debug session time: Wed May 15 01:05:50.191 2013 (UTC - 4:00)
System Uptime: 0 days 0:02:50.204
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address
at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 87801000, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: aa8b11bb, address which referenced memory

Debugging Details:

TRIAGER: Could not open triage file :
e:\dump_analysis\program\triage\modclass.ini, error 2

READ_ADDRESS: GetPointerFromAddress: unable to read from 82baf718
Unable to read MiSystemVaType memory at 82b8f160
87801000

CURRENT_IRQL: 0

FAULTING_IP:
DbgPrnHk+31bb
aa8b11bb f3a5 rep movs dword ptr es:[edi],dword ptr [esi]

ADDITIONAL_DEBUG_TEXT: The trap occurred when interrupts are disabled on
the target.

BUGCHECK_STR: DISABLED_INTERRUPT_FAULT

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: System

TRAP_FRAME: b88bcb14 – (.trap 0xffffffffb88bcb14)
ErrCode = 00000000
eax=00000068 ebx=852cde80 ecx=00000018 edx=00000068 esi=87801000
edi=852cdea0
eip=aa8b11bb esp=b88bcb88 ebp=b88bcc64 iopl=0 nv up di pl nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010002
DbgPrnHk+0x31bb:
aa8b11bb f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
Resetting default scope

LAST_CONTROL_TRANSFER: from aa8b11bb to 82a8d7eb

STACK_TEXT:
b88bcb14 aa8b11bb badb0d00 00000068 00010000 nt!KiTrap0E+0x2cf
WARNING: Stack unwind information not available. Following frames may be
wrong.
b88bcc64 aa8b1525 00000000 87800ff8 fda1b00f DbgPrnHk+0x31bb
b88bcc88 aa8b158c 00000065 00000003 8fd180cc DbgPrnHk+0x3525
b88bccb8 82a4828e 00000065 00000003 8fd180cc DbgPrnHk+0x358c
b88bccd8 8fd14725 8fd180cc b88bcd04 b88bcd28 nt!DbgPrint+0x1d
b88bccf8 82a834bc 864b0e00 8520a000 8ab0f0c0 DTSC4Own+0x1725
b88bcd10 88a2991c 8ab0f020 b88bcd34 82ab710e nt!IofCallDriver+0x63
b88bcd1c 82ab710e 8ab0f0c0 00000000 ffffffff
Ntfs!NtfsStorageDriverCallout+0x14
b88bcd1c 82ab7205 8ab0f0c0 00000000 ffffffff
nt!KiSwapKernelStackAndExit+0x15a
8ab0f030 00000000 00000000 00000000 00000000
nt!KiSwitchKernelStackAndCallout+0x31

STACK_COMMAND: kb

FOLLOWUP_IP:
DbgPrnHk+31bb
aa8b11bb f3a5 rep movs dword ptr es:[edi],dword ptr [esi]

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: DbgPrnHk+31bb

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: DbgPrnHk

IMAGE_NAME: DbgPrnHk.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d871ac0

FAILURE_BUCKET_ID: DISABLED_INTERRUPT_FAULT_DbgPrnHk+31bb

BUCKET_ID: DISABLED_INTERRUPT_FAULT_DbgPrnHk+31bb

Followup: MachineOwner

This free analysis is provided by OSR Open Systems Resources, Inc.
Want a deeper understanding of crash dump analysis? Check out our Windows
Kernel Debugging and Crash Dump Analysis Seminar (opens in new tab/window)

I want to see the contents of the write request.

Thanks,
Uzair Lakhani

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

47

Dear Joe,

Thanks for the input. Basically our driver is a function driver not a filter one. Basically I want to see the content of the incoming write request. I changed the code like below:

pWriteBuff=MmGetMdlVirtualAddress(Irp->MdlAddress);
if(pWriteBuff == NULL){
DbgPrint(“MmGetMdlVirtualAddress: NULL is returned\n”);
}
else{
ULONG i;
DbgPrint(“-----------------------------------------------------\n”);
DbgPrint(“MmGetMdlByteCount(Irp->MdlAddress): %lu \n”, MmGetMdlByteCount(Irp->MdlAddress));
for(i=0; iMdlAddress); i++){
DbgPrint(“%c “,pWriteBuff+i);
}

DbgPrint(”-----------------------------------------------------\n\n\n”);
}

But the contents get printed are the same like below:

! " # $ % & ’ ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z ^ _ ` a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

The above pattern is repeated again and again. I don’t think I am getting the correct content of write requests. Any pointers will be helpful.

Thanks,
Uzair Lakhani

48

Assuming pWriteBuff is of type PCHAR and is valid… you have to deref pWriteBuff and call DbgPrint("%c ", *(pWriteBuff+i));

49

Which works fine if the data is 8-bit characters. To print Unicode, it
would have to be running at PASSIVE_LEVEL to manage the wide-character
priting.

Note that writing
pWriteBuff[i]
is a bit more elegant, but in any case, it will print every other byte of
the array, because AFAIK, %c only prints the low-order 8 bits as a
character. You would use %wc to indicate a Unicode character.

I would have chosen to use a “memory dump” display of the form

xxxxxxxx: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX

and if I wanted to see the text, I might make a second pass and do
sonething like

|A.B.C.D^ E^F.G.H^ I.J.K^L^ M.N.O.P.|

I would make the effort to keep the address, xxxxxxxx, as a multiple of
16, so the first line might start indented a bit, and the last line might
be truncated. All this is trivial SMOP (small matter of programming) that
I would not consider out of place to assign to a freshman by about
mid-semester.

What I illustrated above is displaying “.” for a 0 byte, e.g. L’A’ would
be stored in memory as “41 00” and display in the text as “A.” but a
Unicode character beyond the base range might be stored in memory as “41
gg” where “gg” is the value that designates the Greek segment, and would
represent the value L’\xgg\x41’ and would appear in the text part of the
display as A^, which would allow me to see immediately that this ‘A’ was
not the Roman ‘A’ but the Greek “alpha”. Note that such a sbroutine could
run at any level for which DbgPrint is legal.

Oh, wait a minute! I actually already wrote this code! That’s why it was
so easy to explain!

We would all rather do this the “easy” way. Unfortunately, “easy” does
not always equate to “correct”, “sensible”, “useful” or whatever predicate
you wish to apply. “%s” or its many logical equivalents (like “%wZ”) is
hardly ever the right selection for printing buffer contents for debugging
purposes.
joe

Assuming pWriteBuff is of type PCHAR and is valid… you have to deref
pWriteBuff and call DbgPrint("%c ", *(pWriteBuff+i));

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

50

Dear Members,

Thanks for the input so far. Rephrasing my old question regarding the file system corruption problem, I want to present two scenarios in which in one case the file system check runs on reboot and in the other the file system check does not run. For our testing purposes we are only opening our virtual device X: and then restarting the system in both scenarios.

fileObj below is retrieved using ZwOpenFile & ObReferenceObjectByHandle routines.

// File System Check Not Runs on Reboot
// Think returns … Device Object
PDevExt->StorageDeviceObject = fileObj->DeviceObject;
targetDisk->StorageDeviceObject = fileObj->DeviceObject;

// File System Check Runs on Reboot
// Think returns File System Driver Device Object
PDevExt->StorageDeviceObject = IoGetRelatedDeviceObject(fileObj);
targetDisk->StorageDeviceObject = IoGetRelatedDeviceObject(fileObj);

What is the more suitable of the above two approaches?

According to tests both approaches will give file system check in some cases when data is written to the virtual device. We want to solve the problem of file system check in every case.

Do we need to unmount and then mount again the real disk partition for achieving our purpose and resolving file system check.

One more addition, we are only handling IOCTL_MOUNTDEV_QUERY_DEVICE_NAME ourselves and the rest of the IOCTLs are redirected to the real disk partition.

Any pointers regarding the above are welcome.

Thanks,
Uzair Lakhani

51

Dear Members,

After I copy some data to X: and restart the system then when the file system check is run on next reboot either by default or by myself doing chkdsk on my real disk partition then I get a large number of “replacing invalid security id with default security id for file …” messages.

Can somebody shed some light what can be the problem? I am just forwarding the incoming write IRP to my real disk partition without doing anything special for security id.

Thanks,
Uzair Lakhani

52

This is a clear indication that you are corrupting underlying file
system content on your target device. From your descriptions of what you
are attempting to do, the design and implementation are complex and
there are many things which could easily lead to this sort of
corruption. For instance, are you preventing ANY IO outside of what you
send to the target volume? Particularly IO from the file system mounted
on that volume? Without an thorough review of your design and
implementation, anyone on this list would be purely guessing at what
could be causing the problems you are seeing.

Pete

On 5/17/2013 4:02 AM, xxxxx@gmail.com wrote:

Dear Members,

After I copy some data to X: and restart the system then when the file system check is run on next reboot either by default or by myself doing chkdsk on my real disk partition then I get a large number of “replacing invalid security id with default security id for file …” messages.

Can somebody shed some light what can be the problem? I am just forwarding the incoming write IRP to my real disk partition without doing anything special for security id.

Thanks,
Uzair Lakhani

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

53

Dear Peter,

Thanks for your contribution. Our design is very simple we are only redirecting the incoming read/write requests to the disk partition in read/write dispatch routine like this.

NTSTATUS OwnCompletion(IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp,PVOID Context)
{
PIRP irp = (PIRP) Context;
PDEVICE_EXTENSION deviceExtension = superManager.PdevExt;

irp->IoStatus.Status = Irp->IoStatus.Status;
irp->IoStatus.Information = Irp->IoStatus.Information;
IoCompleteRequest(irp, IO_NO_INCREMENT);

IoReleaseRemoveLock(&deviceExtension->RemoveLock, (PVOID) 42);

IoFreeIrp(Irp);

return STATUS_MORE_PROCESSING_REQUIRED;
}

NTSTATUS
ReadWrite(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp
)
{
PIRP MyIrp;
PIO_STACK_LOCATION IrpStack, MyStack;
PDEVICE_EXTENSION deviceExtension = superManager.PdevExt;
NTSTATUS status;
TargetDisk * targetDisk = superManager.targetDisk;

status = IoAcquireRemoveLock(&deviceExtension->RemoveLock, (PVOID) 42);
if (!NT_SUCCESS(status)){
Irp->IoStatus.Information = 0;
Irp->IoStatus.Status = status;
IoCompleteRequest(Irp,IO_NO_INCREMENT);
return status;
}

if(deviceExtension->DeviceStatus == STATUS_DEVICE_NOT_READY){
Irp->IoStatus.Information = 0;
Irp->IoStatus.Status = STATUS_DEVICE_NOT_READY;
IoCompleteRequest(Irp,IO_NO_INCREMENT);
IoReleaseRemoveLock(&deviceExtension->RemoveLock, (PVOID) 42);
return STATUS_DEVICE_NOT_READY;
}

MyIrp = IoAllocateIrp(MAXIMUM_IRP_STACK_LOCATIONS, FALSE);

IrpStack = IoGetCurrentIrpStackLocation(Irp);
MyStack = IoGetNextIrpStackLocation(MyIrp);

MyStack->Parameters.Read.Length = IrpStack->Parameters.Read.Length;
MyStack->Parameters.Read.ByteOffset.QuadPart = IrpStack->Parameters.Read.ByteOffset.QuadPart;
MyStack->DeviceObject = targetDisk->StorageDeviceObject ;
MyStack->MajorFunction = IrpStack->MajorFunction;

IoSetCompletionRoutine(MyIrp,
OwnCompletion,
Irp,
TRUE,
TRUE,
TRUE);
MyIrp->MdlAddress = Irp->MdlAddress;
MyStack->FileObject = targetDisk->file_obj;
MyStack->Flags |= SL_FORCE_DIRECT_WRITE;

status = IoCallDriver(targetDisk->StorageDeviceObject, MyIrp);

return status;
}

This is a very short and simple piece of code. What problems can it create?

Do I need to show code of my DeviceControl routine and the routine that gets handle to the disk partition also?

Please note that I am not preventing any request from file system or other system.

Thanks,
Uzair Lakhani

54

My comment was more directed at what you are doing with the volume you
are directing your writes to. Is this a mounted volume and you are
writing directly to the underlying volume? If you are a just writing the
IOs from a fs filter perspective directly to the underlying target
volume, then what about all the metadata changes that the file system
itself would write out in order to support the writes you are doing? If
you compare IOs coming into a fs filter with those going to an
underlying volume you’ll find a large number of IOs not seen by the fs
filter that are generated by the file system itself to maintain
metadata, logs, etc.

While your implementation may be simple it is obviously not sufficient
since you are seeing corruption. That said, I would venture a guess that
there are a ton of IOs which are either missed or are not being
generated because you are not the file system.

Pete

On 5/17/2013 9:08 AM, xxxxx@gmail.com wrote:

Dear Peter,

Thanks for your contribution. Our design is very simple we are only redirecting the incoming read/write requests to the disk partition in read/write dispatch routine like this.

NTSTATUS OwnCompletion(IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp,PVOID Context)
{
PIRP irp = (PIRP) Context;
PDEVICE_EXTENSION deviceExtension = superManager.PdevExt;

irp->IoStatus.Status = Irp->IoStatus.Status;
irp->IoStatus.Information = Irp->IoStatus.Information;
IoCompleteRequest(irp, IO_NO_INCREMENT);

IoReleaseRemoveLock(&deviceExtension->RemoveLock, (PVOID) 42);

IoFreeIrp(Irp);

return STATUS_MORE_PROCESSING_REQUIRED;
}

NTSTATUS
ReadWrite(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp
)
{
PIRP MyIrp;
PIO_STACK_LOCATION IrpStack, MyStack;
PDEVICE_EXTENSION deviceExtension = superManager.PdevExt;
NTSTATUS status;
TargetDisk * targetDisk = superManager.targetDisk;

status = IoAcquireRemoveLock(&deviceExtension->RemoveLock, (PVOID) 42);
if (!NT_SUCCESS(status)){
Irp->IoStatus.Information = 0;
Irp->IoStatus.Status = status;
IoCompleteRequest(Irp,IO_NO_INCREMENT);
return status;
}

if(deviceExtension->DeviceStatus == STATUS_DEVICE_NOT_READY){
Irp->IoStatus.Information = 0;
Irp->IoStatus.Status = STATUS_DEVICE_NOT_READY;
IoCompleteRequest(Irp,IO_NO_INCREMENT);
IoReleaseRemoveLock(&deviceExtension->RemoveLock, (PVOID) 42);
return STATUS_DEVICE_NOT_READY;
}

MyIrp = IoAllocateIrp(MAXIMUM_IRP_STACK_LOCATIONS, FALSE);

IrpStack = IoGetCurrentIrpStackLocation(Irp);
MyStack = IoGetNextIrpStackLocation(MyIrp);

MyStack->Parameters.Read.Length = IrpStack->Parameters.Read.Length;
MyStack->Parameters.Read.ByteOffset.QuadPart = IrpStack->Parameters.Read.ByteOffset.QuadPart;
MyStack->DeviceObject = targetDisk->StorageDeviceObject ;
MyStack->MajorFunction = IrpStack->MajorFunction;

IoSetCompletionRoutine(MyIrp,
OwnCompletion,
Irp,
TRUE,
TRUE,
TRUE);
MyIrp->MdlAddress = Irp->MdlAddress;
MyStack->FileObject = targetDisk->file_obj;
MyStack->Flags |= SL_FORCE_DIRECT_WRITE;

status = IoCallDriver(targetDisk->StorageDeviceObject, MyIrp);

return status;
}

This is a very short and simple piece of code. What problems can it create?

Do I need to show code of my DeviceControl routine and the routine that gets handle to the disk partition also?

Please note that I am not preventing any request from file system or other system.

Thanks,
Uzair Lakhani

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

55

Dear Peter,

Thanks again for your input. Yes the disk partition to which we are writing is mounted and we are sending the requests to the device object of the partition but we still have a confusion of using which device object of the two we had mentioned in previous posts. Please note that we are a function driver and not a filter driver.

Do you mean that we have to write a file system driver like NTFS? But that will be too difficult.

One more question. If we make a filter driver than can it solve this problem.

Thanks,
Uzair Lakhani

56

Dear All,

What is the difference between writing an upper filter for Disk Drive Class and one for writing upper filter for Storage Volume Class.

Second question is whether the upper filter for Disk Drive Class can be used as an upper filter for Storage Volume Class if an upper filter for storage volume is required instead of Disk Drive Class?

Thanks,
Uzair Lakhani