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

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

bug check 0xa(0, 2, 8, ?)

James_HarperJames_Harper Member Posts: 1,615
I have a crash dump synthesized from a xen core dump. Some information is lost in the core dump, so I am not sure of the crash dump code exactly (can't get to the console right now to confirm).

Is there such a thing as a bug check 0xA with the third parameter as an 8? The docs say it can be 0 or 1. From what I understand that would imply that the access was not read or write but execute, and therefore executing a null address. That would probably explain the stack trace too:

fffff880`02e62c18 fffff800`02e7d1a9 : 00000000`0000000a 00000000`00000000 00000000`00000002 00000000`00000008 : nt!KeBugCheckEx
fffff880`02e62c20 fffff800`02e7be20 : fffffa80`00d4f8e0 00000000`00000000 fffff880`00e317f0 fffff880`009e8180 : nt!KiBugCheckDispatch+0x69
fffff880`02e62d60 00000000`00000000 : fffff800`02e882fc fffff880`009e8180 00000000`00000000 fffff880`00e33fc0 : nt!KiPageFault+0x260

thanks

James

Comments

  • Pavel_APavel_A Member Posts: 2,660
    IIRC value 8 may mean execution of code at the fault address.
    -- pa

    On 10-Dec-2013 13:03, James Harper wrote:
    > I have a crash dump synthesized from a xen core dump. Some information is lost in the core dump, so I am not sure of the crash dump code exactly (can't get to the console right now to confirm).
    >
    > Is there such a thing as a bug check 0xA with the third parameter as an 8? The docs say it can be 0 or 1. From what I understand that would imply that the access was not read or write but execute, and therefore executing a null address. That would probably explain the stack trace too:
    >
    > fffff880`02e62c18 fffff800`02e7d1a9 : 00000000`0000000a 00000000`00000000 00000000`00000002 00000000`00000008 : nt!KeBugCheckEx
    > fffff880`02e62c20 fffff800`02e7be20 : fffffa80`00d4f8e0 00000000`00000000 fffff880`00e317f0 fffff880`009e8180 : nt!KiBugCheckDispatch+0x69
    > fffff880`02e62d60 00000000`00000000 : fffff800`02e882fc fffff880`009e8180 00000000`00000000 fffff880`00e33fc0 : nt!KiPageFault+0x260
    >
    > thanks
    >
    > James
    >
  • James_HarperJames_Harper Member Posts: 1,615
    >
    > IIRC value 8 may mean execution of code at the fault address.
    > -- pa
    >

    That was my assumption based on the same value in other bug check codes. It's not documented for 0xA though...

    James
  • Steve_Prochniak-2Steve_Prochniak-2 Member Posts: 26
    Maybe you registered a bugcheck callback, but the function pointer went to NULL?
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > IIRC value 8 may mean execution of code at the fault address.
    > -- pa
    >
    > On 10-Dec-2013 13:03, James Harper wrote:
    >> I have a crash dump synthesized from a xen core dump. Some information
    >> is lost in the core dump, so I am not sure of the crash dump code
    >> exactly (can't get to the console right now to confirm).
    >>
    >> Is there such a thing as a bug check 0xA with the third parameter as an
    >> 8? The docs say it can be 0 or 1. From what I understand that would
    >> imply that the access was not read or write but execute, and therefore
    >> executing a null address. That would probably explain the stack trace
    >> too:

    It might mean you are running with the no-execute mode on. The general
    purpose of this is to prevent execution of code on the stack, and I don't
    know if it extends to the heap. But if a buffer overrun clobbers a
    return address and sets it to zero, then this might be the kind of error
    that happens, which make me suspect the docs are not-quite-up-to-date
    (and, as we know, that NEVER happens...)

    In this case, the analysis of a bad callback address seems quite credible.
    joe
    >>
    >> fffff880`02e62c18 fffff800`02e7d1a9 : 00000000`0000000a
    >> 00000000`00000000 00000000`00000002 00000000`00000008 : nt!KeBugCheckEx
    >> fffff880`02e62c20 fffff800`02e7be20 : fffffa80`00d4f8e0
    >> 00000000`00000000 fffff880`00e317f0 fffff880`009e8180 :
    >> nt!KiBugCheckDispatch+0x69
    >> fffff880`02e62d60 00000000`00000000 : fffff800`02e882fc
    >> fffff880`009e8180 00000000`00000000 fffff880`00e33fc0 :
    >> nt!KiPageFault+0x260
    >>
    >> thanks
    >>
    >> James
    >>
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
    >
    > OSR is HIRING!! See http://www.osr.com/careers
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer
    >
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
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space