After writing some test code and reading the Intel reference manuals, the
issue seems more clear and more confusing.
Interrupts are disabled on the following exceptions: int 1, int 3 and
BOUNDS. There is no reason to assume that your exception handler will
restart interrupts by default; you will need to restart them yourself.
Not quite what the solution is here. Do you simply issue an __asm sti
instruction? Are we sure the interrupts were enabled before the exception
occured? Remember the old trick:
pushf
cli
;; do some stuff
popf
Since we do not knw the state of the flags prior to the exception being
called, I am not sure what to recommend. Can we assume interrupts were
enabled prior to the exception occuring? Int 1 and Int 3 are non-maskable.
Another interesting thing I found using SoftIce (all I tested with so far):
If I execute the following line:
__try {DbgBreakPoint()} __except(EXCEPTION_CONTINUE_SEARCH) {}
I get a BSOD, not a debugger break point like I would have expected.
Jamey
----- Original Message -----
From: “Prokash Sinha”
To: “Windows System Software Devs Interest List”
Sent: Sunday, February 13, 2005 9:00 AM
Subject: Re: [ntdev] No memory.dmp mystery II
> I’m much less familiar with design issues of these interrupt vector
> assignment. But what I still recall from my past work/search/findings is
> that they were not needed, sort of stubbing. And one can enhance the
> functionality ( if desired on an experimental systems) just slapping a
> handler. BTW, other oses (Unix family) usually leaves couple slots open
> like
> this if I recall.
>
> -pro
> ----- Original Message -----
> From: “Alberto Moreira”
> To: “Windows System Software Devs Interest List”
> Sent: Sunday, February 13, 2005 6:10 AM
> Subject: Re: [ntdev] No memory.dmp mystery II
>
>
>> One question that arises is, why the Task Gates ? The vectors
>> are NMI, Double Fault and Machine Check. The other point is, one
>> would have expected that the IRQL design might be better served
>> with Trap Gates, although of course that makes it harder to
>> program the ISRs. Another question is, vectors 0x20 to 0x29 are
>> reported as “reserved”, and the ISR offset is set to zero. I
>> wonder why ?
>>
>> Alberto.
>>
>>
>> ----- Original Message -----
>> From: “Jamey Kirby”
>> To: “Windows System Software Devs Interest List”
>>
>> Sent: Saturday, February 12, 2005 8:25 PM
>> Subject: Re: [ntdev] No memory.dmp mystery II
>>
>>
>> > This is what I have read too 
>> >
>> > Jamey
>> > ----- Original Message -----
>> > From: “Alberto Moreira”
>> > To: “Windows System Software Devs Interest List”
>> >
>> > Sent: Saturday, February 12, 2005 2:30 PM
>> > Subject: Re: [ntdev] No memory.dmp mystery II
>> >
>> >
>> >>A quick check with SoftICE shows that while int 0x2, 0x8 and
>> >>0x12 are serviced by Task Gates, the rest of the IDT entries
>> >>between 0x01 and 0xff, with a few exceptions, are Interrupt
>> >>Gates. If you read the Intel Pentium book, you’ll find out
>> >>that ISRs that are serviced by Interrupt Gates get control
>> >>with the Interrupt Flag cleared. So, the Windows interrupt
>> >>routines which get control before the Driver’s ISR have the
>> >>choice of turning interrupts on or leaving them off.
>> >>
>> >> Alberto.
>> >>
>> >>
>> >> ----- Original Message -----
>> >> From: “Jamey Kirby”
>> >> To: “Windows System Software Devs Interest List”
>> >>
>> >> Sent: Saturday, February 12, 2005 5:05 PM
>> >> Subject: Re: [ntdev] No memory.dmp mystery II
>> >>
>> >>
>> >>>I have done some reading. Intel says that when it processes
>> >>>an exception for int 1 and int 3, it bumps the IP to the next
>> >>>instruction. I suspect the solution is to replace
>> >>>EXCEPTION_EXECUTE_HANDLER with EXCEPTION_CONTINUE_EXECUTION.
>> >>>Since IP has been bumped execution should just continue on.
>> >>>
>> >>> I suspect the int 1 and int 3 handlers are being called with
>> >>> interrupts disabled because they are the debugger
>> >>> interrupts. I am going to write some code smippets to see
>> >>> what happens.
>> >>>
>> >>> Jamey
>> >>>
>> >>> ----- Original Message -----
>> >>> From: “Michal Vodicka”
>> >>> To: “Windows System Software Devs Interest List”
>> >>>
>> >>> Sent: Friday, February 11, 2005 3:26 PM
>> >>> Subject: RE: [ntdev] No memory.dmp mystery II
>> >>>
>> >>>
>> >>>>> ----------
>> >>>>> From:
>> >>>>>
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
>> >>>>> on behalf of Ralph Shnelvar[SMTP:xxxxx@dos32.com]
>> >>>>> Reply To: Windows System Software Devs Interest List
>> >>>>> Sent: Saturday, February 12, 2005 12:20 AM
>> >>>>> To: Windows System Software Devs Interest List
>> >>>>> Subject: Re: [ntdev] No memory.dmp mystery II
>> >>>>>
>> >>>>> It is not booting in debug mode.
>> >>>>>
>> >>>> Are you quite sure? Could you post appropriate boot.ini
>> >>>> entry or check if there isn’t anything related to debugger
>> >>>> (/debug etc.).
>> >>>>
>> >>>>> I can also say with absolute certainty that IF is not
>> >>>>> cleared when I run
>> >>>>> with the debugger enabled and WinDbg is attached.
>> >>>>>
>> >>>> How it behaves if you boot with debugger enabled and none
>> >>>> attached?
>> >>>>
>> >>>>> I believe this to be the ultimate Heisenbug. And truly
>> >>>>> frightening.
>> >>>>>
>> >>>> Don’t want to see real Heisenbug 
>> >>>>
>> >>>> Best regards,
>> >>>>
>> >>>> Michal Vodicka
>> >>>> UPEK, Inc.
>> >>>> [xxxxx@upek.com, http://www.upek.com]
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> —
>> >>>> Questions? First check the Kernel Driver FAQ at
>> >>>> http://www.osronline.com/article.cfm?id=256
>> >>>>
>> >>>> You are currently subscribed to ntdev as: unknown lmsubst
>> >>>> tag argument: ‘’
>> >>>> To unsubscribe send a blank email to
>> >>>> xxxxx@lists.osr.com
>> >>>>
>> >>>
>> >>>
>> >>> —
>> >>> Questions? First check the Kernel Driver FAQ at
>> >>> http://www.osronline.com/article.cfm?id=256
>> >>>
>> >>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>> >>> To unsubscribe send a blank email to
>> >>> xxxxx@lists.osr.com
>> >>
>> >>
>> >> —
>> >> Questions? First check the Kernel Driver FAQ at
>> >> http://www.osronline.com/article.cfm?id=256
>> >>
>> >> You are currently subscribed to ntdev as: xxxxx@tfb.com
>> >> To unsubscribe send a blank email to
>> >> xxxxx@lists.osr.com
>> >
>> >
>> > —
>> > Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >
>> > You are currently subscribed to ntdev as: xxxxx@ieee.org
>> > To unsubscribe send a blank email to
>> > xxxxx@lists.osr.com
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@garlic.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@tfb.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com