A strange bug check reported by driver verifier.

NTDEV
1

Hi, all
I have met a strange problem of accessing the memory. The problem is I
allocate 0x60 bytes from non-paged pool and when I access the memory at 0x30
offset, the system bug checked. I have enabled the driver verifier on my
driver. Thanks for any help in advance. The following is the message from
windbg:
============================== analyze of windbg begin

kd> !analyze -v
ERROR: FindPlugIns 8007007b
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6)
N bytes of memory was allocated and more than N bytes are being referenced.
This cannot be protected by try-except.
When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: 82117000, memory referenced
Arg2: 00000001, value 0 = read operation, 1 = write operation
Arg3: f0f24623, if non-zero, the address which referenced memory.
Arg4: 00000000, (reserved)

Debugging Details:

WRITE_ADDRESS: 82117000 Special pool

FAULTING_IP:
XXXXXX!xdrmem_getlong+33
f0f24623 8901 mov dword ptr [ecx],eax

MM_INTERNAL_CODE: 0

IMAGE_NAME: XXXXXX.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 4d7048c7

MODULE_NAME: XXXXXX

FAULTING_MODULE: f0eac000 XXXXXX

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD6

PROCESS_NAME: System

TRAP_FRAME: f9c62150 -- (.trap 0xfffffffff9c62150)
ErrCode = 00000002
eax=00000002 ebx=8191fc00 ecx=82117000 edx=00000000 esi=00026dd4
edi=816ca020
eip=f0f24623 esp=f9c621c4 ebp=f9c621c4 iopl=0 nv up ei ng nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
XXXXXX!xdrmem_getlong+0x33:
f0f24623 8901 mov dword ptr [ecx],eax
ds:0023:82117000=????????
Resetting default scope

LAST_CONTROL_TRANSFER: from 804f8b9d to 80528bdc

STACK_TEXT:
f9c61c8c 804f8b9d 00000003 82117000 00000000
nt!RtlpBreakWithStatusInstruction
f9c61cd8 804f978a 00000003 00000000 c04108b8 nt!KiBugCheckDebugBreak+0x19
f9c620b8 804f9cb5 00000050 82117000 00000001 nt!KeBugCheck2+0x574
f9c620d8 8051dc4f 00000050 82117000 00000001 nt!KeBugCheckEx+0x1b
f9c62138 8054151c 00000001 82117000 00000000 nt!MmAccessFault+0x8e7
f9c62138 f0f24623 00000001 82117000 00000000 nt!KiTrap0E+0xcc
f9c621c4 f0f22e3d f9c622f4 82117000 f9c621e8 XXXXXX!xdrmem_getlong+0x33
f9c621d4 f0f07681 f9c622f4 82117000 f9c622f4 XXXXXX!xdr_u_long+0x1d
f9c621e8 f0f0d481 f9c622f4 82117000 f9c622f4 XXXXXX!xdr_uint32+0x11
f9c621fc f0f238e9 f9c622f4 82117000 ffffffff XXXXXX!xdr_bw_bl_extent+0x11
f9c62228 f0f0d869 f9c622f4 f0f5a1b8 f0f5a1b4 XXXXXX!xdr_array+0xf9
f9c6224c f0f0d9a7 f9c622f4 f0f5a114 00000000 XXXXXX!xdr_logres_ok+0x139
f9c62264 f0f24211 f9c622f4 f0f5a110 00000000 XXXXXX!xdr_logres+0x47
f9c62278 f0f23346 f9c622f4 f9c6232c ffffffff XXXXXX!xdr_accepted_reply+0x61
f9c62294 f0f24325 f9c622f4 f9c62328 f9c6232c XXXXXX!xdr_union+0x56
f9c622b0 f0f22a6f f9c622f4 f9c62320 00000001 XXXXXX!xdr_replymsg+0x55
f9c6235c f0f0acad 81e0aff0 00000014 f0f0d5e0 XXXXXX!clntudp_call+0x4ff
f9c62398 f0f13384 f9c62460 81e0aff0 816ca0d8 XXXXXX!xxxx_layoutget_1+0x8d
f9c62500 f0f160f5 81e4ef58 00000004 00000000
XXXXXX!Xxxx_LayoutGetWrite+0x2d4
f9c62574 f0f16418 81e4ef58 00000004 00000000 XXXXXX!XxxxProt_BlockMap+0x295
f9c62614 f0ed94e6 81e4ef58 00004000 00000000 XXXXXX!XxxxProtGetBlock+0x178
f9c627c8 f0edc644 81e4ef58 00004000 00000000 XXXXXX!RwWriteFile+0x3f6
f9c62920 f0eddd4c 81f52f48 8162f934 816ca020 XXXXXX!FsdWritePaged+0x574
f9c62a10 f0eba3cc 81f52f48 8162f934 816ca020 XXXXXX!FsdWrite+0x5dc
f9c62b1c f0ebb489 81f52f48 8162f918 816ca020 XXXXXX!FsdDispatchWrite+0x8fc
f9c62cd4 f0ebd2b8 81f52f48 8162f918 816ca020 XXXXXX!FsdDispatchRequest+0x109
f9c62d20 804ef119 816ca020 81f52f48 806d32e8 XXXXXX!FsdBuildRequest+0x168
f9c62d30 8064e628 8146af90 00004000 8191fcf8 nt!IopfCallDriver+0x31
f9c62d54 804f10f9 8191fcf8 806d32d0 8191fce8 nt!IovCallDriver+0xa0
f9c62d68 8050c9ea 8146af02 816ca020 8191fcf0 nt!IoAsynchronousPageWrite+0xc3
f9c62dac 805c7160 00000000 00000000 00000000 nt!MiMappedPageWriter+0xc2
f9c62ddc 80542dd2 8050c928 00000000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
XXXXXX!xdrmem_getlong+33
f0f24623 8901 mov dword ptr [ecx],eax

