Adding Software Interrupts (on x86 XP

I would like to add a new software interrupt to the Interrupt Descriptor Tab
le (IDT) while executing a device driver in kernel mode.
My problem is that I get a 0xC0000005: STATUS_ACCESS_VIOLATION error when I
access an entry in the IDT. I access the IDT as part of an AddInterrupt() ro
uting I call in HandleStartDevice(). I am baffled.
Thank you.

HandleStartDevice() {

AddInterrupt()
}

/* Interrupt to be added */
#define ADDINT 0x22

/* sidt instruction stores the base and limit of IDTR in this format */
typedef struct idtr {
short Limit; // 16 bits
unsigned int Base; // 32 bits
} Idtr_t, *PIdtr_t;

/* Decriptor Entry corresponding to interrupt gate */
typedef struct idtentry { // is 8 bytes bytes : should be 8 bytes
unsigned short OffsetLow; // 2 bytes : 2 bytes ok
unsigned short Selector; // 2 bytes : 2 bytes ok
unsigned char Reserved; // 8 bits
unsigned char Always1:3; // 3 bits
unsigned char Type:1; // 1 bits
unsigned char Always0:1; // 1 bits
unsigned char Dpl:2; // 2 bits
unsigned char Present:1; // 1 bits
unsigned short OffsetHigh; // 2 bytes
} IdtEntry_t, *PIdtEntry_t;

/* Old Idt Entry */
IdtEntry_t OldIdtEntry;

/* Buffer to store result of sidt instruction */
char buffer[6]; // 48 bits: 16 bits LIMIT, 32 bits BASE

/* Pointer to structure to identify the limit and base of IDTR*/
PIdtr_t Idtr= (PIdtr_t) buffer;

NTSTATUS AddInterrupt() {
PIdtEntry_t IdtEntry;
/* Get the Base and Limit of IDT table */
_asm sidt buffer
IdtEntry=(PIdtEntry_t)Idtr->Base;

if ((IdtEntry[ADDINT].OffsetLow!=0) || (IdtEntry[ADDINT].OffsetHigh!=0))
return STATUS_UNSUCCESSFUL;
–> // 0xC0000005: STATUS_ACCESS_VIOLATION


}

xxxxx@hotmail.com wrote:

I would like to add a new software interrupt to the Interrupt Descriptor Tab
le (IDT) while executing a device driver in kernel mode.

Fascinating! What leads you to believe this will work? Are you 100%
confident that the operating system will not reload the IDT from its
internal tables on a task switch?

Are you hoping that this will allow you to catch an “INT 22h” from
user-mode? I think you are dreaming.

My problem is that I get a 0xC0000005: STATUS_ACCESS_VIOLATION error when I
access an entry in the IDT. I access the IDT as part of an AddInterrupt() ro
uting I call in HandleStartDevice(). I am baffled.

Have you stepped through this in a debugger, so that you can be
confident that the numbers you are getting are reasonable and that the
address arithmetic is correct?

Are you sure the IDT page is marked writable in the page tables?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

RNKAYAB:

As Tim pointed out, there are a lot of potential issues here, and he
just touched the surface. In particular, what he did not discuss was
the tremendous amount of work that has gone in to breaking this sort of
thing on x64 platforms (which, clearly, doesn’t apply to you) and Vista
overall. Why do you want to do this? I am not asking you to justify
it; I don’t care. It is just that, having spent quite a while
examining, among other things, the work that has gone in to preventing
this sort of thing, I can’t think of any reason that could even begin to
justify the work that will be required if you wish to get this to even
have a remote shot of working on more than whatever you are using now.
If you must do this (and those situations certainly can and do occur),
then my guess would be to start with Tim’s last response: the page is
likely non-writeable.

This code looks like it might be based on that in “Undocumented
Windows.” If it is, that book is, frankly, not very accurate or
complete, although the chapter in question is its best, not all that
bad, and, as far as I know the only thing like it. So, if you’re
already using it, beware; that being said, if you are going to go
forward with this, you might want to get a hold of it, and then beware.

mm

>> xxxxx@hotmail.com 2006-10-09 20:02 >>>
I would like to add a new software interrupt to the Interrupt
Descriptor Tab
le (IDT) while executing a device driver in kernel mode.
My problem is that I get a 0xC0000005: STATUS_ACCESS_VIOLATION error
when I
access an entry in the IDT. I access the IDT as part of an
AddInterrupt() ro
uting I call in HandleStartDevice(). I am baffled.
Thank you.

HandleStartDevice() {

AddInterrupt()
}

/* Interrupt to be added */
#define ADDINT 0x22

/* sidt instruction stores the base and limit of IDTR in this format */

typedef struct idtr {
short Limit; // 16 bits
unsigned int Base; // 32 bits
} Idtr_t, *PIdtr_t;

/* Decriptor Entry corresponding to interrupt gate */
typedef struct idtentry { // is 8 bytes bytes : should be 8 bytes
unsigned short OffsetLow; // 2 bytes : 2 bytes ok
unsigned short Selector; // 2 bytes : 2 bytes ok
unsigned char Reserved; // 8 bits
unsigned char Always1:3; // 3 bits
unsigned char Type:1; // 1 bits
unsigned char Always0:1; // 1 bits
unsigned char Dpl:2; // 2 bits
unsigned char Present:1; // 1 bits
unsigned short OffsetHigh; // 2 bytes
} IdtEntry_t, *PIdtEntry_t;

/* Old Idt Entry */
IdtEntry_t OldIdtEntry;

/* Buffer to store result of sidt instruction */
char buffer[6]; // 48 bits: 16 bits LIMIT, 32 bits BASE

/* Pointer to structure to identify the limit and base of IDTR*/
PIdtr_t Idtr= (PIdtr_t) buffer;

NTSTATUS AddInterrupt() {
PIdtEntry_t IdtEntry;
/* Get the Base and Limit of IDT table */
_asm sidt buffer
IdtEntry=(PIdtEntry_t)Idtr->Base;

if ((IdtEntry[ADDINT].OffsetLow!=0) ||
(IdtEntry[ADDINT].OffsetHigh!=0))
return STATUS_UNSUCCESSFUL;
–> // 0xC0000005: STATUS_ACCESS_VIOLATION


}


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Hi Tim and MM:

I am basing this on the article “Adding New Software Interrupts in Windows NT” at
http://www.windowsitlibrary.com/Content/356/10/1.html. I would like to temporary add some software interrupts in a dummy device driver to be used in kernel mode only and only while the driver is running. I have several ISR’s in my driver of different priorities that perform short numeric computation and would like to test consistency of results given different points of interruption. To guarantee an interrupt happens exactly where I want, I was planning to map the ISR to software interrupts and use the INT instruction at interesting possible interruption points. This way I don’t face delay hardware interrupts have. Can you guys suggest a better way to do this?
Thank you.

Yep, that is from Undocunented Windows NT, it was incorrect with Windows
NT, let alone any real OS. When the book first came out I experimented
with this, and it was highly dependant on the HAL whether it worked or
crashed. Forget this garbage.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

wrote in message news:xxxxx@ntdev…
> Hi Tim and MM:
>
> I am basing this on the article “Adding New Software Interrupts in
> Windows NT” at
> http://www.windowsitlibrary.com/Content/356/10/1.html. I would like to
> temporary add some software interrupts in a dummy device driver to be
> used in kernel mode only and only while the driver is running. I have
> several ISR’s in my driver of different priorities that perform short
> numeric computation and would like to test consistency of results given
> different points of interruption. To guarantee an interrupt happens
> exactly where I want, I was planning to map the ISR to software
> interrupts and use the INT instruction at interesting possible
> interruption points. This way I don’t face delay hardware interrupts
> have. Can you guys suggest a better way to do this?
> Thank you.
>
>

The article indeed comes from “Undocumented Windows NT”.

I want to use real interrupts to test is as I am interested in the state save on the stack. I ultimately want to self-restart interrupted handlers: if a higher-priority handler interrupts a lower-priority handler in my driver, code in the higher-priority handler modifies the stack so that afterr IRET , the lower-priority handler starts executing from its beginning.

Write your own operating system, this is bogus. If you need a capability
like this have your ISR check the hardware for interrupt flags before
exiting, and process those.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

wrote in message news:xxxxx@ntdev…
> The article indeed comes from “Undocumented Windows NT”.
>
> I want to use real interrupts to test is as I am interested in the state
> save on the stack. I ultimately want to self-restart interrupted
> handlers: if a higher-priority handler interrupts a lower-priority
> handler in my driver, code in the higher-priority handler modifies the
> stack so that afterr IRET , the lower-priority handler starts executing
> from its beginning.
>
>

Tim and mm:

Have you stepped through this in a debugger, so that you can be
confident that the numbers you are getting are reasonable and that the
address arithmetic is correct?
Roumen: Yes, the starting address of the IDT and its size are correct (256 entries). I crash even when I read the first entry, that is IdtEntry[0].OffsetLow.

Are you sure the IDT page is marked writable in the page tables?
Roumen: Should it be writable at that point? The crash is caused by *reading* IdtEntry.OffsetLow

Don Burn:

If you need a capability
like this have your ISR check the hardware for interrupt flags before
exiting, and process those.
Roumen: Would you expand on that point? How would I ultimatedly restart the interrupted lower-level handler?

Thank you.

As for the most part indicated by what I wrote earlier, and for the most
part in agreement with Don, that book does, indeed, suck as much as it
wants to, for the most part. My recommendation was that, should you
decide to punish yourself by pursing this, good, bad or otherwise, it is
the only source that I know of, and at least that particular chapter is
essentially correct. What I did not make explicit, and its important,
is what Don said - NT. I mentioned Vista, but that really doesn’t cover
all the problems with this.

THAT BEING SAID:

Are you saying that you trying to write code involving two
self-prioritizing interrupts, that do so by modifying each other’s
respective state? I’m not doubting your intentions or even necessarily
need, but if I understand you correctly and that this what you are
really trying to do, this is, without question, an insane path to
follow. You sound like you’re a little confused on to proceed. I’m not
trying to just be unkind, but let me clear - you do not want to do this.
If nothing else, there exists the issue of something you are not
planning on occuring between (1) and (2), which, coincidentally, go by
the name of interrupt. The absolute nail in the coffin here is that all
of this, unless you have something like an ECM-50 or some other hardware
debugger and a lot of time, or are uncommonly good at guessing, this
will be completely non-debuggable.

mm

>> xxxxx@hotmail.com 2006-10-10 12:31 >>>
The article indeed comes from “Undocumented Windows NT”.

I want to use real interrupts to test is as I am interested in the
state save on the stack. I ultimately want to self-restart interrupted
handlers: if a higher-priority handler interrupts a lower-priority
handler in my driver, code in the higher-priority handler modifies the
stack so that afterr IRET , the lower-priority handler starts executing
from its beginning.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> As for the most part indicated by what I wrote earlier, and for the most
> part in agreement with Don, that book does, indeed, suck as much as it
> wants to, for the most part. My recommendation was that, should you
> decide to punish yourself by pursing this, good, bad or otherwise, it is
> the only source that I know of, and at least that particular chapter is
> essentially correct. What I did not make explicit, and its important,
> is what Don said - NT. I mentioned Vista, but that really doesn’t cover
> all the problems with this.

Actually, Windows NT 4.0 no service pack Uni-processor HAL withouth ACPI!!!
Anything else is probably bogus, and since that is an unlikely
configuration today, you are hosed. If you are that concerned about an
interrupt of your interrupt, make sure you at the end of your ISR re-read
the hardware indicators that would cause an interrupt, and if there is
additional work perform the actions you need to do this.

If your hardware is bogus enough not to allow you to see the indications
you have a problem. Trying to mess with Windows interrupt handling outside
of what is normal for an ISR is a request to be added to the “Hall of
Flame” where your name is cursed by the rest of the kernel developers and
every firm you work for is tainted.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

xxxxx@hotmail.com wrote:

The article indeed comes from “Undocumented Windows NT”.

I want to use real interrupts to test is as I am interested in the state save on the stack. I ultimately want to self-restart interrupted handlers: if a higher-priority handler interrupts a lower-priority handler in my driver, code in the higher-priority handler modifies the stack so that afterr IRET , the lower-priority handler starts executing from its beginning.

Nope, that’s not going to work. Assuming you got this to work, remember
that your injected interrupt will jump IMMEDIATELY to your interrupt
handler, whereas interrupts connected through IoConnectInterrupt are
going to pass through several layers of HAL and kernel before they get
to your handler. The stack environment will not be clean – you won’t
be able to find the address of the interrupted ISR.

Are your ISRs really time-consuming enough that it is possible for you
have nested interrupts? Remember that a 3.3GHz CPU can execute 100
instructions between PCI bus cycles, and you can’t have two interrupts
arrive any closer together than that.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

mm:

Are you saying that you trying to write code involving two
self-prioritizing interrupts, that do so by modifying each other’s
respective state? …
If nothing else, there exists the issue of something you are not
planning on occuring between (1) and (2), which, coincidentally, go by
the name of interrupt.

Correct. The interrupts are of a fixed priority. Suppose you have only two interrupts (1) and (2), and no other interrupts can occur. Can the higher priority interrupt (2) modify the saved state in the stack for (1) and specifically the stored CS counter to point to the beginning of (1)?

Agreed.

>> xxxxx@acm.org 2006-10-10 12:56 >>>

“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> As for the most part indicated by what I wrote earlier, and for the
most
> part in agreement with Don, that book does, indeed, suck as much as
it
> wants to, for the most part. My recommendation was that, should you
> decide to punish yourself by pursing this, good, bad or otherwise, it
is
> the only source that I know of, and at least that particular chapter
is
> essentially correct. What I did not make explicit, and its
important,
> is what Don said - NT. I mentioned Vista, but that really doesn’t
cover
> all the problems with this.

Actually, Windows NT 4.0 no service pack Uni-processor HAL withouth
ACPI!!!
Anything else is probably bogus, and since that is an unlikely
configuration today, you are hosed. If you are that concerned about an

interrupt of your interrupt, make sure you at the end of your ISR
re-read
the hardware indicators that would cause an interrupt, and if there is

additional work perform the actions you need to do this.

If your hardware is bogus enough not to allow you to see the
indications
you have a problem. Trying to mess with Windows interrupt handling
outside
of what is normal for an ISR is a request to be added to the “Hall of
Flame” where your name is cursed by the rest of the kernel developers
and
every firm you work for is tainted.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Licence the HAL Kit and write your own cutsom HAL

Dan

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 10, 2006 8:05 PM
Subject: RE:[ntdev] Adding Software Interrupts (on x86 XP

> mm:
>> Are you saying that you trying to write code involving two
>> self-prioritizing interrupts, that do so by modifying each other’s
>> respective state? …
>> If nothing else, there exists the issue of something you are not
>> planning on occuring between (1) and (2), which, coincidentally, go by
>> the name of interrupt.
>
> Correct. The interrupts are of a fixed priority. Suppose you have only two
> interrupts (1) and (2), and no other interrupts can occur. Can the higher
> priority interrupt (2) modify the saved state in the stack for (1) and
> specifically the stored CS counter to point to the beginning of (1)?
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

Don:

If you are that concerned about an
interrupt of your interrupt, make sure you at the end of your ISR re-read
the hardware indicators that would cause an interrupt
Roumen: Would you expand?

Tim:

Assuming you got this to work, remember
that your injected interrupt will jump IMMEDIATELY to your interrupt
handler…
ROUMEN: I don’t see this. In the high-priority interrupt, I only modified the stack saved state of the low-priority interrupt. If some other medium-priority interrupt occurs while the high-p is executing and becomes pending, the medium-priority interrupt will run next. The key is: Nothing gets saved on the stack after the low-p frame, while the high-p is running (on a single CPU).

your ISRs really time-consuming enough that it is possible for you
have nested interrupts?
Roumen: Sure, assume some computation requiring 300 CPU cycles.

Tim just mentioned the specifics of why not. My response was not that
detailed, and really only commented on the fact there is a tremendous
amount of stuff going on that you have way of really controlling, or
even speculating about at all reliably without spending a lot of time
with a hardware debugger, or having access to the source code. It is
not that what you are considering could never work under ideal
circumstances, it is that you can’t create those circumstances, ensure
that they do not get changed on you, and, in particular, when it does
not work as anything doesn’t at times along the way during development,
this one would absolutely suck to debug, even with the appropriate
hardware; without it, whether it is even possible would depend on what
you end up doing, and how things go awry. The outrageously difficult
problem that borders on unresolvable without something like source code
or a whole lot of time (not even getting in to what Tim said, which is
just a killer) is that whenever this situation occurs, you are never
going to be able to learn anything from it, because, best case scenario,
you’re going to cause a hardware panic or something else that ultimately
ends up as an NMI, of which WinDbg is not very fond at any time, but
particularly so during a nested interrupt (unless you’re going to
disable that at the APIC, for all processors, and god knows what would
happen then; I guess it would just hang).

I really can only speak authoritatively on one subject here, and,
unfortunately, it is how amazingly difficult things are when you screw
with interrupt handlers in non-standard ways. Over time, I’ve had to
replace in very, very non-standard ways (as an explicit requirement in
each case of very, very non-standard projects) all of the interrupts
that most directly relate to debugging (1, 3 & 2D), as well as that for
the NMI itself. The handlers themselves are not the problem; the NMI,
for example, was actually reasonably simple. Not a one of them (and 2D
was not a picnic) is as dependent on the system as what you are
attempting and you have no obvious, immediate control over the rest of
the environment of Windows, and learning that on the fly when you are
going to cripple debugging (at least without some serious capital
investment) is brutal. What I did eventually worked, but none of them
presented the issue that Mark described, and they were also essentially
the whole point of the research. I guess all I’m really saying is that
you should seek alternatives; NT, depsite some very contrived articles
by the Gartner Group a long time ago, is not by any reasonable
definition a real time os. A great deal of effort went in to preventing
the real time scenario from occuring, mostly by at least saying that
everything is premptable.

mm

>> xxxxx@hotmail.com 2006-10-10 13:05 >>>
mm:
Are you saying that you trying to write code involving two
self-prioritizing interrupts, that do so by modifying each other’s
respective state? …
If nothing else, there exists the issue of something you are not
planning on occuring between (1) and (2), which, coincidentally, go
by
the name of interrupt.

Correct. The interrupts are of a fixed priority. Suppose you have only
two interrupts (1) and (2), and no other interrupts can occur. Can the
higher priority interrupt (2) modify the saved state in the stack for
(1) and specifically the stored CS counter to point to the beginning of
(1)?


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

This is the best idea by far on how to proceed.

>> xxxxx@rdsor.ro 2006-10-10 13:17 >>>
Licence the HAL Kit and write your own cutsom HAL

Dan

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 10, 2006 8:05 PM
Subject: RE:[ntdev] Adding Software Interrupts (on x86 XP

> mm:
>> Are you saying that you trying to write code involving two
>> self-prioritizing interrupts, that do so by modifying each other’s
>> respective state? …
>> If nothing else, there exists the issue of something you are not
>> planning on occuring between (1) and (2), which, coincidentally, go
by
>> the name of interrupt.
>
> Correct. The interrupts are of a fixed priority. Suppose you have
only two
> interrupts (1) and (2), and no other interrupts can occur. Can the
higher
> priority interrupt (2) modify the saved state in the stack for (1)
and
> specifically the stored CS counter to point to the beginning of
(1)?
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

>>The outrageously difficult

>problem that borders on unresolvable without something like source code

You make it sound soo … difficult. When acutaly aint quite so bad.
Actualy writting a Numega NTice debugger clone from the point of view of
handling interrupts is way simplier than it seems.

----- Original Message -----
From: “Martin O’Brien”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 10, 2006 8:46 PM
Subject: RE:[ntdev] Adding Software Interrupts (on x86 XP

> Tim just mentioned the specifics of why not. My response was not that
> detailed, and really only commented on the fact there is a tremendous
> amount of stuff going on that you have way of really controlling, or
> even speculating about at all reliably without spending a lot of time
> with a hardware debugger, or having access to the source code. It is
> not that what you are considering could never work under ideal
> circumstances, it is that you can’t create those circumstances, ensure
> that they do not get changed on you, and, in particular, when it does
> not work as anything doesn’t at times along the way during development,
> this one would absolutely suck to debug, even with the appropriate
> hardware; without it, whether it is even possible would depend on what
> you end up doing, and how things go awry. The outrageously difficult
> problem that borders on unresolvable without something like source code
> or a whole lot of time (not even getting in to what Tim said, which is
> just a killer) is that whenever this situation occurs, you are never
> going to be able to learn anything from it, because, best case scenario,
> you’re going to cause a hardware panic or something else that ultimately
> ends up as an NMI, of which WinDbg is not very fond at any time, but
> particularly so during a nested interrupt (unless you’re going to
> disable that at the APIC, for all processors, and god knows what would
> happen then; I guess it would just hang).
>
> I really can only speak authoritatively on one subject here, and,
> unfortunately, it is how amazingly difficult things are when you screw
> with interrupt handlers in non-standard ways. Over time, I’ve had to
> replace in very, very non-standard ways (as an explicit requirement in
> each case of very, very non-standard projects) all of the interrupts
> that most directly relate to debugging (1, 3 & 2D), as well as that for
> the NMI itself. The handlers themselves are not the problem; the NMI,
> for example, was actually reasonably simple. Not a one of them (and 2D
> was not a picnic) is as dependent on the system as what you are
> attempting and you have no obvious, immediate control over the rest of
> the environment of Windows, and learning that on the fly when you are
> going to cripple debugging (at least without some serious capital
> investment) is brutal. What I did eventually worked, but none of them
> presented the issue that Mark described, and they were also essentially
> the whole point of the research. I guess all I’m really saying is that
> you should seek alternatives; NT, depsite some very contrived articles
> by the Gartner Group a long time ago, is not by any reasonable
> definition a real time os. A great deal of effort went in to preventing
> the real time scenario from occuring, mostly by at least saying that
> everything is premptable.
>
> mm
>
>>>> xxxxx@hotmail.com 2006-10-10 13:05 >>>
> mm:
>> Are you saying that you trying to write code involving two
>> self-prioritizing interrupts, that do so by modifying each other’s
>> respective state? …
>> If nothing else, there exists the issue of something you are not
>> planning on occuring between (1) and (2), which, coincidentally, go
> by
>> the name of interrupt.
>
> Correct. The interrupts are of a fixed priority. Suppose you have only
> two interrupts (1) and (2), and no other interrupts can occur. Can the
> higher priority interrupt (2) modify the saved state in the stack for
> (1) and specifically the stored CS counter to point to the beginning of
> (1)?
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

Well good luck on the ‘license the hal kit’ part.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Tuesday, October 10, 2006 1:48 PM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] Adding Software Interrupts (on x86 XP

This is the best idea by far on how to proceed.

>> xxxxx@rdsor.ro 2006-10-10 13:17 >>>
Licence the HAL Kit and write your own cutsom HAL

Dan

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 10, 2006 8:05 PM
Subject: RE:[ntdev] Adding Software Interrupts (on x86 XP

> mm:
>> Are you saying that you trying to write code involving two
>> self-prioritizing interrupts, that do so by modifying each other’s
>> respective state? …
>> If nothing else, there exists the issue of something you are not
>> planning on occuring between (1) and (2), which, coincidentally, go
by
>> the name of interrupt.
>
> Correct. The interrupts are of a fixed priority. Suppose you have
only two
> interrupts (1) and (2), and no other interrupts can occur. Can the
higher
> priority interrupt (2) modify the saved state in the stack for (1)
and
> specifically the stored CS counter to point to the beginning of
(1)?
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

I missed something. Why are you modifying CS (that is, not EIP)?

>> xxxxx@evitechnology.com 2006-10-10 13:46 >>>
Tim just mentioned the specifics of why not. My response was not that
detailed, and really only commented on the fact there is a tremendous
amount of stuff going on that you have way of really controlling, or
even speculating about at all reliably without spending a lot of time
with a hardware debugger, or having access to the source code. It is
not that what you are considering could never work under ideal
circumstances, it is that you can’t create those circumstances, ensure
that they do not get changed on you, and, in particular, when it does
not work as anything doesn’t at times along the way during
development,
this one would absolutely suck to debug, even with the appropriate
hardware; without it, whether it is even possible would depend on what
you end up doing, and how things go awry. The outrageously difficult
problem that borders on unresolvable without something like source
code
or a whole lot of time (not even getting in to what Tim said, which is
just a killer) is that whenever this situation occurs, you are never
going to be able to learn anything from it, because, best case
scenario,
you’re going to cause a hardware panic or something else that
ultimately
ends up as an NMI, of which WinDbg is not very fond at any time, but
particularly so during a nested interrupt (unless you’re going to
disable that at the APIC, for all processors, and god knows what would
happen then; I guess it would just hang).

I really can only speak authoritatively on one subject here, and,
unfortunately, it is how amazingly difficult things are when you screw
with interrupt handlers in non-standard ways. Over time, I’ve had to
replace in very, very non-standard ways (as an explicit requirement in
each case of very, very non-standard projects) all of the interrupts
that most directly relate to debugging (1, 3 & 2D), as well as that
for
the NMI itself. The handlers themselves are not the problem; the NMI,
for example, was actually reasonably simple. Not a one of them (and
2D
was not a picnic) is as dependent on the system as what you are
attempting and you have no obvious, immediate control over the rest of
the environment of Windows, and learning that on the fly when you are
going to cripple debugging (at least without some serious capital
investment) is brutal. What I did eventually worked, but none of them
presented the issue that Mark described, and they were also
essentially
the whole point of the research. I guess all I’m really saying is
that
you should seek alternatives; NT, depsite some very contrived articles
by the Gartner Group a long time ago, is not by any reasonable
definition a real time os. A great deal of effort went in to
preventing
the real time scenario from occuring, mostly by at least saying that
everything is premptable.

mm

>> xxxxx@hotmail.com 2006-10-10 13:05 >>>
mm:
Are you saying that you trying to write code involving two
self-prioritizing interrupts, that do so by modifying each other’s
respective state? …
If nothing else, there exists the issue of something you are not
planning on occuring between (1) and (2), which, coincidentally, go
by
the name of interrupt.

Correct. The interrupts are of a fixed priority. Suppose you have only
two interrupts (1) and (2), and no other interrupts can occur. Can the
higher priority interrupt (2) modify the saved state in the stack for
(1) and specifically the stored CS counter to point to the beginning
of
(1)?


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer