Mail Archives: djgpp/2002/10/08/00:01:56
> message generates a series of interrupts to tell us that there is data
> available in the UART. We read and display this data before sending out
> the next poll command.
> This all works very well for a while. After somewhere between 0 and 15
> minutes, the program will crash with the following error (example):
> Int 0x22 at eip 31ee0; flags=1234
> eax=00000030 ebx=00000000 ecx=0000000c edx=00000000
> esi=0001a44a edi=00000000 ebp=00000000 esp=00002672
> cs=18 ds=38 es=af fs=0 gs=0 ss=20 error=0000
I believe I've seen this error reported before.
It does seem to be from CWSDPMI. I may have entered an analysis in
a previous post/email - but I don't remember now.
CS points to the ring 0 selector but EIP doesn't make sense in that
context (32-bit on a 16-bit selector?)
So something's corrupt. It may be due to some nasty nested interrupts,
or a chip bug.
> I don't understand this error indication. Int 0x22 isn't really an
> interrupt vector at all. It simply specifies the return address
> to be used when an application terminates. I'm not certain how our
> application could have generated this interrupt. Also, the format
> of the error display leads me to believe that this report might be
> coming from CWSDPMI (see FAQ section 12.2).
> If we run this test several times, we get the same result, but at
> different eip values. I have traced all of these eip values and find
> them to be valid points within the test loop that we are running. The
> fact that the error is happening at different points in our loop leads
> me to believe that our problem has something to do with our interrupt
> handler, but I can't put my finger on it.
Is it one you wrote from pure assembly, or does it use the wrappers?
Protected mode only, or a real mode hook also?
Do you keep interrupts disabled?
What version of cwsdpmi?
What CPU (speed/type)? Motherboard chipset?
Are you making any calls in the interrupt handler?
- Raw text -