Data-Type mismatch in Driver.

Hello Everybody
I’m writing a volume-level Upper Filter driver for Windows XP where I’m
using ‘IO_STACK_LOCATION’ structure and whose variable ByteOffset(irpStack->
Parameters.Read.ByteOffset) is of type LARGE_INTEGER and performing some
calculations with this variable like as follows:

StartingByteOffset.QuadPart = irpStack->
Parameters.Read.ByteOffset.QuadPart;
DbgPrint(“GFILTER ReadIrp ByteOffset=%ld \n”,(
StartingByteOffset.QuadPart));

BitPosition=(ULONG)(StartingByteOffset.QuadPart/CLUSTER_SIZE);
DbgPrint(“GFILTER CLUSTER_SIZE=%ld , ReadIrp BitPosition=%ld
\n”,CLUSTER_SIZE,BitPosition);

Where CLUSTER_SIZE is of type ULONG and after performing debug I came to
know that values are not coming proper as I’m typcasting a variable of type
LARGE_INTEGER to ULONG. But there are many functions like
‘RtlAreBitsClear()’, ‘RtlCheckBit()’ which take the parameters as ULONG only
so is there any method to pass arguments of LARGE_INTEGER type or some
changes that I can make while calculating BitPosition without changing its
type to LARGE_INTEGER.
Thanks in Advance.

Anuj Agarwal

You may want to replace %ld by %I64u or %I64d for all QuadPart’s.

is there any method to pass arguments of LARGE_INTEGER type or
some changes that I can make while calculating BitPosition without
changing its type to LARGE_INTEGER.
LARGE_INTEGER may be seen as DWORD LowPart, followed (on Intel)
by LONG HighPart.

DWORD is ULONG, on a 32 bit platform at least.

After

LARGE_INTEGER li;
li.HighPart = 1;
li.LowPart = 2;

li.QuadPart is 0x0000000100000002, but in (Intel’s) memory you have it as

02 00 00 00 01 00 00 00

The rest is manual labor.

----- Original Message -----
From: Anuj Agarwal
To: Windows System Software Devs Interest List
Sent: Tuesday, February 28, 2006 6:47 AM
Subject: [ntdev] Data-Type mismatch in Driver.

Hello Everybody
I’m writing a volume-level Upper Filter driver for Windows XP where I’m using ‘IO_STACK_LOCATION’ structure and whose variable ByteOffset(irpStack->Parameters.Read.ByteOffset) is of type LARGE_INTEGER and performing some calculations with this variable like as follows:

StartingByteOffset.QuadPart = irpStack->Parameters.Read.ByteOffset.QuadPart;
DbgPrint(“GFILTER ReadIrp ByteOffset=%ld \n”,(StartingByteOffset.QuadPart));

BitPosition=(ULONG)(StartingByteOffset.QuadPart/CLUSTER_SIZE);
DbgPrint(“GFILTER CLUSTER_SIZE=%ld , ReadIrp BitPosition=%ld \n”,CLUSTER_SIZE,BitPosition);

Where CLUSTER_SIZE is of type ULONG and after performing debug I came to know that values are not coming proper as I’m typcasting a variable of type LARGE_INTEGER to ULONG. But there are many functions like ‘RtlAreBitsClear()’, ‘RtlCheckBit()’ which take the parameters as ULONG only so is there any method to pass arguments of LARGE_INTEGER type or some changes that I can make while calculating BitPosition without changing its type to LARGE_INTEGER.
Thanks in Advance.

Anuj Agarwal
— Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Um. Maybe i’m doing my math wrong, but if you have a bitmap with more than ULONG_MAX worth of bits, that bitmap is going to take more than 4GB of virtual memory to hold.

So if you’re actually overflowing the BitPosition value then you’ve got some architectural problems. You’ll either need to build a two-level map of available clusters, or you’ll need a larger cluster size.

what is your cluster size? Even if it’s as small as 4K, you should still be able to represent a 1TB volume in only a 2GB bitmap. Still way too large to be feasible, but it wouldn’t require a ULONGLONG for the bit index.