SYMBOL_STACK_INDEX: 6

SYMBOL_NAME: XXXXXX!xdrmem_getlong+33

FOLLOWUP_NAME: MachineOwner

FAILURE_BUCKET_ID: 0xD6_VRF_XXXXXX!xdrmem_getlong+33

BUCKET_ID: 0xD6_VRF_XXXXXX!xdrmem_getlong+33

Followup: MachineOwner

=============================== analyze of windbg end

The following is information of !pool:
============================== information of !pool begin

kd> !pool 0x82117000
Pool page 82117000 region is Special pool
82117000: Unable to get contents of special pool block
============================== information of !pool end

The following is information of !poolval:
============================ information of !poolval begin

kd> !poolval 0x82117000 3
Pool page 82117000 region is Special pool

Validating Pool headers for pool page: 82117000

Pool page [82117000] is __inVALID.

Displaying all POOL_HEADER meta info...
[82117000]: FIRST_LINK | LAST_LINK | START_PAGE_BLOCK
[82117000]: back link [82117000]

Displaying linked lists...
[82117000]: FIRST_LINK | LAST_LINK | START_PAGE_BLOCK
[82117000]: back link [82117000]
[82117000]: 01

Analyzing longest linked list...
[headerinfo = 0x71 @ 82117000]: 01

Scanning for single bit errors...

None found
============================ information of !poolval end

Ted Chang

2

>

Hi, all
I have met a strange problem of accessing the memory. The problem is I
allocate 0x60 bytes from non-paged pool and when I access the memory
at 0x30
offset, the system bug checked. I have enabled the driver verifier on
my
driver. Thanks for any help in advance. The following is the message
from
windbg:

Can you post the offending code? Is the name of your driver really
XXXXXX or did you redact it because it’s so secret that even mentioning
the driver name would be giving away too much :slight_smile:

James

3

Thanks, James
The following is the code segment, it’s very old:

00:bool_t
01:xdr_array(xdrs, addrp, sizep, maxsize, elsize, elproc)
02: register XDR *xdrs;
03: caddr_t *addrp; /* array pointer */
04: u_int *sizep; /* number of elements */
05: u_int maxsize; /* max numberof elements */
06: u_int elsize; /* size in bytes of each element */
07: xdrproc_t elproc; /* xdr routine to handle each element */
08:{
09: register u_int i;
10: register caddr_t target = *addrp;
11: register u_int c; /* the actual element count */
12: register bool_t stat = TRUE;
13: register u_int nodesize;
14:
15: /* like strings, arrays are really counted arrays */
16: if (! xdr_u_int(xdrs, sizep)) {
17: return (FALSE);
18: }
19: c = *sizep;
20: if ((c > maxsize) && (xdrs->x_op != XDR_FREE)) {
21: return (FALSE);
22: }
23: nodesize = c * elsize;
24:
25: /*
26: * if we are deserializing, we may need to allocate an array.
27: * We also save time by checking for a null array if we are freeing.
28: */
29: if (target == NULL)
30: switch (xdrs->x_op) {
31: case XDR_DECODE:
32: if (c == 0)
33: return (TRUE);
34: *addrp = target = mem_alloc(nodesize);
35: if (target == NULL) {
36: return (FALSE);
37: }
38: bzero(target, nodesize);
39: break;
40:
41: case XDR_FREE:
42: return (TRUE);
43: }
44:
45: /*
46: * now we xdr each element of array
47: */
48: for (i = 0; (i < c) && stat; i++) {
49: stat = (*elproc)(xdrs, target, LASTUNSIGNED);
50: target += elsize;
51: }
52:
53: /*
54: * the array may need freeing
55: */
56: if (xdrs->x_op == XDR_FREE) {
57: mem_free(*addrp, nodesize);
58: *addrp = NULL;
59: }
60: return (stat);
61:}

The local variable c is 2, the parameter elsize is 0x30, the, the problem
occurred at line 49, when i is 1, the target point to an address which value
is 0x821170000. And the memory pointed by target cannot be accessed.
mem_alloc is a marco which directory call ExAllocatePoolWithTag allocate
memory from non-paged pool. bzero is a wrapper of memset which zeroed the
allocated memory.

Ted Chang

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Friday, March 04, 2011 4:45 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] A strange bug check reported by driver verifier.

Hi, all
I have met a strange problem of accessing the memory. The problem is I
allocate 0x60 bytes from non-paged pool and when I access the memory
at 0x30
offset, the system bug checked. I have enabled the driver verifier on
my
driver. Thanks for any help in advance. The following is the message
from
windbg:

Can you post the offending code? Is the name of your driver really
XXXXXX or did you redact it because it’s so secret that even mentioning
the driver name would be giving away too much :slight_smile:

James

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other 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

4

Wouldn’t you just want to increment target, not increment it by elsize
(which I assume stands for ‘element size’)?

That is:

target++

v.

50: target += elsize;

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Chang
Sent: Friday, March 04, 2011 4:11 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] A strange bug check reported by driver verifier.

Thanks, James
The following is the code segment, it’s very old:

00:bool_t
01:xdr_array(xdrs, addrp, sizep, maxsize, elsize, elproc)
02: register XDR *xdrs;
03: caddr_t *addrp; /* array pointer */
04: u_int *sizep; /* number of elements */
05: u_int maxsize; /* max numberof elements */
06: u_int elsize; /* size in bytes of each element */
07: xdrproc_t elproc; /* xdr routine to handle each element */
08:{
09: register u_int i;
10: register caddr_t target = *addrp;
11: register u_int c; /* the actual element count */
12: register bool_t stat = TRUE;
13: register u_int nodesize;
14:
15: /* like strings, arrays are really counted arrays */
16: if (! xdr_u_int(xdrs, sizep)) {
17: return (FALSE);
18: }
19: c = *sizep;
20: if ((c > maxsize) && (xdrs->x_op != XDR_FREE)) {
21: return (FALSE);
22: }
23: nodesize = c * elsize;
24:
25: /*
26: * if we are deserializing, we may need to allocate an array.
27: * We also save time by checking for a null array if we are freeing.
28: */
29: if (target == NULL)
30: switch (xdrs->x_op) {
31: case XDR_DECODE:
32: if (c == 0)
33: return (TRUE);
34: *addrp = target = mem_alloc(nodesize);
35: if (target == NULL) {
36: return (FALSE);
37: }
38: bzero(target, nodesize);
39: break;
40:
41: case XDR_FREE:
42: return (TRUE);
43: }
44:
45: /*
46: * now we xdr each element of array
47: */
48: for (i = 0; (i < c) && stat; i++) {
49: stat = (*elproc)(xdrs, target, LASTUNSIGNED);
50: target += elsize;
51: }
52:
53: /*
54: * the array may need freeing
55: */
56: if (xdrs->x_op == XDR_FREE) {
57: mem_free(*addrp, nodesize);
58: *addrp = NULL;
59: }
60: return (stat);
61:}

The local variable c is 2, the parameter elsize is 0x30, the, the problem
occurred at line 49, when i is 1, the target point to an address which value
is 0x821170000. And the memory pointed by target cannot be accessed.
mem_alloc is a marco which directory call ExAllocatePoolWithTag allocate
memory from non-paged pool. bzero is a wrapper of memset which zeroed the
allocated memory.

Ted Chang

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Friday, March 04, 2011 4:45 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] A strange bug check reported by driver verifier.

Hi, all
I have met a strange problem of accessing the memory. The problem is I
allocate 0x60 bytes from non-paged pool and when I access the memory
at 0x30
offset, the system bug checked. I have enabled the driver verifier on
my
driver. Thanks for any help in advance. The following is the message
from
windbg:

Can you post the offending code? Is the name of your driver really
XXXXXX or did you redact it because it’s so secret that even mentioning
the driver name would be giving away too much :slight_smile:

James

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other 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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other 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

5

Thanks,
target was a pointer to the buffer which used to save an array of some
structure. The elsize was the size of that kind of structure which is 0x30.
When I use the elproc function decoded the current element in the xdrs, I
need to decode the next one. BTW, the xdrs->x_op was XDR_DECODE.

Ted Chang

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Friday, March 04, 2011 5:23 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] A strange bug check reported by driver verifier.

Wouldn’t you just want to increment target, not increment it by elsize
(which I assume stands for ‘element size’)?

That is:

target++

v.

50: target += elsize;

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Chang
Sent: Friday, March 04, 2011 4:11 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] A strange bug check reported by driver verifier.

Thanks, James
The following is the code segment, it’s very old:

00:bool_t
01:xdr_array(xdrs, addrp, sizep, maxsize, elsize, elproc)
02: register XDR *xdrs;
03: caddr_t *addrp; /* array pointer */
04: u_int *sizep; /* number of elements */
05: u_int maxsize; /* max numberof elements */
06: u_int elsize; /* size in bytes of each element */
07: xdrproc_t elproc; /* xdr routine to handle each element */
08:{
09: register u_int i;
10: register caddr_t target = *addrp;
11: register u_int c; /* the actual element count */
12: register bool_t stat = TRUE;
13: register u_int nodesize;
14:
15: /* like strings, arrays are really counted arrays */
16: if (! xdr_u_int(xdrs, sizep)) {
17: return (FALSE);
18: }
19: c = *sizep;
20: if ((c > maxsize) && (xdrs->x_op != XDR_FREE)) {
21: return (FALSE);
22: }
23: nodesize = c * elsize;
24:
25: /*
26: * if we are deserializing, we may need to allocate an array.
27: * We also save time by checking for a null array if we are freeing.
28: */
29: if (target == NULL)
30: switch (xdrs->x_op) {
31: case XDR_DECODE:
32: if (c == 0)
33: return (TRUE);
34: *addrp = target = mem_alloc(nodesize);
35: if (target == NULL) {
36: return (FALSE);
37: }
38: bzero(target, nodesize);
39: break;
40:
41: case XDR_FREE:
42: return (TRUE);
43: }
44:
45: /*
46: * now we xdr each element of array
47: */
48: for (i = 0; (i < c) && stat; i++) {
49: stat = (*elproc)(xdrs, target, LASTUNSIGNED);
50: target += elsize;
51: }
52:
53: /*
54: * the array may need freeing
55: */
56: if (xdrs->x_op == XDR_FREE) {
57: mem_free(*addrp, nodesize);
58: *addrp = NULL;
59: }
60: return (stat);
61:}

The local variable c is 2, the parameter elsize is 0x30, the, the problem
occurred at line 49, when i is 1, the target point to an address which value
is 0x821170000. And the memory pointed by target cannot be accessed.
mem_alloc is a marco which directory call ExAllocatePoolWithTag allocate
memory from non-paged pool. bzero is a wrapper of memset which zeroed the
allocated memory.

Ted Chang

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Friday, March 04, 2011 4:45 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] A strange bug check reported by driver verifier.

Hi, all
I have met a strange problem of accessing the memory. The problem is I
allocate 0x60 bytes from non-paged pool and when I access the memory
at 0x30
offset, the system bug checked. I have enabled the driver verifier on
my
driver. Thanks for any help in advance. The following is the message
from
windbg:

Can you post the offending code? Is the name of your driver really
XXXXXX or did you redact it because it’s so secret that even mentioning
the driver name would be giving away too much :slight_smile:

James

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other 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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other 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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other 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

6

target += elsize will advance target by elsize * sizeof(*target) bytes. If target is a short then that is 2 * elsize bytes. Is that what you intended?

Sent from my iPhone

On 04/03/2011, at 20:32, “Ted Chang” wrote:

> Thanks,
> target was a pointer to the buffer which used to save an array of some
> structure. The elsize was the size of that kind of structure which is 0x30.
> When I use the elproc function decoded the current element in the xdrs, I
> need to decode the next one. BTW, the xdrs->x_op was XDR_DECODE.
>
> Ted Chang
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
> Sent: Friday, March 04, 2011 5:23 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] A strange bug check reported by driver verifier.
>
> Wouldn’t you just want to increment target, not increment it by elsize
> (which I assume stands for ‘element size’)?
>
> That is:
>
> target++
>
> v.
>
> 50: target += elsize;
>
>
> mm
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ted Chang
> Sent: Friday, March 04, 2011 4:11 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] A strange bug check reported by driver verifier.
>
> Thanks, James
> The following is the code segment, it’s very old:
>
> 00:bool_t
> 01:xdr_array(xdrs, addrp, sizep, maxsize, elsize, elproc)
> 02: register XDR *xdrs;
> 03: caddr_t addrp; / array pointer */
> 04: u_int sizep; / number of elements /
> 05: u_int maxsize; / max numberof elements /
> 06: u_int elsize; / size in bytes of each element /
> 07: xdrproc_t elproc; / xdr routine to handle each element */
> 08:{
> 09: register u_int i;
> 10: register caddr_t target = addrp;
> 11: register u_int c; / the actual element count /
> 12: register bool_t stat = TRUE;
> 13: register u_int nodesize;
> 14:
> 15: / like strings, arrays are really counted arrays */
> 16: if (! xdr_u_int(xdrs, sizep)) {
> 17: return (FALSE);
> 18: }
> 19: c = sizep;
> 20: if ((c > maxsize) && (xdrs->x_op != XDR_FREE)) {
> 21: return (FALSE);
> 22: }
> 23: nodesize = c * elsize;
> 24:
> 25: /
> 26: * if we are deserializing, we may need to allocate an array.
> 27: * We also save time by checking for a null array if we are freeing.
> 28: */
> 29: if (target == NULL)
> 30: switch (xdrs->x_op) {
> 31: case XDR_DECODE:
> 32: if (c == 0)
> 33: return (TRUE);
> 34: addrp = target = mem_alloc(nodesize);
> 35: if (target == NULL) {
> 36: return (FALSE);
> 37: }
> 38: bzero(target, nodesize);
> 39: break;
> 40:
> 41: case XDR_FREE:
> 42: return (TRUE);
> 43: }
> 44:
> 45: /
> 46: * now we xdr each element of array
> 47: */
> 48: for (i = 0; (i < c) && stat; i++) {
> 49: stat = (elproc)(xdrs, target, LASTUNSIGNED);
> 50: target += elsize;
> 51: }
> 52:
> 53: /
> 54: * the array may need freeing
> 55: */
> 56: if (xdrs->x_op == XDR_FREE) {
> 57: mem_free(*addrp, nodesize);
> 58: *addrp = NULL;
> 59: }
> 60: return (stat);
> 61:}
>
> The local variable c is 2, the parameter elsize is 0x30, the, the problem
> occurred at line 49, when i is 1, the target point to an address which value
> is 0x821170000. And the memory pointed by target cannot be accessed.
> mem_alloc is a marco which directory call ExAllocatePoolWithTag allocate
> memory from non-paged pool. bzero is a wrapper of memset which zeroed the
> allocated memory.
>
>
> Ted Chang
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
> Sent: Friday, March 04, 2011 4:45 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] A strange bug check reported by driver verifier.
>
>>
>> Hi, all
>> I have met a strange problem of accessing the memory. The problem is I
>> allocate 0x60 bytes from non-paged pool and when I access the memory
> at 0x30
>> offset, the system bug checked. I have enabled the driver verifier on
> my
>> driver. Thanks for any help in advance. The following is the message
> from
>> windbg:
>
>
> Can you post the offending code? Is the name of your driver really
> XXXXXX or did you redact it because it’s so secret that even mentioning
> the driver name would be giving away too much :slight_smile:
>
> James
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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

7

Sorry, I forget to mention that caddr_t is char *
typedef char *caddr_t;
#define bool_t int

Ted Chang

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Friday, March 04, 2011 5:59 PM
To: Windows System Software Devs Interest List
Cc: Windows System Software Devs Interest List
Subject: Re: [ntdev] A strange bug check reported by driver verifier.

target += elsize will advance target by elsize * sizeof(*target) bytes. If
target is a short then that is 2 * elsize bytes. Is that what you intended?

Sent from my iPhone

On 04/03/2011, at 20:32, “Ted Chang” wrote:

> Thanks,
> target was a pointer to the buffer which used to save an array of some
> structure. The elsize was the size of that kind of structure which is
0x30.
> When I use the elproc function decoded the current element in the xdrs, I
> need to decode the next one. BTW, the xdrs->x_op was XDR_DECODE.
>
> Ted Chang
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
> Sent: Friday, March 04, 2011 5:23 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] A strange bug check reported by driver verifier.
>
> Wouldn’t you just want to increment target, not increment it by elsize
> (which I assume stands for ‘element size’)?
>
> That is:
>
> target++
>
> v.
>
> 50: target += elsize;
>
>
> mm
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ted Chang
> Sent: Friday, March 04, 2011 4:11 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] A strange bug check reported by driver verifier.
>
> Thanks, James
> The following is the code segment, it’s very old:
>
> 00:bool_t
> 01:xdr_array(xdrs, addrp, sizep, maxsize, elsize, elproc)
> 02: register XDR *xdrs;
> 03: caddr_t addrp; / array pointer */
> 04: u_int sizep; / number of elements /
> 05: u_int maxsize; / max numberof elements /
> 06: u_int elsize; / size in bytes of each element /
> 07: xdrproc_t elproc; / xdr routine to handle each element */
> 08:{
> 09: register u_int i;
> 10: register caddr_t target = addrp;
> 11: register u_int c; / the actual element count /
> 12: register bool_t stat = TRUE;
> 13: register u_int nodesize;
> 14:
> 15: / like strings, arrays are really counted arrays */
> 16: if (! xdr_u_int(xdrs, sizep)) {
> 17: return (FALSE);
> 18: }
> 19: c = sizep;
> 20: if ((c > maxsize) && (xdrs->x_op != XDR_FREE)) {
> 21: return (FALSE);
> 22: }
> 23: nodesize = c * elsize;
> 24:
> 25: /
> 26: * if we are deserializing, we may need to allocate an array.
> 27: * We also save time by checking for a null array if we are
freeing.
> 28: */
> 29: if (target == NULL)
> 30: switch (xdrs->x_op) {
> 31: case XDR_DECODE:
> 32: if (c == 0)
> 33: return (TRUE);
> 34: addrp = target = mem_alloc(nodesize);
> 35: if (target == NULL) {
> 36: return (FALSE);
> 37: }
> 38: bzero(target, nodesize);
> 39: break;
> 40:
> 41: case XDR_FREE:
> 42: return (TRUE);
> 43: }
> 44:
> 45: /
> 46: * now we xdr each element of array
> 47: */
> 48: for (i = 0; (i < c) && stat; i++) {
> 49: stat = (elproc)(xdrs, target, LASTUNSIGNED);
> 50: target += elsize;
> 51: }
> 52:
> 53: /
> 54: * the array may need freeing
> 55: */
> 56: if (xdrs->x_op == XDR_FREE) {
> 57: mem_free(*addrp, nodesize);
> 58: *addrp = NULL;
> 59: }
> 60: return (stat);
> 61:}
>
> The local variable c is 2, the parameter elsize is 0x30, the, the problem
> occurred at line 49, when i is 1, the target point to an address which
value
> is 0x821170000. And the memory pointed by target cannot be accessed.
> mem_alloc is a marco which directory call ExAllocatePoolWithTag allocate
> memory from non-paged pool. bzero is a wrapper of memset which zeroed the
> allocated memory.
>
>
> Ted Chang
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
> Sent: Friday, March 04, 2011 4:45 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] A strange bug check reported by driver verifier.
>
>>
>> Hi, all
>> I have met a strange problem of accessing the memory. The problem is I
>> allocate 0x60 bytes from non-paged pool and when I access the memory
> at 0x30
>> offset, the system bug checked. I have enabled the driver verifier on
> my
>> driver. Thanks for any help in advance. The following is the message
> from
>> windbg:
>
>
> Can you post the offending code? Is the name of your driver really
> XXXXXX or did you redact it because it’s so secret that even mentioning
> the driver name would be giving away too much :slight_smile:
>
> James
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other 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

8

>

Sorry, I forget to mention that caddr_t is char *
typedef char *caddr_t;
#define bool_t int

When the function is entered, is *addrp definitely NULL, or does target
definitely contain a buffer of the right size? The code seems to take
the “only allocate if necessary” approach so if an incorrect sized
buffer was allocated previously this might explain it.

Have you put a breakpoint at the start and stepped through it with the
debugger?

Can you confirm that the function *elproc isn’t overstepping the memory
buffer too?

James

Ted Chang

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Friday, March 04, 2011 5:59 PM
To: Windows System Software Devs Interest List
Cc: Windows System Software Devs Interest List
Subject: Re: [ntdev] A strange bug check reported by driver verifier.

target += elsize will advance target by elsize * sizeof(*target)
bytes. If
target is a short then that is 2 * elsize bytes. Is that what you
intended?

Sent from my iPhone

On 04/03/2011, at 20:32, “Ted Chang” wrote:
>
> > Thanks,
> > target was a pointer to the buffer which used to save an array of
some
> > structure. The elsize was the size of that kind of structure which
is
> 0x30.
> > When I use the elproc function decoded the current element in the
xdrs, I
> > need to decode the next one. BTW, the xdrs->x_op was XDR_DECODE.
> >
> > Ted Chang
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Martin
O’Brien
> > Sent: Friday, March 04, 2011 5:23 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] A strange bug check reported by driver
verifier.
> >
> > Wouldn’t you just want to increment target, not increment it by
elsize
> > (which I assume stands for ‘element size’)?
> >
> > That is:
> >
> > target++
> >
> > v.
> >
> > 50: target += elsize;
> >
> >
> > mm
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Ted Chang
> > Sent: Friday, March 04, 2011 4:11 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] A strange bug check reported by driver
verifier.
> >
> > Thanks, James
> > The following is the code segment, it’s very old:
> >
> > 00:bool_t
> > 01:xdr_array(xdrs, addrp, sizep, maxsize, elsize, elproc)
> > 02: register XDR *xdrs;
> > 03: caddr_t addrp; / array pointer */
> > 04: u_int sizep; / number of elements /
> > 05: u_int maxsize; / max numberof elements /
> > 06: u_int elsize; / size in bytes of each element /
> > 07: xdrproc_t elproc; / xdr routine to handle each element */
> > 08:{
> > 09: register u_int i;
> > 10: register caddr_t target = addrp;
> > 11: register u_int c; / the actual element count /
> > 12: register bool_t stat = TRUE;
> > 13: register u_int nodesize;
> > 14:
> > 15: / like strings, arrays are really counted arrays */
> > 16: if (! xdr_u_int(xdrs, sizep)) {
> > 17: return (FALSE);
> > 18: }
> > 19: c = sizep;
> > 20: if ((c > maxsize) && (xdrs->x_op != XDR_FREE)) {
> > 21: return (FALSE);
> > 22: }
> > 23: nodesize = c * elsize;
> > 24:
> > 25: /
> > 26: * if we are deserializing, we may need to allocate an array.
> > 27: * We also save time by checking for a null array if we are
> freeing.
> > 28: */
> > 29: if (target == NULL)
> > 30: switch (xdrs->x_op) {
> > 31: case XDR_DECODE:
> > 32: if (c == 0)
> > 33: return (TRUE);
> > 34: addrp = target = mem_alloc(nodesize);
> > 35: if (target == NULL) {
> > 36: return (FALSE);
> > 37: }
> > 38: bzero(target, nodesize);
> > 39: break;
> > 40:
> > 41: case XDR_FREE:
> > 42: return (TRUE);
> > 43: }
> > 44:
> > 45: /
> > 46: * now we xdr each element of array
> > 47: */
> > 48: for (i = 0; (i < c) && stat; i++) {
> > 49: stat = (elproc)(xdrs, target, LASTUNSIGNED);
> > 50: target += elsize;
> > 51: }
> > 52:
> > 53: /
> > 54: * the array may need freeing
> > 55: */
> > 56: if (xdrs->x_op == XDR_FREE) {
> > 57: mem_free(*addrp, nodesize);
> > 58: *addrp = NULL;
> > 59: }
> > 60: return (stat);
> > 61:}
> >
> > The local variable c is 2, the parameter elsize is 0x30, the, the
problem
> > occurred at line 49, when i is 1, the target point to an address
which
> value
> > is 0x821170000. And the memory pointed by target cannot be accessed.
> > mem_alloc is a marco which directory call ExAllocatePoolWithTag
allocate
> > memory from non-paged pool. bzero is a wrapper of memset which
zeroed the
> > allocated memory.
> >
> >
> > Ted Chang
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
> > Sent: Friday, March 04, 2011 4:45 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] A strange bug check reported by driver
verifier.
> >
> >>
> >> Hi, all
> >> I have met a strange problem of accessing the memory. The problem
is I
> >> allocate 0x60 bytes from non-paged pool and when I access the
memory
> > at 0x30
> >> offset, the system bug checked. I have enabled the driver verifier
on
> > my
> >> driver. Thanks for any help in advance. The following is the
message
> > from
> >> windbg:
> >
> >
> > Can you post the offending code? Is the name of your driver really
> > XXXXXX or did you redact it because it’s so secret that even
mentioning
> > the driver name would be giving away too much :slight_smile:
> >
> > James
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other 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
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other 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
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other 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
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other 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
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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

9

Thank you very much, James. I always think addrp should be NULL and the
memory was allocated by this function. But this may be wrong. I will add
some log to the function and take more tests.

Ted Chang

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Friday, March 04, 2011 7:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] A strange bug check reported by driver verifier.

Sorry, I forget to mention that caddr_t is char *
typedef char *caddr_t;
#define bool_t int

When the function is entered, is *addrp definitely NULL, or does target
definitely contain a buffer of the right size? The code seems to take
the “only allocate if necessary” approach so if an incorrect sized
buffer was allocated previously this might explain it.

Have you put a breakpoint at the start and stepped through it with the
debugger?

Can you confirm that the function *elproc isn’t overstepping the memory
buffer too?

James

Ted Chang

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Friday, March 04, 2011 5:59 PM
To: Windows System Software Devs Interest List
Cc: Windows System Software Devs Interest List
Subject: Re: [ntdev] A strange bug check reported by driver verifier.

target += elsize will advance target by elsize * sizeof(*target)
bytes. If
target is a short then that is 2 * elsize bytes. Is that what you
intended?

Sent from my iPhone

On 04/03/2011, at 20:32, “Ted Chang” wrote:
>
> > Thanks,
> > target was a pointer to the buffer which used to save an array of
some
> > structure. The elsize was the size of that kind of structure which
is
> 0x30.
> > When I use the elproc function decoded the current element in the
xdrs, I
> > need to decode the next one. BTW, the xdrs->x_op was XDR_DECODE.
> >
> > Ted Chang
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Martin
O’Brien
> > Sent: Friday, March 04, 2011 5:23 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] A strange bug check reported by driver
verifier.
> >
> > Wouldn’t you just want to increment target, not increment it by
elsize
> > (which I assume stands for ‘element size’)?
> >
> > That is:
> >
> > target++
> >
> > v.
> >
> > 50: target += elsize;
> >
> >
> > mm
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Ted Chang
> > Sent: Friday, March 04, 2011 4:11 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] A strange bug check reported by driver
verifier.
> >
> > Thanks, James
> > The following is the code segment, it’s very old:
> >
> > 00:bool_t
> > 01:xdr_array(xdrs, addrp, sizep, maxsize, elsize, elproc)
> > 02: register XDR *xdrs;
> > 03: caddr_t addrp; / array pointer */
> > 04: u_int sizep; / number of elements /
> > 05: u_int maxsize; / max numberof elements /
> > 06: u_int elsize; / size in bytes of each element /
> > 07: xdrproc_t elproc; / xdr routine to handle each element */
> > 08:{
> > 09: register u_int i;
> > 10: register caddr_t target = addrp;
> > 11: register u_int c; / the actual element count /
> > 12: register bool_t stat = TRUE;
> > 13: register u_int nodesize;
> > 14:
> > 15: / like strings, arrays are really counted arrays */
> > 16: if (! xdr_u_int(xdrs, sizep)) {
> > 17: return (FALSE);
> > 18: }
> > 19: c = sizep;
> > 20: if ((c > maxsize) && (xdrs->x_op != XDR_FREE)) {
> > 21: return (FALSE);
> > 22: }
> > 23: nodesize = c * elsize;
> > 24:
> > 25: /
> > 26: * if we are deserializing, we may need to allocate an array.
> > 27: * We also save time by checking for a null array if we are
> freeing.
> > 28: */
> > 29: if (target == NULL)
> > 30: switch (xdrs->x_op) {
> > 31: case XDR_DECODE:
> > 32: if (c == 0)
> > 33: return (TRUE);
> > 34: addrp = target = mem_alloc(nodesize);
> > 35: if (target == NULL) {
> > 36: return (FALSE);
> > 37: }
> > 38: bzero(target, nodesize);
> > 39: break;
> > 40:
> > 41: case XDR_FREE:
> > 42: return (TRUE);
> > 43: }
> > 44:
> > 45: /
> > 46: * now we xdr each element of array
> > 47: */
> > 48: for (i = 0; (i < c) && stat; i++) {
> > 49: stat = (elproc)(xdrs, target, LASTUNSIGNED);
> > 50: target += elsize;
> > 51: }
> > 52:
> > 53: /
> > 54: * the array may need freeing
> > 55: */
> > 56: if (xdrs->x_op == XDR_FREE) {
> > 57: mem_free(*addrp, nodesize);
> > 58: *addrp = NULL;
> > 59: }
> > 60: return (stat);
> > 61:}
> >
> > The local variable c is 2, the parameter elsize is 0x30, the, the
problem
> > occurred at line 49, when i is 1, the target point to an address
which
> value
> > is 0x821170000. And the memory pointed by target cannot be accessed.
> > mem_alloc is a marco which directory call ExAllocatePoolWithTag
allocate
> > memory from non-paged pool. bzero is a wrapper of memset which
zeroed the
> > allocated memory.
> >
> >
> > Ted Chang
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
> > Sent: Friday, March 04, 2011 4:45 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] A strange bug check reported by driver
verifier.
> >
> >>
> >> Hi, all
> >> I have met a strange problem of accessing the memory. The problem
is I
> >> allocate 0x60 bytes from non-paged pool and when I access the
memory
> > at 0x30
> >> offset, the system bug checked. I have enabled the driver verifier
on
> > my
> >> driver. Thanks for any help in advance. The following is the
message
> > from
> >> windbg:
> >
> >
> > Can you post the offending code? Is the name of your driver really
> > XXXXXX or did you redact it because it’s so secret that even
mentioning
> > the driver name would be giving away too much :slight_smile:
> >
> > James
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other 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
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other 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
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other 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
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other 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
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other 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

