RE: RE:(ntdev) (ntdev) Utterly mystified by this bugcheck

Reply Separator
Subject: Re: RE:(ntdev) (ntdev) Utterly mystified by this bugcheck.
Author: “Chuck Batson” smtp:xxxxx
Date: 13/12/2004 13:14

> To clarify, the instruction that bugchecks is the instruction that
> immediately follows your call to KeAcquireSpinlock()?

Yes, that’s correct.

> Also note this line from your original post:

> READ_ADDRESS: f1881574 Nonpaged pool

> 0xf1881574 of course being the address of the bugchecking instruction.
> Is it just me or does this mean that address really is not paged?

I’d say “most of the time”. I’ve seen situations where code that’s reported as
“nonpaged-pool” is actually in the PAGE section in the driver, and is in fact
paged out from time to time - hence why I checked the map file.

That tends to happen when dealing with KS property set identifiers - one of the
headers (ks.h?, ksmedia.h?) has some funny declspec stuff in it which results in
initialised constant data being put in the paged section.

> Although the symptom seems to indicate your code is missing when
> KeAcquireSpinlock() returns. Weird!

Very. Wondering if something happens that means that when the driver is paged
out, the “wrong parts” of the code get paged?

> This is a long shot, but is there any chance that something is
> overwriting the code in your driver? Perhaps, for example, a debugger
> putting a soft break point at address 0xf1881574?

Not as far as I can tell. This particular error occured whilst loading the
drivers during a warm boot, running the free version of the kernel, with driver
verifier enabled. I was testing something else entirely, and I just happened to
boot with the /debug switch and the debugger connected, but I hadn’t actually
done anything with the debugger or set any breakpoints since power on in the
morning.

Another “long shot” I’ve been tempted to consider is whether switching IRQ level
might unmask some sort of pending error or interrupt.

Pity it’s so hard to reproduce, another thing I could do is to remove the wait
call present in that particular system thread so it just spins, acquiring and
releasing the lock. ISTR that makes it crash rather fast.

MH.

This email and any attachments is confidential, may be legally privileged and is intended for the use of the addressee only. If you are not the intended recipient, please note that any use, disclosure, printing or copying of this email is strictly prohibited and may be unlawful. If received in error, please delete this email and any attachments and confirm this to the sender.</smtp:xxxxx>