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

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

BSoD 0x7E (0xC0000096, , , )

James_HarperJames_Harper Member Posts: 1,615
When run on a physical machine, a user is reporting that my xen pv drivers are giving a bug check 0x7E with a parameter of 0xC0000096, which equates to STATUS_PRIVILEGED_INSTRUCTION. I can't get my hands on a crash dump or anything at this time, but looking at my code I assume the crash is occurring when making __cpuid() calls, and that maybe I need to wrap those calls up in an exception handler. This assumption is based on the fact that if the __cpuid() calls don't find a reference to running on a Xen VM then the driver doesn't do much else.

I've never needed to use exception handling before, and there doesn't seem to be a lot of documentation in the DDK, apart from a referral to the SDK, but in the SDK all the examples I can find appear to prefix the keywords with __, so I'm wondering if kernel SEH obeys the same rules...

What would be the syntax to catch this exception? Is it as simple as:

try {
__cpuid(...);
} except (EXCEPTION_EXECUTE_HANDLER) {
return some_error_indicating_no_support;
}

?

Thanks

James

Comments

  • Alex_GrigAlex_Grig Member Posts: 3,238
    You need to get a crashdump. Do you have your own repro?
  • James_HarperJames_Harper Member Posts: 1,615
    >
    > You need to get a crashdump. Do you have your own repro?
    >

    Not until Monday. I was just asking if that's the correct way to catch such an exception (and if that particular exception can be caught at all).

    As usual though, after sitting on that email all morning, right after I hit send I noticed an off-by-one error in my code, which is probably the cause.

    James
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > When run on a physical machine, a user is reporting that my xen pv drivers
    > are giving a bug check 0x7E with a parameter of 0xC0000096, which equates
    > to STATUS_PRIVILEGED_INSTRUCTION. I can't get my hands on a crash dump or
    > anything at this time, but looking at my code I assume the crash is
    > occurring when making __cpuid() calls, and that maybe I need to wrap those
    > calls up in an exception handler. This assumption is based on the fact
    > that if the __cpuid() calls don't find a reference to running on a Xen VM
    > then the driver doesn't do much else.
    >
    > I've never needed to use exception handling before, and there doesn't seem
    > to be a lot of documentation in the DDK, apart from a referral to the SDK,
    > but in the SDK all the examples I can find appear to prefix the keywords
    > with __, so I'm wondering if kernel SEH obeys the same rules...
    >
    SEH was added as an extension to C primarily to support kernel coding.

    Note that __try/__except are used for SEH, and try/catch for C++
    exceptions. So I don't understand your concern about __ prefixinng.
    Before the new C99 standard, only one undeline was used, but the new
    standard demands two undelines for vendor-specific extensions.

    CPUID should be supported, so if it doesn't work, the hypervisor is
    probably doing something bad.
    joe
    > What would be the syntax to catch this exception? Is it as simple as:
    >
    > try {
    > __cpuid(...);
    > } except (EXCEPTION_EXECUTE_HANDLER) {
    > return some_error_indicating_no_support;
    > }
    >
    > ?
    >
    > 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
    >
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,307
    His problem is that it is failing only in a non-virtual environment. cpuid
    is fine in the kernel and shouldn't need an exception handler.

    Mark Roddy


    On Sun, Jan 12, 2014 at 12:41 AM, wrote:

    > > When run on a physical machine, a user is reporting that my xen pv
    > drivers
    > > are giving a bug check 0x7E with a parameter of 0xC0000096, which equates
    > > to STATUS_PRIVILEGED_INSTRUCTION. I can't get my hands on a crash dump or
    > > anything at this time, but looking at my code I assume the crash is
    > > occurring when making __cpuid() calls, and that maybe I need to wrap
    > those
    > > calls up in an exception handler. This assumption is based on the fact
    > > that if the __cpuid() calls don't find a reference to running on a Xen VM
    > > then the driver doesn't do much else.
    > >
    > > I've never needed to use exception handling before, and there doesn't
    > seem
    > > to be a lot of documentation in the DDK, apart from a referral to the
    > SDK,
    > > but in the SDK all the examples I can find appear to prefix the keywords
    > > with __, so I'm wondering if kernel SEH obeys the same rules...
    > >
    > SEH was added as an extension to C primarily to support kernel coding.
    >
    > Note that __try/__except are used for SEH, and try/catch for C++
    > exceptions. So I don't understand your concern about __ prefixinng.
    > Before the new C99 standard, only one undeline was used, but the new
    > standard demands two undelines for vendor-specific extensions.
    >
    > CPUID should be supported, so if it doesn't work, the hypervisor is
    > probably doing something bad.
    > joe
    > > What would be the syntax to catch this exception? Is it as simple as:
    > >
    > > try {
    > > __cpuid(...);
    > > } except (EXCEPTION_EXECUTE_HANDLER) {
    > > return some_error_indicating_no_support;
    > > }
    > >
    > > ?
    > >
    > > 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
    > >
    >
    >
    >
    > ---
    > 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
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > I was just asking if that's the correct way to catch
    > such an exception (and if that particular exception
    > can be caught at all).

    Yes, the '__try{}__except(){}' is a correct syntax for dealing with SEH at 'C'.
    But exceptions raised by a hardware condition when executing at the kernel mode (e.g. zero-division, invalid op-code or access violation at some address) do not spawn the exception dispatching process obligatory.

    AFAIK at kernel mode:
    zero-division - a bound trap;
    invalid op-code - a bound trap;
    access violation at a kernel mode address (any IRQL) - a bound trap;
    access violation at a user mode address (for IRQL>PASSIVE_LEVEL) - a bound trap;
    access violation at a user mode address (for IRQL==PASSIVE_LEVEL) - SEH-dispatching is involved;
    (a 'bound trap' means here just the corresponding bsod, without a SEH-dispatching).

    While all the above-mentioned h/w-exceptions are SEH-dispatchable at an user-mode process.
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    AFAIK, CPUID is not a privileged instruction; you can use it at app-level.
    The OP reported that there was an off-by-1 error elsewhere, which is why
    doing !analyze -v is so important--but the OP had no crash dumps to work
    with. So, if the EIP was pointing to CPUID (which could be determined
    from a link map) it would mean the instruction preceding it failed.
    Analyzing a crash in the absence of any real data is challenging.
    joe


    > His problem is that it is failing only in a non-virtual environment. cpuid
    > is fine in the kernel and shouldn't need an exception handler.
    >
    > Mark Roddy
    >
    >
    > On Sun, Jan 12, 2014 at 12:41 AM, <xxxxx@flounder.com> wrote:
    >
    >> > When run on a physical machine, a user is reporting that my xen pv
    >> drivers
    >> > are giving a bug check 0x7E with a parameter of 0xC0000096, which
    >> equates
    >> > to STATUS_PRIVILEGED_INSTRUCTION. I can't get my hands on a crash dump
    >> or
    >> > anything at this time, but looking at my code I assume the crash is
    >> > occurring when making __cpuid() calls, and that maybe I need to wrap
    >> those
    >> > calls up in an exception handler. This assumption is based on the fact
    >> > that if the __cpuid() calls don't find a reference to running on a Xen
    >> VM
    >> > then the driver doesn't do much else.
    >> >
    >> > I've never needed to use exception handling before, and there doesn't
    >> seem
    >> > to be a lot of documentation in the DDK, apart from a referral to the
    >> SDK,
    >> > but in the SDK all the examples I can find appear to prefix the
    >> keywords
    >> > with __, so I'm wondering if kernel SEH obeys the same rules...
    >> >
    >> SEH was added as an extension to C primarily to support kernel coding.
    >>
    >> Note that __try/__except are used for SEH, and try/catch for C++
    >> exceptions. So I don't understand your concern about __ prefixinng.
    >> Before the new C99 standard, only one undeline was used, but the new
    >> standard demands two undelines for vendor-specific extensions.
    >>
    >> CPUID should be supported, so if it doesn't work, the hypervisor is
    >> probably doing something bad.
    >> joe
    >> > What would be the syntax to catch this exception? Is it as simple as:
    >> >
    >> > try {
    >> > __cpuid(...);
    >> > } except (EXCEPTION_EXECUTE_HANDLER) {
    >> > return some_error_indicating_no_support;
    >> > }
    >> >
    >> > ?
    >> >
    >> > 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
    >> >
    >>
    >>
    >>
    >> ---
    >> 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
    >>
    >
    > ---
    > 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
  • James_HarperJames_Harper Member Posts: 1,615
    >
    > AFAIK, CPUID is not a privileged instruction; you can use it at app-level.
    > The OP reported that there was an off-by-1 error elsewhere, which is why
    > doing !analyze -v is so important--but the OP had no crash dumps to work
    > with. So, if the EIP was pointing to CPUID (which could be determined
    > from a link map) it would mean the instruction preceding it failed.
    > Analyzing a crash in the absence of any real data is challenging.

    But sometimes it's all we have to go on.

    The code does:

    . search cpuid space for xen signature
    . get xen version from another cpuid call
    . wrmsr to trigger the hypercall setup

    The off-by-one was in the 'if not found' at the end of the search, and meant that when the search failed to find anything, the wrmsr was called anyway, which is what is triggering the BSoD.

    Having fixed the search call, the privileged instruction should only be called when I know it is permitted, so I shouldn't need exception handling after all.

    Thanks

    James
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