Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Getting IRQL from the debugger

Jake_OshinsJake_Oshins Member Posts: 1,058
This topic seems to recur way too often. So I'll post some explanation
again.

When you look in the PCR with !pcr in the debugger, you're looking at what
has been written into some scratchpad space that may or may not be currently
in use by the HAL. Several HALs use the PCR to track IRQL. Other HALs use
the TPR (Task Priority Register) in the Local APIC. Still others may have
their own implementations. So you should always consider the value of IRQL
in the PCR to be suspect, simply because it may not be in use. A value like
0xFF, which corresponds to no actual IRQL should immediately clue you in to
the fact that the HAL that you're using ignores the value in the PCR.

Furthermore, you need to understand what, exactly, the debugger really is
and what it really does. (This discussion applies to the debugger that is
built into the NT kernel, and not Soft-ICE or an Arium or an ITP that is
debugging from outside of the kernel.) The debugger is just a piece of code
that runs within the kernel, trying to depend on as few services from
outside itself as possible. In order to become more deterministic, it
disables interrupts whenever it is entered. The NT way of disabling
interrupts securely and safely is to raise IRQL to HIGH_LEVEL. Thus,
whenever you're in the debugger, IRQL is actually HIGH_LEVEL, regardless of
what it was when it was executing the code that you were trying to debug.

Consequently, looking at the IRQL in the PCR from the debugger should always
tell you HIGH_LEVEL if the PCR is actually being used to track IRQL. If it
tells you anything else, it's meaningless. (This assumes that you actually
found some meaning in asking what the current IRQL is while you're in the
debugger, as you knew a-priori it should be HIGH_LEVEL.) This point also
applies if you try to read the APIC TPR on a HAL that uses the TPR to track
IRQL. It should always correspond to HIGH_LEVEL while you're in the
debugger.

The only way you can reliably find out what IRQL your code was running at is
to look at where the debugger pushed your IRQL onto the stack when the
debugger was entered. Interestingly, this is beyond the end of the stack
frame that the debugger itself displays to you, as the debugger assumes that
you are primarily interested in the code that you wrote, not the debugger
itself. So it pretends that the stack ends at your code, not automatically
displaying the part of the stack that the debugger itself is currently
running on.

Lastly, the WinDbg team has taken note in recent years that lots of people
would be interested in knowing what IRQL their code was running at.
Unfortunately, they noticed this first for people who were trying to debug
crashdumps and only later (at my begging) extended their code to be able to
tell you for a running system.

So you can know what IRQL code was running at on Windows XP and later when
debugging a crashdump by using !irql. If you are debugging Windows Server
2003 or later, !irql will give you an accurate answer even if you're
debugging a live system. !irql does exactly what I suggested above. It
looks at the IRQL that the debugger itself stored as it was being entered.

Please, let us never see another posting saying that IRQL was 0xFF.

--
Jake Oshins
Windows Kernel Group

This posting is provided "AS IS" with no warranties, and confers no rights.

Comments

  • Gary_G._LittleGary_G._Little Member Posts: 508
    Hmmm, I'll give it 48 hours.

    --
    The personal opinion of
    Gary G. Little

    "Jake Oshins" wrote in message
    news:xxxxx@ntdev...
    > This topic seems to recur way too often. So I'll post some explanation
    > again.
    >
    > When you look in the PCR with !pcr in the debugger, you're looking at what
    > has been written into some scratchpad space that may or may not be
    currently
    > in use by the HAL. Several HALs use the PCR to track IRQL. Other HALs
    use
    > the TPR (Task Priority Register) in the Local APIC. Still others may have
    > their own implementations. So you should always consider the value of
    IRQL
    > in the PCR to be suspect, simply because it may not be in use. A value
    like
    > 0xFF, which corresponds to no actual IRQL should immediately clue you in
    to
    > the fact that the HAL that you're using ignores the value in the PCR.
    >
    > Furthermore, you need to understand what, exactly, the debugger really is
    > and what it really does. (This discussion applies to the debugger that is
    > built into the NT kernel, and not Soft-ICE or an Arium or an ITP that is
    > debugging from outside of the kernel.) The debugger is just a piece of
    code
    > that runs within the kernel, trying to depend on as few services from
    > outside itself as possible. In order to become more deterministic, it
    > disables interrupts whenever it is entered. The NT way of disabling
    > interrupts securely and safely is to raise IRQL to HIGH_LEVEL. Thus,
    > whenever you're in the debugger, IRQL is actually HIGH_LEVEL, regardless
    of
    > what it was when it was executing the code that you were trying to debug.
    >
    > Consequently, looking at the IRQL in the PCR from the debugger should
    always
    > tell you HIGH_LEVEL if the PCR is actually being used to track IRQL. If
    it
    > tells you anything else, it's meaningless. (This assumes that you
    actually
    > found some meaning in asking what the current IRQL is while you're in the
    > debugger, as you knew a-priori it should be HIGH_LEVEL.) This point also
    > applies if you try to read the APIC TPR on a HAL that uses the TPR to
    track
    > IRQL. It should always correspond to HIGH_LEVEL while you're in the
    > debugger.
    >
    > The only way you can reliably find out what IRQL your code was running at
    is
    > to look at where the debugger pushed your IRQL onto the stack when the
    > debugger was entered. Interestingly, this is beyond the end of the stack
    > frame that the debugger itself displays to you, as the debugger assumes
    that
    > you are primarily interested in the code that you wrote, not the debugger
    > itself. So it pretends that the stack ends at your code, not
    automatically
    > displaying the part of the stack that the debugger itself is currently
    > running on.
    >
    > Lastly, the WinDbg team has taken note in recent years that lots of people
    > would be interested in knowing what IRQL their code was running at.
    > Unfortunately, they noticed this first for people who were trying to debug
    > crashdumps and only later (at my begging) extended their code to be able
    to
    > tell you for a running system.
    >
    > So you can know what IRQL code was running at on Windows XP and later when
    > debugging a crashdump by using !irql. If you are debugging Windows Server
    > 2003 or later, !irql will give you an accurate answer even if you're
    > debugging a live system. !irql does exactly what I suggested above. It
    > looks at the IRQL that the debugger itself stored as it was being entered.
    >
    > Please, let us never see another posting saying that IRQL was 0xFF.
    >
    > --
    > Jake Oshins
    > Windows Kernel Group
    >
    > This posting is provided "AS IS" with no warranties, and confers no
    rights.
    >
    >
    >
    >
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA