someone will probably say that I need to have the disclaimer on this 
here are some things you can try. All of this assumes you’re running
the MS debugger. I’m not sure how/if you can access debugger extensions
from softice. In the end there’s not going to be a silver bullet and
you’ll probably have to do quite a bit of analysis on your own.
turn the driver verifier on and point it specifically at your driver.
run verifier on the crashing machine from a cmd window. Create standard
settings, select a driver from the list, add a driver and put in the
binary name of your component (assuming it wasn’t loaded and thus wasn’t
on the list). The verifier can often help catch these sorts of things
before they wind this far through the system.
try !analyze -v. Sometimes it’s better at unwinding the stack.
when the address is invalid rather than null use !pool
. This
might give you an idea of what the memory used to be. If it's one of
your allocations you can go use different tags for each thing you
allocate. If it's an IRP look in your driver extension to see if you
can find the bogus pointer ... perhaps you're reusing a field in there
after it's been freed.
you can try using dds to dump the stack pointer by pointer and see what
symbols might still be there. This leads to a lot of red herrings as
there are return addresses and global variable references littered
throughout the stack. Still, you can occasionally pick out a coherent
looking thread through your code (hey, mydriver!X calls mydriver!Y and
that calls nt!SomeLongSystemCallName so that's probably my stack).
maybe one of these techniques will help.
-p
-----Original Message-----
From: Rajiv B.L. [mailto:xxxxx@wipro.com]
Sent: Thursday, June 06, 2002 2:52 AM
To: NT Developers Interest List
Subject: [ntdev] Re: BugCheck D1
Hi,
Thanks for the replies.
Let me explain the problem slightly in detail. Firstly, there is no
interrupts since its a virtual driver. This happens randomly while data
transfer. The D1 bug-check is always hit with the memory referrenced and
code that referrenced this memory are same, i.e., the parameter 1 and
parameter 4 are always the same, sometimes it is NULL and sometimes
invalid address. How do i proceed debugging from this point as no stack
trace is available.
Any inputs on this will be of great help.
Thanks,
Rajiv.
-------------------------------------------------
You have a memory access problem. The code D1 is
DRIVER_IRQL_NOT_LESS_OR_EQUAL, meaning you touched pageable memory, or
location 0, at DISPATCH_LEVEL or above, like from a StartIo() function
or an interrupt handler. I know, because I get it all the time!!!! I
could never get a valid stack trace, and had to keep moving "_asm int
3;" around until I found it. It was a null pointer.
Rajiv B.L. wrote in message
news:xxxxx@ntdev...
>
> Hi All,
>
> Can anyone provide some information on how to debug the following bug
> check. The stack trace is also not helpful, since it provides trace
> only for DbgBreakPoint and KeHelper.
>
> *** Fatal System Error: 0x000000d1
> (0xFFFFFFFF,0x00000002,0x00000000,0xFFFFFFFF)
>
> Break instruction exception - code 80000003 (first chance)
>
> A fatal system error has occurred.
> Debugger entered on first try; Bugcheck callbacks have not been
> invoked.
>
> Probably caused by : ntoskrnl ( nt!DbgBreakPointWithStatus+4 )
>
> Thanks In Advance,
> Rajiv.
>
>
---
You are currently subscribed to ntdev as: xxxxx@wipro.com To
unsubscribe send a blank email to %%email.unsub%%
---
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%