-p


From: xxxxx@lists.osr.com on behalf of Anuj Agarwal
Sent: Tue 2/28/2006 3:47 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Data-Type mismatch in Driver.

Hello Everybody
I’m writing a volume-level Upper Filter driver for Windows XP where I’m using ‘IO_STACK_LOCATION’ structure and whose variable ByteOffset(irpStack->Parameters.Read.ByteOffset) is of type LARGE_INTEGER and performing some calculations with this variable like as follows:

StartingByteOffset.QuadPart = irpStack->Parameters.Read.ByteOffset.QuadPart;
DbgPrint(“GFILTER ReadIrp ByteOffset=%ld \n”,(StartingByteOffset.QuadPart));

BitPosition=(ULONG)(StartingByteOffset.QuadPart/CLUSTER_SIZE);
DbgPrint(“GFILTER CLUSTER_SIZE=%ld , ReadIrp BitPosition=%ld \n”,CLUSTER_SIZE,BitPosition);

Where CLUSTER_SIZE is of type ULONG and after performing debug I came to know that values are not coming proper as I’m typcasting a variable of type LARGE_INTEGER to ULONG. But there are many functions like ‘RtlAreBitsClear()’, ‘RtlCheckBit()’ which take the parameters as ULONG only so is there any method to pass arguments of LARGE_INTEGER type or some changes that I can make while calculating BitPosition without changing its type to LARGE_INTEGER.
Thanks in Advance.

Anuj Agarwal
— Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Thanks Alex I got the problem, it was only the printing mistake and I need
to use %l64d while printing as you told.

Anuj Agarwal

On 2/28/06, xxxxx@Home wrote:
>
> You may want to replace %ld by %I64u or %I64d for all QuadPart’s.
>
> > is there any method to pass arguments of LARGE_INTEGER type or
> > some changes that I can make while calculating BitPosition without
> > changing its type to LARGE_INTEGER.
> LARGE_INTEGER may be seen as DWORD LowPart, followed (on Intel)
> by LONG HighPart.
>
> DWORD is ULONG, on a 32 bit platform at least.
> After
>
> LARGE_INTEGER li;
> li.HighPart = 1;
> li.LowPart = 2;
>
> li.QuadPart is 0x0000000100000002, but in (Intel’s) memory you have it as
>
> 02 00 00 00 01 00 00 00
>
> The rest is manual labor.
>
>
>
> ----- Original Message -----
> From: Anuj Agarwal
> To: Windows System Software Devs Interest List
> Sent: Tuesday, February 28, 2006 6:47 AM
> Subject: [ntdev] Data-Type mismatch in Driver.
>
> Hello Everybody
> I’m writing a volume-level Upper Filter driver for Windows XP where I’m
> using ‘IO_STACK_LOCATION’ structure and whose variable ByteOffset
> (irpStack->Parameters.Read.ByteOffset) is of type LARGE_INTEGER and
> performing some calculations with this variable like as follows:
>
> StartingByteOffset.QuadPart = irpStack->
> Parameters.Read.ByteOffset.QuadPart;
> DbgPrint(“GFILTER ReadIrp ByteOffset=%ld \n”,(
> StartingByteOffset.QuadPart));
>
> BitPosition=(ULONG)(StartingByteOffset.QuadPart/CLUSTER_SIZE);
> DbgPrint(“GFILTER CLUSTER_SIZE=%ld , ReadIrp BitPosition=%ld
> \n”,CLUSTER_SIZE,BitPosition);
>
> Where CLUSTER_SIZE is of type ULONG and after performing debug I came to
> know that values are not coming proper as I’m typcasting a variable of type
> LARGE_INTEGER to ULONG. But there are many functions like
> ‘RtlAreBitsClear()’, ‘RtlCheckBit()’ which take the parameters as ULONG only
> so is there any method to pass arguments of LARGE_INTEGER type or some
> changes that I can make while calculating BitPosition without changing its
> type to LARGE_INTEGER.
> Thanks in Advance.
>
> Anuj Agarwal
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer