Just had a thought… Does the behaviour change if you map the code
pageable? It should crash immediately when using DV. But it’s worth
checking to see that it actually does make a difference.
–
Mats
-------- Notice --------
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or any
action taken by you in reliance on it, is prohibited and may be unlawful.
If you have received this message in error, please delete it and contact
the sender immediately. Thank you.
xxxxx@lists.osr.com wrote on 12/13/2004 02:05:00 PM:
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.
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> ForwardSourceID:NT00009552</smtp:xxxxx>