Re: Driver IRQL Not Less an Eaqual!!
- From: Juan <Juan@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 25 Jan 2009 10:23:03 -0800
I see you said it was KIS causing the issue, I have the exact same problem at
the moment but with KAV and Vista x64 on a brand new computer, could you
elaborate on what you did to fix the BSOD issue
thanks
"Ridge Runner" wrote:
It's Kaspersky Internet Security causing the problem............
"jcgriff2" <guest@xxxxxxxxxxxxxxxxx> wrote in message
news:dab3ba643575d10beaff4bcadebb236d@xxxxxxxxxxxxxxxxxxx
RuffRider;862729 Wrote:
Exact same bunch of numbers and zeros every time.
STOP 0x000000D1 0x0000000000000000, 0x0000000000000002,
0x0000000000000008, 0x0000000000000000
Never changes, always the exact same.
A 0xd1 bugcheck = DRIVER_IRQL_NOT_LESS_OR_EQUAL and indicates that a
kernel-mode driver attempted to access a pageable memory address (or a
bad address) when it should not have (at a process IRQL that was too
high). A 0xd1 bugcheck is usually caused by drivers using improper
addresses.
A few things in the posted bugcheck I find interesting. I already
mentioned what 0xd1 means. The first parm inside the parenthesis is the
memory address referenced by the object in the 4th parm - so you have an
object with a memory address of 0x0 referencing a 0x0 - these s/b filled
with numbers and letters... not zeroes as far as I have ever seen. The
second parm (0x2) is the IRQL at the time #4 referenced #1, which is
fine (or at least a valid #). The 3rd parm 0x8 tells us that this is an
execution routine (0x0 = read; 0x1 = write).
The real interesting item here is that parm #4 = parm #1 and parm #3 is
0x8, which typically means that the bugcheck was caused by a driver
attempting to execute code that was paged out. Possible causes for this
are:
- the driver trying to acquire a resource/object lock - keeping its
siblings out
- a call was made to a driver that was already unloaded from RAM
- the pointer is bad
If no driver was named by the BSOD, then run the driver verifier in
hopes that it will cause a BSOD (like a 0xc4) and flag the offending
driver. If driver not named on BSOD screen, then maybe something will
show up in the stack text for all to see. No guarantees, of course.
The 0x0 in parms 1 & 4 are still bothersome.
I suggest you run memtest ISO if you have not already done so (not just
the Vista memory check).
If you invoke the driver verifier and BSOD occurs, get that dump, zip
it up and attach - c:\windows\minidump - it may contain the clue needed.
Where does XP Pro fit in here? Is this the same system? Do you have 1
app in common between the two systems that maybe contains old drivers?
The loaded driver list in the dbug output may tell us, unless it was
unloaded at the time of the crash.
You may also want to run driverquery and look over your drivers - Bring
up an *-elevated -*cmd prompt ("DOS") -
START | type cmd.exe into the start search box | right-click on cmd.exe
| select run as administrator - the type or copy/paste the following
into the DOS screen (to paste into DOS screen, right-click at the top,
select Edit, select Paste) hit Enter:
Code:
--------------------
*driverquery /v > %temp%\driverquery.txt & start notepad
%temp%\driverquery.txt*
--------------------
A notepad will appear with the driver query report. Watch out for the
ones marked "disabled" under the column "Start Mode".
Regards. . .
jcgriff2
.
--
jcgriff2
- Follow-Ups:
- Re: Driver IRQL Not Less an Eaqual!!
- From: jcgriff2
- Re: Driver IRQL Not Less an Eaqual!!
- Prev by Date: Re: internet problems
- Next by Date: Re: internet problems
- Previous by thread: how do I restore to a point of my choosing
- Next by thread: Re: Driver IRQL Not Less an Eaqual!!
- Index(es):
Relevant Pages
|
