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
You need to get a crashdump. Do you have your own repro?
>
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
> 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
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
>
> 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.
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, 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
>
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