I had previously sent in mail regarding a D1 bugcheck but got no response on the same. Since the stack itself looks corrupted, I think this might be because of a memory corruption (just guessing here). Anyways, does anybody know if using the driver verifier can track such problems. Hints on how I can debug this issue, would be greatly appreciated. Note that both param 1 and 4 of the bugcheck data revealed nothing of use to me...
Thanks
-Johnny
==============
I am somewhat at a loss as to how to debug a D1 bugcheck that I get when debugging my driver.. The information presented is quite meaningless, and I am clueless as to how to proceed. Might be that the stack itself is getting corrupted by the time I get to have a look at it...
I get a trap frame, but .trap gave me the following:
0006fef8 01003fae 000001f4 00814d5c 00000005 0x77e8affe
0006ff38 010046c8 77fb9045 77f83e80 7ffdf000 0x1003fae
0006ff70 0100b55f 00000001 00813648 00812928 0x10046c8
0006ffc0 77e992a6 77fb9045 77f83e80 7ffdf000 0x100b55f
0006fff0 00000000 0100b460 00000000 000000c8 0x77e992a6
PARAM 4 - supposedly the address causing the problem is pointing to non-code area of memory
None of these addresses are pointing to any code. How can I proceed to debug my driver ??
Thanks
-Johnny
====
BugCheck D1, {77e8b000, 2, 0, 77e8affe}
Probably caused by : ntkrnlmp
Followup: MachineOwner
nt!RtlpBreakWithStatusInstruction:
80453e90 cc int 3
1: kd> kb
ChildEBP RetAddr Args to Child
f7bc598c 8042a357 00000003 f7bc59d4 77e8b000
nt!RtlpBreakWithStatusInstruction
f7bc59bc 8042a94a 00000003 77e8b000 77e8affe nt!KiBugCheckDebugBreak+0x31
f7bc5d48 80466f7c 00000000 77e8b000 00000002 nt!KeBugCheckEx+0x390
f7bc5d48 77e8affe 00000000 77e8b000 00000002 nt!KiTrap0E+0x284
0006fef8 01003fae 000001f4 00814d5c 00000005 0x77e8affe
0006ff38 010046c8 77fb9045 77f83e80 7ffdf000 0x1003fae
0006ff70 0100b55f 00000001 00813648 00812928 0x10046c8
0006ffc0 77e992a6 77fb9045 77f83e80 7ffdf000 0x100b55f
0006fff0 00000000 0100b460 00000000 000000c8 0x77e992a6
Join the world’s largest e-mail service with MSN Hotmail. Click Here
“Johnny D” wrote in message news:xxxxx@ntdev…
>I get a trap frame, but .trap gave me the following:
>0006fef8 01003fae 000001f4 00814d5c 00000005 0x77e8affe
>0006ff38 010046c8 77fb9045 77f83e80 7ffdf000 0x1003fae
>0006ff70 0100b55f 00000001 00813648 00812928 0x10046c8
>0006ffc0 77e992a6 77fb9045 77f83e80 7ffdf000 0x100b55f
>0006fff0 00000000 0100b460 00000000 000000c8 0x77e992a6
>
>None of these addresses are pointing to any code. How can I proceed to
debug my driver ??
>
Well, you can’t from that mess. Set up the symbols properly. Try it on the
checked build. Let us know what the stack looks like at crash. And what
version of the OS this is on. We’ll try to help you from there.
But BE SURE the symbols are setup correctly. It may be hard to believe, but
even Alberto doesn’t know what function 0x77e8affe is…
Also, you DO just need to spend some time debugging it. We can’t do that
for you. Single step through the code, put in DbgPrints(…) whatever turns
you on.
When you hit a roadblock, send us lots of pertinent data to the list and
we’ll try to do what we can,
Peter
OSR
Thanks for responding to my email. DbgPrints werent really helping and my sympath looks fine to the best of my knowledge, so I used “driver verifier” to see whats going on: I had 2 questions regarding *Ndis spin lock* acquistiion/release order:
- If I do the following
grab A
grab B
release A
release B
Would this cause any problems as far as the IRQ levels are concerned?. whn I release B, then could I be causing a corruption? - I think I might be at a level lower than DISPATCH and that is a problem - Please confirm!
- When running within a timer function am I at DISPATCH level : How does it work… does a DPC thread get queued which at the specified time, runs my routine at DISPATCH level - Some explanation on how this works would help.
Regards
-Johnny
From: “Peter Viscarola”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: D1 bugcheck; driver verifier?
>Date: Fri, 3 May 2002 19:17:24 -0400
>
>“Johnny D” wrote in message news:xxxxx@ntdev…
> >I get a trap frame, but .trap gave me the following:
> >0006fef8 01003fae 000001f4 00814d5c 00000005 0x77e8affe
> >0006ff38 010046c8 77fb9045 77f83e80 7ffdf000 0x1003fae
> >0006ff70 0100b55f 00000001 00813648 00812928 0x10046c8
> >0006ffc0 77e992a6 77fb9045 77f83e80 7ffdf000 0x100b55f
> >0006fff0 00000000 0100b460 00000000 000000c8 0x77e992a6
> >
> >None of these addresses are pointing to any code. How can I proceed to
>debug my driver ??
> >
>
>Well, you can’t from that mess. Set up the symbols properly. Try it on the
>checked build. Let us know what the stack looks like at crash. And what
>version of the OS this is on. We’ll try to help you from there.
>
>But BE SURE the symbols are setup correctly. It may be hard to believe, but
>even Alberto doesn’t know what function 0x77e8affe is…
>
>Also, you DO just need to spend some time debugging it. We can’t do that
>for you. Single step through the code, put in DbgPrints(…) whatever turns
>you on.
>
>When you hit a roadblock, send us lots of pertinent data to the list and
>we’ll try to do what we can,
>
>Peter
>OSR
>
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%
Join the world’s largest e-mail service with MSN Hotmail. Click Here
Yes that is a problem; spinlocks must be released in reverse order; if the
order of acquisition is A then B, then you must release them in the order B
then A; this is because the acquisition stores the previous IRQL in the NDIS
spinlock structure and the release restores Irql to that value; thus is you
were at PASSIVE originally, the previous Irql stored in spinlock A would be
PASSIVE and in B would be DISPATCH. When you release them in the order A
then B, you will change Irql to PASSIVE when releasing A and then attempt to
change Irql to DISPATCH when you release B; not good!
/simgr
-----Original Message-----
From: Johnny D [mailto:xxxxx@hotmail.com]
Sent: Friday, May 03, 2002 11:56 PM
To: NT Developers Interest List
Cc: xxxxx@osr.com; xxxxx@storagecraft.com
Subject: [ntdev] Re: D1 bugcheck; driver verifier?
Thanks for responding to my email. DbgPrints werent really helping and my
sympath looks fine to the best of my knowledge, so I used “driver verifier”
to see whats going on: I had 2 questions regarding *Ndis spin lock*
acquistiion/release order:
- If I do the following
grab A
grab B
release A
release B
Would this cause any problems as far as the IRQ levels are concerned?. whn I
release B, then could I be causing a corruption? - I think I might be at a
level lower than DISPATCH and that is a problem - Please confirm!
- When running within a timer function am I at DISPATCH level : How does it
work… does a DPC thread get queued which at the specified time, runs my
routine at DISPATCH level - Some explanation on how this works would help.
Regards
-Johnny
From: “Peter Viscarola”
Reply-To: “NT Developers Interest List”
To: “NT Developers Interest List”
Subject: [ntdev] Re: D1 bugcheck; driver verifier?
Date: Fri, 3 May 2002 19:17:24 -0400
“Johnny D” wrote in message news:xxxxx@ntdev…
>I get a trap frame, but .trap gave me the following:
>0006fef8 01003fae 000001f4 00814d5c 00000005 0x77e8affe
>0006ff38 010046c8 77fb9045 77f83e80 7ffdf000 0x1003fae
>0006ff70 0100b55f 00000001 00813648 00812928 0x10046c8
>0006ffc0 77e992a6 77fb9045 77f83e80 7ffdf000 0x100b55f
>0006fff0 00000000 0100b460 00000000 000000c8 0x77e992a6
>
>None of these addresses are pointing to any code. How can I proceed to
debug my driver ??
>
Well, you can’t from that mess. Set up the symbols properly. Try it on the
checked build. Let us know what the stack looks like at crash. And what
version of the OS this is on. We’ll try to help you from there.
But BE SURE the symbols are setup correctly. It may be hard to believe, but
even Alberto doesn’t know what function 0x77e8affe is…
Also, you DO just need to spend some time debugging it. We can’t do that
for you. Single step through the code, put in DbgPrints(…) whatever turns
you on.
When you hit a roadblock, send us lots of pertinent data to the list and
we’ll try to do what we can,
Peter
OSR
You are currently subscribed to ntdev as: xxxxx@hotmail.com
To unsubscribe send a blank email to %%email.unsub%%
Join the world’s largest e-mail service with MSN Hotmail. Click Here
http:
—
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to %%email.unsub%%</http:>
Message>“Graham, Simon” wrote in message
news:xxxxx@ntdev…
>Yes that is a problem; spinlocks must be released in reverse order; if the
order of acquisition is A then B, then you must >release them in the order B
then A;
>
Simon is, of course, correct.
Just to clarify for the archive: NDIS spinlocks must be released in
reverse order (because they store the pre-spinlock IRQL in their own little
structure).
This doesn’t apply to KeAcquire/KeRelease…
P
Although you do have to preserve the IRQl order on release, i.e. don’t do
this:
KeAcquireSpinlock(&lock1, &lock1Irql); // PASSIVE->DISPATCH
KeAcquireSpinlock(&lock2, &lock2Irql); // DISPATCH->DISPATCH
someCode();
KeReleaseSpinlock(&lock1, lock1Irql); // DISPATCH->PASSIVE!
someMoreCodeAtTheWrongIrql(); // most likely bad things happen here
KeReleaseSpinlock(&lock2, lock2Irql); // UH-OH! PASSIVE->DISPATCH!
-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
Sent: Monday, May 06, 2002 9:38 AM
To: NT Developers Interest List
Subject: [ntdev] Re: D1 bugcheck; driver verifier?
Message>“Graham, Simon” wrote in message
> news:xxxxx@ntdev…
> >Yes that is a problem; spinlocks must be released in reverse
> order; if
> >the
> order of acquisition is A then B, then you must >release them
> in the order B then A;
> >
> Simon is, of course, correct.
>
> Just to clarify for the archive: NDIS spinlocks must be
> released in reverse order (because they store the
> pre-spinlock IRQL in their own little structure).
>
> This doesn’t apply to KeAcquire/KeRelease…
>
> P
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> %%email.unsub%%
>