Re: 0xa bugcheck - HELP REQUIRED!

NTDEV
1

Ok, so “!analyze -v” shows me some information, but not enough to make
progress. A code review didnt show any mis-usage of spin locks or events.
The memory location at fault when disassembeled gives me a pointer to NT
code which by itself without a meaningful stacktrace in which *my driver* is
present, makes no sense to me. “kv” gives me no FPO/trap frame information
so I cannot change the context record to point to one of my interest. There
has to be another way to get a menaingful stack, if you dont have a trap
frame address, right??.

Any help appreciated!
-Johnny

=====
1: kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pagable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000016, memory referenced
Arg2: 0000001c, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 8042b0c1, address which referenced memory

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: A

LAST_CONTROL_TRANSFER: from 8042a94a to 80453e90

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
f24ab928 8042a94a 00000003 00000016 8042b0c1 nt!DbgBreakPointWithStatus+0x4
f24abcb4 80466f7c 00000000 00000016 0000001c nt!KeBugCheckEx+0x390
f24abcd0 804681d9 f24abcf4 00000000 820216e0 nt!Kei386EoiHelper+0x2ae4
00000246 00000000 00000000 00000000 00000000 nt!KiUnexpectedInterrupt+0x29f

FOLLOWUP_IP:
nt!DbgBreakPointWithStatus+4
80453e90 cc int 3

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!DbgBreakPointWithStatus+4

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp

STACK_COMMAND: kb

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

1: kd> u 8042b0c1
nt!KeSetEvent+31:
8042b0c1 66394616 cmp [esi+0x16],ax
8042b0c5 7511 jnz nt!KeSetEvent+0x48 (8042b0d8)
8042b0c7 0fb75614 movzx edx,word ptr [esi+0x14]
8042b0cb ff750c push dword ptr [ebp+0xc]
8042b0ce 8b4e08 mov ecx,[esi+0x8]
8042b0d1 e8c2740000 call nt!ZwYieldExecution+0x1f90 (80432598)
8042b0d6 eb0f jmp nt!KeSetEvent+0x57 (8042b0e7)
8042b0d8 85ff test edi,edi

=====

>From: “Gary G. Little”
> >Reply-To: “NT Developers Interest List”
> >To: “NT Developers Interest List”
> >Subject: [ntdev] Re: 0xa bugcheck
> >Date: Tue, 12 Mar 2002 08:13:54 -0800
> >
> >My suggestion is to subscribe … It’s easy … and it’s free … well
>…
> >you do have to pay of a computer which isn’t free … or borrow someone’s
> >… or use someone’s … and you or they do have to have access to an ISP
> >… which isn’t free … oh never mind …
> >
> >Try running !analyze -v. If on SMP try “0kb/v” and or “1kb/v”.
> >
> >Barring that, who is at 8042CCA2 that was trying to access address 16?
> >
> >ewwwww … stinky …
> > ntoskrnl!KiReleaseSpinLock makes me wonder if you might not have an
> >un-initialized spin lock that you have attempted to access, or perhaps
>you
> >are passing a bogus spinlock address to KeReleaseSpinlock.
> >–
> >Gary G. Little
> >xxxxx@broadstor.com
> >xxxxx@inland.net
> >
> >“Johnny D” wrote in message news:xxxxx@ntdev…
> > >
> > > I got a 0xa bugcheck such as the following. I am unable to get a
>useful
> >trap
> > > frame address by doing “kv”, and so cannot do !trap to
> >get
> > > true frame. Is there some known way of getting around this. Please
> >include
> > > me in all your replies as I not subscribed directly.
> > >
> > > Thanks
> > > -Johnny
> > >
> > >
> > > *** Fatal System Error: 0x0000000a
> > > (0x00000016,0x00000002,0x00000000,0x8042CCA2)
> > >
> > >
> > > i386kd: A fatal system error has occurred.
> > > i386kd: Debugger entered on first try; Bugcheck callbacks have not
>been
> > > invoked.
> > >
> > >
> > > i386kd: A fatal system error has occurred.
> > >
> > > ntoskrnl!DbgBreakPointWithStatus+4:
> > > 80455994 cc int 3
> > > eax=00000003 ebx=0000000a ecx=f74c3dcc edx=00000000 esi=00000016
> > > edi=f74c3940
> > > eip=80455994 esp=f74c38fc ebp=f74c3928 iopl=0 nv up ei pl zr
>na
> >po
> > > nc
> > > cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> > > efl=00000246
> > > ntoskrnl!DbgBreakPointWithStatus+4:
> > > 80455994 cc int 3
> > > ChildEBP RetAddr Args to Child
> > > f74c3928 8042c2bb 00000003 00000016 8042cca2
> > > ntoskrnl!DbgBreakPointWithStatus+0x
> > > 4
> > > f74c3cb4 80467e7f 00000000 00000016 00000002
>ntoskrnl!KeBugCheckEx+0x169
> > > f74c3cd0 804024d7 f74c3cf4 00000000 813903a0
> >ntoskrnl!Kei386EoiHelper+0x2ac9
> > > 00000246 00000000 00000000 00000000 00000000
> > > ntoskrnl!KiReleaseSpinLock+0x1c7
> > > 80481b20 0000000a 00000016 00000002 00000000
> > > 80481b30 8042cca2
> > >
> > >
> > >
> > > MSN Photos is the easiest way to share and print your photos:
> > > http://photos.msn.com/support/worldwide.aspx
> > >
> > >
> > >
> >
> >
> >
> >—
> >You are currently subscribed to ntdev as: xxxxx@hotmail.com
> >To unsubscribe send a blank email to %%email.unsub%%
>
>
>
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

2

I snipped a lot of stuff that is meaningless, because of the error message
at the end of the part I left in. You need to get your symbols right
before you can successfully debug your driver.

That said, you can infer some things from the bugcheck codes, namely that a
pointer to NULL was put somewhere it shouldn’t be. This is evident from
the fact that the memory read that faulted is 0x16. Anything in the first
page (address < 0x1000) (4k) is pretty much guaranteed to be a bogus
address from any code you write.

Phil

“Johnny D” @lists.osr.com on 03/15/2002 02:03:37 PM

Please respond to “NT Developers Interest List”

Sent by: xxxxx@lists.osr.com

To: “NT Developers Interest List”
cc:

Subject: [ntdev] Re: 0xa bugcheck - HELP REQUIRED!

Ok, so “!analyze -v” shows me some information, but not enough to make
progress. A code review didnt show any mis-usage of spin locks or events.
The memory location at fault when disassembeled gives me a pointer to NT
code which by itself without a meaningful stacktrace in which my driver
is
present, makes no sense to me. “kv” gives me no FPO/trap frame information
so I cannot change the context record to point to one of my interest. There
has to be another way to get a menaingful stack, if you dont have a trap
frame address, right??.

Any help appreciated!
-Johnny

=====
1: kd> !analyze -v




 Bugcheck Analysis

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pagable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000016, memory referenced
Arg2: 0000001c, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 8042b0c1, address which referenced memory

Debugging Details:
------------------

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

3

Pay heed to what Phil said. Also take a look at that KiUnexpectedInterrupt.
If you are handling interrupts have you made a classic mistake of enabling
interrupts before you have succeeded a call to IoConnectInterrupt?

Mostly what you are seeing is life in kernel mode. You spend a hell of a lot
of time de-bunking problems in your driver when there is no direct evidence
that your driver caused the problem … other than the classic “It works
when my driver ain’t running.” These “symptoms” can be caused by clobbered
memory because boundaries in a memmove/cpy/zero were incorrect; a
mis-handled IRP; failure to acquire a spin lock before accessing critical
memory; many many more. Your driver caused it, but returned, and by
returning removed all evidence of itself from the call stack before the
system panics and crashes.

–
Gary G. Little
xxxxx@broadstor.com
xxxxx@inland.net

4

Yes, I understand that its an equivalent of a NULL pointer exception in the
kernel. Just that which object from my driver is causing the issue is not
clear, because of the lack of a meaningful stack trace. I am not using any
calls to handling interrupts myself. I am using the symbols server and set
up the sympath in a way such as the follows:

c:\winnt;http://msdl.microsoft.com/download/symbols

Please let me know if this sort of way of specifying the sympath is ok or
not?. If yes, then did the stack get clobbered in some way before we got a
chance to look at it?

thanks
-Johnny

From: xxxxx@seagate.com
Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: 0xa bugcheck - HELP REQUIRED!
>Date: Fri, 15 Mar 2002 14:12:10 -0700
>
>
>I snipped a lot of stuff that is meaningless, because of the error message
>at the end of the part I left in. You need to get your symbols right
>before you can successfully debug your driver.
>
>That said, you can infer some things from the bugcheck codes, namely that a
>pointer to NULL was put somewhere it shouldn’t be. This is evident from
>the fact that the memory read that faulted is 0x16. Anything in the first
>page (address < 0x1000) (4k) is pretty much guaranteed to be a bogus
>address from any code you write.
>
>Phil
>
>
>
>
>“Johnny D” @lists.osr.com on 03/15/2002 02:03:37 PM
>
>Please respond to “NT Developers Interest List”
>
>Sent by: xxxxx@lists.osr.com
>
>
>To: “NT Developers Interest List”
>cc:
>
>Subject: [ntdev] Re: 0xa bugcheck - HELP REQUIRED!
>
>
>Ok, so “!analyze -v” shows me some information, but not enough to make
>progress. A code review didnt show any mis-usage of spin locks or events.
>The memory location at fault when disassembeled gives me a pointer to NT
>code which by itself without a meaningful stacktrace in which my driver
>is
>present, makes no sense to me. “kv” gives me no FPO/trap frame information
>so I cannot change the context record to point to one of my interest. There
>has to be another way to get a menaingful stack, if you dont have a trap
>frame address, right??.
>
>
>Any help appreciated!
>-Johnny
>
>
>
>=====
>1: kd> !analyze -v
>
>
>
>
> Bugcheck Analysis
>
>
>
>
>
>
>IRQL_NOT_LESS_OR_EQUAL (a)
>An attempt was made to access a pagable (or completely invalid) address at
>an
>interrupt request level (IRQL) that is too high. This is usually
>caused by drivers using improper addresses.
>If a kernel debugger is available get the stack backtrace.
>Arguments:
>Arg1: 00000016, memory referenced
>Arg2: 0000001c, IRQL
>Arg3: 00000000, value 0 = read operation, 1 = write operation
>Arg4: 8042b0c1, address which referenced memory
>
>Debugging Details:
>------------------
>
> ***** Kernel symbols are WRONG. Please fix symbols to do analysis.
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

5

Your sympath is almost correct.

First, you need to give it a path to your driver symbols. I hope they
aren’t in C:\WINNT. Second, you need to look more carefully at the
documentation for using the online symbol server. There’s more to it than
what you have, and it will be a useful learning experience for you to sort
that part out yourself.
http://www.microsoft.com/ddk/debugging/symbols.asp

Once you have those two issues worked out, you might still have the problem
that Gary described, which is that you are clobbering something that isn’t
discovered until after the routine that clobbered it is long gone. Driver
Verifier can help with this. If all else fails, single stepping through
your code, while watching the boundaries of your data structures, is also
useful. If you are indeed clobbering memory you don’t own, doing this can
show you where it’s occurring.

Hope this helps.

Phil

“Johnny D” @lists.osr.com on 03/15/2002 03:08:57 PM

Please respond to “NT Developers Interest List”

Sent by: xxxxx@lists.osr.com

To: “NT Developers Interest List”
cc: xxxxx@seagate.com, xxxxx@broadstor.com

Subject: [ntdev] Re: 0xa bugcheck - HELP REQUIRED!

Yes, I understand that its an equivalent of a NULL pointer exception in the
kernel. Just that which object from my driver is causing the issue is not
clear, because of the lack of a meaningful stack trace. I am not using any
calls to handling interrupts myself. I am using the symbols server and set
up the sympath in a way such as the follows:

c:\winnt;http://msdl.microsoft.com/download/symbols

Please let me know if this sort of way of specifying the sympath is ok or
not?. If yes, then did the stack get clobbered in some way before we got a
chance to look at it?

thanks
-Johnny

>From: xxxxx@seagate.com
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: 0xa bugcheck - HELP REQUIRED!
>Date: Fri, 15 Mar 2002 14:12:10 -0700
>
>
>I snipped a lot of stuff that is meaningless, because of the error message
>at the end of the part I left in. You need to get your symbols right
>before you can successfully debug your driver.
>
>That said, you can infer some things from the bugcheck codes, namely that
a
>pointer to NULL was put somewhere it shouldn’t be. This is evident from
>the fact that the memory read that faulted is 0x16. Anything in the first
>page (address < 0x1000) (4k) is pretty much guaranteed to be a bogus
>address from any code you write.
>
>Phil
>
>
>
>
>“Johnny D” @lists.osr.com on 03/15/2002 02:03:37
PM
>
>Please respond to “NT Developers Interest List”
>
>Sent by: xxxxx@lists.osr.com
>
>
>To: “NT Developers Interest List”
>cc:
>
>Subject: [ntdev] Re: 0xa bugcheck - HELP REQUIRED!
>
>
>Ok, so “!analyze -v” shows me some information, but not enough to make
>progress. A code review didnt show any mis-usage of spin locks or events.
>The memory location at fault when disassembeled gives me a pointer to NT
>code which by itself without a meaningful stacktrace in which my driver
>is
>present, makes no sense to me. “kv” gives me no FPO/trap frame information
>so I cannot change the context record to point to one of my interest.
There
>has to be another way to get a menaingful stack, if you dont have a trap
>frame address, right??.
>
>
>Any help appreciated!
>-Johnny
>
>
>
>=====
>1: kd> !analyze -v
>


>
>
>
> Bugcheck Analysis
>
>
>
>

>
>
>IRQL_NOT_LESS_OR_EQUAL (a)
>An attempt was made to access a pagable (or completely invalid) address at
>an
>interrupt request level (IRQL) that is too high. This is usually
>caused by drivers using improper addresses.
>If a kernel debugger is available get the stack backtrace.
>Arguments:
>Arg1: 00000016, memory referenced
>Arg2: 0000001c, IRQL
>Arg3: 00000000, value 0 = read operation, 1 = write operation
>Arg4: 8042b0c1, address which referenced memory
>
>Debugging Details:
>------------------
>
> ***** Kernel symbols are WRONG. Please fix symbols to do analysis.
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

—
You are currently subscribed to ntdev as: xxxxx@seagate.com
To unsubscribe send a blank email to %%email.unsub%%

6

0x0000000a : IRQL_NOT_LESS_OR_EQUAL
(0x00000016: Memory referenced ,
0x00000002: DISPATCH_LEVEL,
0x00000000: Read,
0x8042CCA2: Address which referenced memory)

My suggestion is to check all “super dangerous” reinterpret_cast(s) in
your code if your code is c++. reinterpret_cast in c++ ddev is
usually used for reinterpreting pointers to void* and passing it
through Context to somewhere else. Receiver of the context then
reinterprets this pointer back to some meaningful pointer. Here is an
example were reinterpret_cast will fail:

class Base1;
class Base2;

class Derived : public Base1, public Base2
{
}
***********
Derived* d = new Derived;
void* voidPtr = reinterpret_cast(d);
something->Context = voidPtr;
.
.
.
Base1* base1Ptr = reinterpret_cast(something->Context);

The pointer base1Ptr is illegal. The code will still execute but
access to any base1Ptr->member will result in page fault.

2. LOCKED CODE

#ifdef ALLOC_PRAGMA
#pragma code_seg()
#endif // ALLOC_PRAGMA

Use this pragma where your code runs at DISPATCH_LEVEL.

P.S. My suggestions might not help you … anyway, it won’t hurt if
you check your code once more …

Robert M.

On Fri, 15 Mar 2002 21:03:37 +0000, “Johnny D”
wrote:

>
>Ok, so “!analyze -v” shows me some information, but not enough to make
>progress. A code review didnt show any mis-usage of spin locks or events.
>The memory location at fault when disassembeled gives me a pointer to NT
>code which by itself without a meaningful stacktrace in which my driver is
>present, makes no sense to me. “kv” gives me no FPO/trap frame information
>so I cannot change the context record to point to one of my interest. There
>has to be another way to get a menaingful stack, if you dont have a trap
>frame address, right??.
>
>
>Any help appreciated!
>-Johnny
>
>
>
>=====
>1: kd> !analyze -v
>
>
>
> Bugcheck Analysis
>
>
>
>
>
>IRQL_NOT_LESS_OR_EQUAL (a)
>An attempt was made to access a pagable (or completely invalid) address at
>an
>interrupt request level (IRQL) that is too high. This is usually
>caused by drivers using improper addresses.
>If a kernel debugger is available get the stack backtrace.
>Arguments:
>Arg1: 00000016, memory referenced
>Arg2: 0000001c, IRQL
>Arg3: 00000000, value 0 = read operation, 1 = write operation
>Arg4: 8042b0c1, address which referenced memory
>
>Debugging Details:
>------------------
>
>**Kernel symbols are WRONG. Please fix symbols to do analysis.
>
>
>DEFAULT_BUCKET_ID: DRIVER_FAULT
>
>BUGCHECK_STR: A
>
>LAST_CONTROL_TRANSFER: from 8042a94a to 80453e90
>
>STACK_TEXT:
>WARNING: Stack unwind information not available. Following frames may be
>wrong.
>f24ab928 8042a94a 00000003 00000016 8042b0c1 nt!DbgBreakPointWithStatus+0x4
>f24abcb4 80466f7c 00000000 00000016 0000001c nt!KeBugCheckEx+0x390
>f24abcd0 804681d9 f24abcf4 00000000 820216e0 nt!Kei386EoiHelper+0x2ae4
>00000246 00000000 00000000 00000000 00000000 nt!KiUnexpectedInterrupt+0x29f
>
>
>FOLLOWUP_IP:
>nt!DbgBreakPointWithStatus+4
>80453e90 cc int 3
>
>FOLLOWUP_NAME: MachineOwner
>
>SYMBOL_NAME: nt!DbgBreakPointWithStatus+4
>
>MODULE_NAME: nt
>
>IMAGE_NAME: ntkrnlmp
>
>STACK_COMMAND: kb
>
>BUCKET_ID: WRONG_SYMBOLS
>
>Followup: MachineOwner
>---------
>
>1: kd> u 8042b0c1
>nt!KeSetEvent+31:
>8042b0c1 66394616 cmp [esi+0x16],ax
>8042b0c5 7511 jnz nt!KeSetEvent+0x48 (8042b0d8)
>8042b0c7 0fb75614 movzx edx,word ptr [esi+0x14]
>8042b0cb ff750c push dword ptr [ebp+0xc]
>8042b0ce 8b4e08 mov ecx,[esi+0x8]
>8042b0d1 e8c2740000 call nt!ZwYieldExecution+0x1f90 (80432598)
>8042b0d6 eb0f jmp nt!KeSetEvent+0x57 (8042b0e7)
>8042b0d8 85ff test edi,edi
>
>=====
>>
>> >From: “Gary G. Little”
>> >Reply-To: “NT Developers Interest List”
>> >To: “NT Developers Interest List”
>> >Subject: [ntdev] Re: 0xa bugcheck
>> >Date: Tue, 12 Mar 2002 08:13:54 -0800
>> >
>> >My suggestion is to subscribe … It’s easy … and it’s free … well
>>…
>> >you do have to pay of a computer which isn’t free … or borrow someone’s
>> >… or use someone’s … and you or they do have to have access to an ISP
>> >… which isn’t free … oh never mind …
>> >
>> >Try running !analyze -v. If on SMP try “0kb/v” and or “1kb/v”.
>> >
>> >Barring that, who is at 8042CCA2 that was trying to access address 16?
>> >
>> >ewwwww … stinky …
>> > ntoskrnl!KiReleaseSpinLock makes me wonder if you might not have an
>> >un-initialized spin lock that you have attempted to access, or perhaps
>>you
>> >are passing a bogus spinlock address to KeReleaseSpinlock.
>> >–
>> >Gary G. Little
>> >xxxxx@broadstor.com
>> >xxxxx@inland.net
>> >
>> >“Johnny D” wrote in message news:xxxxx@ntdev…
>> > >
>> > > I got a 0xa bugcheck such as the following. I am unable to get a
>>useful
>> >trap
>> > > frame address by doing “kv”, and so cannot do !trap to
>> >get
>> > > true frame. Is there some known way of getting around this. Please
>> >include
>> > > me in all your replies as I not subscribed directly.
>> > >
>> > > Thanks
>> > > -Johnny
>> > >
>> > >
>> > > Fatal System Error: 0x0000000a
>> > > (0x00000016,0x00000002,0x00000000,0x8042CCA2)
>> > >
>> > >
>> > > i386kd: A fatal system error has occurred.
>> > > i386kd: Debugger entered on first try; Bugcheck callbacks have not
>>been
>> > > invoked.
>> > >
>> > >
>> > > i386kd: A fatal system error has occurred.
>> > >
>> > > ntoskrnl!DbgBreakPointWithStatus+4:
>> > > 80455994 cc int 3
>> > > eax=00000003 ebx=0000000a ecx=f74c3dcc edx=00000000 esi=00000016
>> > > edi=f74c3940
>> > > eip=80455994 esp=f74c38fc ebp=f74c3928 iopl=0 nv up ei pl zr
>>na
>> >po
>> > > nc
>> > > cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
>> > > efl=00000246
>> > > ntoskrnl!DbgBreakPointWithStatus+4:
>> > > 80455994 cc int 3
>> > > ChildEBP RetAddr Args to Child
>> > > f74c3928 8042c2bb 00000003 00000016 8042cca2
>> > > ntoskrnl!DbgBreakPointWithStatus+0x
>> > > 4
>> > > f74c3cb4 80467e7f 00000000 00000016 00000002
>>ntoskrnl!KeBugCheckEx+0x169
>> > > f74c3cd0 804024d7 f74c3cf4 00000000 813903a0
>> >ntoskrnl!Kei386EoiHelper+0x2ac9
>> > > 00000246 00000000 00000000 00000000 00000000
>> > > ntoskrnl!KiReleaseSpinLock+0x1c7
>> > > 80481b20 0000000a 00000016 00000002 00000000
>> > > 80481b30 8042cca2
>> > >
>> > >
>> > >
>> > > MSN Photos is the easiest way to share and print your photos:
>> > > http://photos.msn.com/support/worldwide.aspx
>> > >
>> > >
>> > >
>> >
>> >
>> >
>> >—
>> >You are currently subscribed to ntdev as: xxxxx@hotmail.com
>> >To unsubscribe send a blank email to %%email.unsub%%
>>
>>
>>
>>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
>
>
> _________________________________________________________________
>Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
>

7

The original post had a bugcheck caused by dereferencing an obviously NULL
pointer, so I don’t think the problem described below is his problem. But
what is wrong with the code below? What makes the dereference of the
<reinterpret_-cast>ed pointer invalid? If the pointer isn’t null, then
that’s not the problem. Is it an issue of changing thread or process
contexts changing the VA space? If that’s the case, then how does anything
that passes a void* across thread or process boundaries ever work? You
haven’t not explained the failure, just asserted that it will happen.
Please finish the story…

Phil

“Robert M.” <robert.m>@lists.osr.com on 03/17/2002 05:48:05 AM

Please respond to “NT Developers Interest List”

Sent by: xxxxx@lists.osr.com

To: “NT Developers Interest List”
cc:

Subject: [ntdev] Re: 0xa bugcheck - HELP REQUIRED!
1.
My suggestion is to check all “super dangerous” reinterpret_cast(s) in
your code if your code is c++. reinterpret_cast in c++ ddev is
usually used for reinterpreting pointers to void* and passing it
through Context to somewhere else. Receiver of the context then
reinterprets this pointer back to some meaningful pointer. Here is an
example were reinterpret_cast will fail:

class Base1;
class Base2;

class Derived : public Base1, public Base2
{
}
***********
Derived* d = new Derived;
void* voidPtr = reinterpret_cast(d);
something->Context = voidPtr;
.
.
.
Base1* base1Ptr = reinterpret_cast(something->Context);

The pointer base1Ptr is illegal. The code will still execute but
access to any base1Ptr->member will result in page fault.</robert.m></reinterpret_-cast>

8

Philip,

Probably the issue with the code below is the
wrong use of reinterpret_cast instead of dynamic_cast
which should be used when dealing with polymorphic
types(RTTI issue…), but in this case I don’t
understand the point of this code either.

Regards,
-Mike.
— xxxxx@seagate.com wrote:

The original post had a bugcheck caused by
dereferencing an obviously NULL
pointer, so I don’t think the problem described
below is his problem. But
what is wrong with the code below? What makes the
dereference of the
<reinterpret_-cast>ed pointer invalid? If the
> pointer isn’t null, then
> that’s not the problem. Is it an issue of changing
> thread or process
> contexts changing the VA space? If that’s the case,
> then how does anything
> that passes a void* across thread or process
> boundaries ever work? You
> haven’t not explained the failure, just asserted
> that it will happen.
> Please finish the story…
>
> Phil
>
>
>
>
> “Robert M.” <robert.m>@lists.osr.com on
> 03/17/2002 05:48:05 AM
>
> Please respond to “NT Developers Interest List”
>
>
> Sent by: xxxxx@lists.osr.com
>
>
> To: “NT Developers Interest List”
>
> cc:
>
> Subject: [ntdev] Re: 0xa bugcheck - HELP REQUIRED!
> 1.
> My suggestion is to check all “super dangerous”
> reinterpret_cast(s) in
> your code if your code is c++. reinterpret_cast in
> c++ ddev is
> usually used for reinterpreting pointers to void*
> and passing it
> through Context to somewhere else. Receiver of the
> context then
> reinterprets this pointer back to some meaningful
> pointer. Here is an
> example were reinterpret_cast will fail:
>
> class Base1;
> class Base2;
>
> class Derived : public Base1, public Base2
> {
> }
> ***********
> Derived* d = new Derived;
> void* voidPtr = reinterpret_cast(d);
> something->Context = voidPtr;
> .
> .
> .
> Base1* base1Ptr =
> reinterpret_cast(something->Context);
>
> The pointer base1Ptr is illegal. The code will still
> execute but
> access to any base1Ptr->member will result in page
> fault.
>
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
%%email.unsub%%

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/</robert.m></reinterpret_-cast>

9

On Mon, 18 Mar 2002 16:12:57 -0700, xxxxx@seagate.com wrote:

If I understend the bugcheck codes correctly the memory referenced was
0x00000016 != NULL and the operation was *Read* operation at
IRQL==DISPATCH_LEVEL. It looks to me like unexpected pointer value
rather than NULL pointer.

This will explain what I meant in my previous post. Here is an example
to play with:

#include <assert.h>

class base1
{
private:
int m_iBase1Member;
};

class base2
{
protected:
int& m_iBase2Member;
public:
base2(int& iValue) : m_iBase2Member(iValue){};
void SetMember(int iValue)
{
m_iBase2Member = iValue;
}
};

class derived : public base1, public base2
{
public:
derived(int& iValue) : base2(iValue) {}
};

int main(int argc, char* argv)
{
int iValue;
derived* d = new derived(iValue);

// this is OK !!!
((base2*)d)->SetMember(0x12345678);
// the assertion will not fail
assert(iValue == 0x12345678);

void* pv = reinterpret_cast(d);
base2* b2 = reinterpret_cast(pv);

// if you are lucky the page fault will occur within
// SetMember, otherwise it will somewhere else
b2->SetMember(0x87654321);
// the assertion will fail %100
assert(iValue == 0x87654321);

return 0;
}

>
>
>The original post had a bugcheck caused by dereferencing an obviously NULL
>pointer, so I don’t think the problem described below is his problem. But
>what is wrong with the code below? What makes the dereference of the
><reinterpret_-cast>ed pointer invalid? If the pointer isn’t null, then
>that’s not the problem. Is it an issue of changing thread or process
>contexts changing the VA space? If that’s the case, then how does anything
>that passes a void* across thread or process boundaries ever work? You
>haven’t not explained the failure, just asserted that it will happen.
>Please finish the story…
>
>Phil
>
>
>
>
>“Robert M.” <robert.m>@lists.osr.com on 03/17/2002 05:48:05 AM
>
>Please respond to “NT Developers Interest List”
>
>Sent by: xxxxx@lists.osr.com
>
>
>To: “NT Developers Interest List”
>cc:
>
>Subject: [ntdev] Re: 0xa bugcheck - HELP REQUIRED!
>1.
>My suggestion is to check all “super dangerous” reinterpret_cast(s) in
>your code if your code is c++. reinterpret_cast in c++ ddev is
>usually used for reinterpreting pointers to void* and passing it
>through Context to somewhere else. Receiver of the context then
>reinterprets this pointer back to some meaningful pointer. Here is an
>example were reinterpret_cast will fail:
>
>class Base1;
>class Base2;
>
>class Derived : public Base1, public Base2
>{
>}
> ***********
>Derived* d = new Derived;
>void* voidPtr = reinterpret_cast(d);
>something->Context = voidPtr;
>.
>.
>.
>Base1* base1Ptr = reinterpret_cast(something->Context);
>
>The pointer base1Ptr is illegal. The code will still execute but
>access to any base1Ptr->member will result in page fault.
>
>
>
></robert.m></reinterpret_-cast></assert.h>

10

>

If I understend the bugcheck codes correctly the memory
referenced was 0x00000016 != NULL and the operation was
*Read* operation at IRQL==DISPATCH_LEVEL. It looks to me like
unexpected pointer value rather than NULL pointer.

Phil was ommitting the common sequence of: ‘reference through null
pointer to offset in structure’, a bug whose signature is a 0x0a
bugcheck with a value at or near zero for the ‘memory location’, and
simply referring to this as a NULL pointer. The cpu is happy to add 0x16
to NULL, it is the attempt to read the value stored at 0x16 that causes
the problem.

=====================
Mark Roddy
Windows XP/2000/NT Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
xxxxx@hollistech.com
For Windows Device Driver Training: see www.azius.com

11

603-321-1032
wrote in message news:xxxxx@ntdev…
>
>
> The original post had a bugcheck caused by dereferencing an obviously NULL
> pointer, so I don’t think the problem described below is his problem. But
> what is wrong with the code below? What makes the dereference of the
> <reinterpret_-cast>ed pointer invalid? If the pointer isn’t null, then
> that’s not the problem. Is it an issue of changing thread or process
> contexts changing the VA space? If that’s the case, then how does
anything
> that passes a void* across thread or process boundaries ever work? You
> haven’t not explained the failure, just asserted that it will happen.
> Please finish the story…
>

The problem is setting a base class pointer to the address of a derived
class, where the derived class uses multiple inheritance, and expecting that
to always work.

The memory layout is like this:

Derived {

Base1; // he occupies storage

Base2; // so this is not the same address as Derived.

}

The programmer lies and tells the compiler that the address of Derived is
the same as the address of Base2, when it obviously isn’t if Base1 occupies
any storage at all. A cast to Base1 would work, but only because of a priori
knowledge of the storage layout. STATUS_BAD_PROGRAMMER_ON_DEVICE. Don’t do
that. See Scott Meyers’ Effective C++ series and elsewhere for the horrors
of MI. Try a container relationship instead.

As pointed out elsewhere, a dynamic_cast would offset the base pointer value
correctly to skip the storage for Base1 and point b2 at Base2.
reinterpret_cast should be used with caution.

–
===
Mark Roddy
Consultant
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com</reinterpret_-cast>

12

OK, just to clear the confusion I made. I never said that my
suggestions will save the day. The point of my post was … when there
is no obvious reason for the failure you might want to check your code
for other not so obvious errors. You must agree that
rinterpret_casts(s) are widely used in c++ driver dev. and if you are
not 100% sure what it does you might run into troubles.

Robert M.

13

Your memory is correct, the memory read was to 0x00000016, which is not
NULL, however, there are relatively few occasions when system routines are
directly dereferencing a pointer, because most of them are pointers to
structures, so they end up dereferencing an offset from the pointer. As a
consequence, even though the bug is a NULL pointer, you end up deref’ng a
non-NULL address. But it’s still a NULL pointer, and it’s usually pretty
evident that it’s NULL instead of wild, where wild can be anywhere in
memory that doesn’t look like it’s NULL or an offset from NULL.

As to the second one, I’m not very sharp on polymorphism, but it looks like
you are assigning the pointer to 0x87654321 in the second case, so I would
expect it to fail. But I might be reading it wrong. As others have said,
<dynamic_cast> is probably more appropiate, anyway. Thanks for the
explanation.

Phil

“Robert M.” <robert.m>@lists.osr.com on 03/19/2002 01:46:28 AM

Please respond to “NT Developers Interest List”

Sent by: xxxxx@lists.osr.com

To: “NT Developers Interest List”
cc:

Subject: [ntdev] Re: 0xa bugcheck - HELP REQUIRED!

On Mon, 18 Mar 2002 16:12:57 -0700, xxxxx@seagate.com wrote:

If I understend the bugcheck codes correctly the memory referenced was
0x00000016 != NULL and the operation was Read operation at
IRQL==DISPATCH_LEVEL. It looks to me like unexpected pointer value
rather than NULL pointer.

This will explain what I meant in my previous post. Here is an example
to play with:

#include <assert.h>

class base1
{
private:
int m_iBase1Member;
};

class base2
{
protected:
int& m_iBase2Member;
public:
base2(int& iValue) : m_iBase2Member(iValue){};
void SetMember(int iValue)
{
m_iBase2Member = iValue;
}
};

class derived : public base1, public base2
{
public:
derived(int& iValue) : base2(iValue) {}
};

int main(int argc, char* argv)
{
int iValue;
derived* d = new derived(iValue);

// this is OK !!!
((base2*)d)->SetMember(0x12345678);
// the assertion will not fail
assert(iValue == 0x12345678);

void* pv = reinterpret_cast(d);
base2* b2 = reinterpret_cast(pv);

// if you are lucky the page fault will occur within
// SetMember, otherwise it will somewhere else
b2->SetMember(0x87654321);
// the assertion will fail %100
assert(iValue == 0x87654321);

return 0;
}</assert.h></robert.m></dynamic_cast>

14

Ahhh. That makes plenty of sense. Thanks for filling in the blanks.

Phil

“Mark Roddy” @lists.osr.com on 03/19/2002 07:17:27 AM

Please respond to “NT Developers Interest List”

Sent by: xxxxx@lists.osr.com

To: “NT Developers Interest List”
cc:

Subject: [ntdev] Re: 0xa bugcheck - HELP REQUIRED!

The problem is setting a base class pointer to the address of a derived
class, where the derived class uses multiple inheritance, and expecting
that
to always work.

The memory layout is like this:

Derived {

Base1; // he occupies storage

Base2; // so this is not the same address as Derived.

}

The programmer lies and tells the compiler that the address of Derived is
the same as the address of Base2, when it obviously isn’t if Base1 occupies
any storage at all. A cast to Base1 would work, but only because of a
priori
knowledge of the storage layout. STATUS_BAD_PROGRAMMER_ON_DEVICE. Don’t do
that. See Scott Meyers’ Effective C++ series and elsewhere for the horrors
of MI. Try a container relationship instead.

As pointed out elsewhere, a dynamic_cast would offset the base pointer
value
correctly to skip the storage for Base1 and point b2 at Base2.
reinterpret_cast should be used with caution.