10

So if the code segment
29: if (target == NULL)
30: switch (xdrs->x_op) {
31: case XDR_DECODE:

is being executed, and in particular

34: *addrp = target = mem_alloc(nodesize);
35: if (target == NULL) {
36: return (FALSE);
37: }
38: bzero(target, nodesize); <<< touches all of
the allocation.

gets executed, then the problem is in:

48: for (i = 0; (i < c) && stat; i++) {
49: stat = (*elproc)(xdrs, target, LASTUNSIGNED);
50: target += elsize;
51: }

where from your stack the function xdr_bw_bl_extent is invoked
indirectly and craps out at the start of the alleged pool allocation:
82117000?

These assertions are contradictory. target was not null.

Mark Roddy

On Fri, Mar 4, 2011 at 8:02 AM, Ted Chang wrote:
> Thank you very much, James. I always think addrp should be NULL and the
> memory was allocated by this function. But this may be wrong. I will add
> some log to the function and take more tests.
>
> Ted Chang
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
> Sent: Friday, March 04, 2011 7:53 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] A strange bug check reported by driver verifier.
>
>>
>> Sorry, I forget to mention that caddr_t is char *
>> typedef char *caddr_t;
>> #define bool_t int
>>
>
> When the function is entered, is *addrp definitely NULL, or does target
> definitely contain a buffer of the right size? The code seems to take
> the “only allocate if necessary” approach so if an incorrect sized
> buffer was allocated previously this might explain it.
>
> Have you put a breakpoint at the start and stepped through it with the
> debugger?
>
> Can you confirm that the function *elproc isn’t overstepping the memory
> buffer too?
>
> James
>
>
>> Ted Chang
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
>> Sent: Friday, March 04, 2011 5:59 PM
>> To: Windows System Software Devs Interest List
>> Cc: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] A strange bug check reported by driver verifier.
>>
>> target += elsize will advance target by elsize * sizeof(*target)
> bytes. If
>> target is a short then that is 2 * elsize bytes. Is that what you
> intended?
>>
>> Sent from my iPhone
>>
>> On 04/03/2011, at 20:32, “Ted Chang” wrote:
>>
>> > Thanks,
>> > target was a pointer to the buffer which used to save an array of
> some
>> > structure. The elsize was the size of that kind of structure which
> is
>> 0x30.
>> > When I use the elproc function decoded the current element in the
> xdrs, I
>> > need to decode the next one. BTW, the xdrs->x_op was XDR_DECODE.
>> >
>> > Ted Chang
>> >
>> >
>> > -----Original Message-----
>> > From: xxxxx@lists.osr.com
>> > [mailto:xxxxx@lists.osr.com] On Behalf Of Martin
> O’Brien
>> > Sent: Friday, March 04, 2011 5:23 PM
>> > To: Windows System Software Devs Interest List
>> > Subject: RE: [ntdev] A strange bug check reported by driver
> verifier.
>> >
>> > Wouldn’t you just want to increment target, not increment it by
> elsize
>> > (which I assume stands for ‘element size’)?
>> >
>> > That is:
>> >
>> > target++
>> >
>> > v.
>> >
>> > 50: ? ? ? ?target += elsize;
>> >
>> >
>> > mm
>> >
>> > -----Original Message-----
>> > From: xxxxx@lists.osr.com
>> > [mailto:xxxxx@lists.osr.com] On Behalf Of Ted Chang
>> > Sent: Friday, March 04, 2011 4:11 AM
>> > To: Windows System Software Devs Interest List
>> > Subject: RE: [ntdev] A strange bug check reported by driver
> verifier.
>> >
>> > Thanks, James
>> > The following is the code segment, it’s very old:
>> >
>> > 00:bool_t
>> > 01:xdr_array(xdrs, addrp, sizep, maxsize, elsize, elproc)
>> > 02: ? ?register XDR *xdrs;
>> > 03: ? ?caddr_t addrp; ? ? ? ?/ array pointer */
>> > 04: ? ?u_int sizep; ? ? ? ?/ number of elements /
>> > 05: ? ?u_int maxsize; ? ? ? ?/ max numberof elements /
>> > 06: ? ?u_int elsize; ? ? ? ?/ size in bytes of each element /
>> > 07: ? ?xdrproc_t elproc; ? ?/ xdr routine to handle each element */
>> > 08:{
>> > 09: ? ?register u_int i;
>> > 10: ? ?register caddr_t target = addrp;
>> > 11: ? ?register u_int c; ?/ the actual element count /
>> > 12: ? ?register bool_t stat = TRUE;
>> > 13: ? ?register u_int nodesize;
>> > 14:
>> > 15: ? ?/ like strings, arrays are really counted arrays */
>> > 16: ? ?if (! xdr_u_int(xdrs, sizep)) {
>> > 17: ? ? ? ?return (FALSE);
>> > 18: ? ?}
>> > 19: ? ?c = sizep;
>> > 20: ? ?if ((c > maxsize) && (xdrs->x_op != XDR_FREE)) {
>> > 21: ? ? ? ?return (FALSE);
>> > 22: ? ?}
>> > 23: ? ?nodesize = c * elsize;
>> > 24:
>> > 25: ? ?/
>> > 26: ? ? * if we are deserializing, we may need to allocate an array.
>> > 27: ? ? * We also save time by checking for a null array if we are
>> freeing.
>> > 28: ? ? */
>> > 29: ? ?if (target == NULL)
>> > 30: ? ? ? ?switch (xdrs->x_op) {
>> > 31: ? ? ? ?case XDR_DECODE:
>> > 32: ? ? ? ? ? ?if (c == 0)
>> > 33: ? ? ? ? ? ? ? ?return (TRUE);
>> > 34: ? ? ? ? ? ?addrp = target = mem_alloc(nodesize);
>> > 35: ? ? ? ? ? ?if (target == NULL) {
>> > 36: ? ? ? ? ? ? ? ?return (FALSE);
>> > 37: ? ? ? ? ? ?}
>> > 38: ? ? ? ? ? ?bzero(target, nodesize);
>> > 39: ? ? ? ? ? ?break;
>> > 40:
>> > 41: ? ? ? ?case XDR_FREE:
>> > 42: ? ? ? ? ? ?return (TRUE);
>> > 43: ? ?}
>> > 44:
>> > 45: ? ?/
>> > 46: ? ? * now we xdr each element of array
>> > 47: ? ? */
>> > 48: ? ?for (i = 0; (i < c) && stat; i++) {
>> > 49: ? ? ? ?stat = (elproc)(xdrs, target, LASTUNSIGNED);
>> > 50: ? ? ? ?target += elsize;
>> > 51: ? ?}
>> > 52:
>> > 53: ? ?/
>> > 54: ? ? * the array may need freeing
>> > 55: ? ? */
>> > 56: ? ?if (xdrs->x_op == XDR_FREE) {
>> > 57: ? ? ? ?mem_free(*addrp, nodesize);
>> > 58: ? ? ? ?*addrp = NULL;
>> > 59: ? ?}
>> > 60: ? ?return (stat);
>> > 61:}
>> >
>> > The local variable c is 2, the parameter elsize is 0x30, the, the
> problem
>> > occurred at line 49, when i is 1, the target point to an address
> which
>> value
>> > is 0x821170000. And the memory pointed by target cannot be accessed.
>> > mem_alloc is a marco which directory call ExAllocatePoolWithTag
> allocate
>> > memory from non-paged pool. bzero is a wrapper of memset which
> zeroed the
>> > allocated memory.
>> >
>> >
>> > Ted Chang
>> >
>> >
>> > -----Original Message-----
>> > From: xxxxx@lists.osr.com
>> > [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
>> > Sent: Friday, March 04, 2011 4:45 PM
>> > To: Windows System Software Devs Interest List
>> > Subject: RE: [ntdev] A strange bug check reported by driver
> verifier.
>> >
>> >>
>> >> Hi, all
>> >> I have met a strange problem of accessing the memory. The problem
> is I
>> >> allocate 0x60 bytes from non-paged pool and when I access the
> memory
>> > at 0x30
>> >> offset, the system bug checked. I have enabled the driver verifier
> on
>> > my
>> >> driver. Thanks for any help in advance. The following is the
> message
>> > from
>> >> windbg:
>> >
>> >
>> > Can you post the offending code? Is the name of your driver really
>> > XXXXXX or did you redact it because it’s so secret that even
> mentioning
>> > the driver name would be giving away too much :slight_smile:
>> >
>> > James
>> >
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > For our schedule of WDF, WDM, debugging and other 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
>> >
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > For our schedule of WDF, WDM, debugging and other 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
>> >
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > For our schedule of WDF, WDM, debugging and other 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
>> >
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > For our schedule of WDF, WDM, debugging and other 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
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other 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
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other 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
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>

11

If elproc accesses the target at offset 0x30, it will hit the bugcheck.

Check that the function is not using a wrong structure definition. If possible, step through its assembly code, or at least its source code.

12

Ted Chang wrote:

Hi, all
I have met a strange problem of accessing the memory. The problem is I
allocate 0x60 bytes from non-paged pool and when I access the memory at 0x30
offset, the system bug checked. I have enabled the driver verifier on my
driver. Thanks for any help in advance. The following is the message from
windbg:
…
FAULTING_IP:
XXXXXX!xdrmem_getlong+33
f0f24623 8901 mov dword ptr [ecx],eax

It is interesting to me that, even though windbg clearly told you the
crash happened in xdrmem_getlong, you did not show us the code for
xdrmem_getlong.

It’s odd to me that a function with that name would be storing a value.
I would expect xdrmem_getlong to READ memory and return a result in a
register.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.