APIC timer ISR will automatically reboot

[wyz7155]

Hello, guys.
I use the local APIC as the high precise timer to trigger Interrupt periodically to do something (for now, I just print "Hello World").
The problem is:　The interrupt can be periodically triggered and can print "Hello World" normally with low CPU usage . But if the CPU usage is high (running AIDA64 CPU test), the PC will automatically reboot, and WinDbg on my host has no error information or dump files.
And I try to solve this problem by giving APIC long period, it doesn't work.
My OS is Windows 7 x64, I modified this code from Windows 7 default APC ISR.
Thank you guys.
This is my ISR code:

Code: Select all

#pragma LOCKEDCODE
void Dispatch()
{	
	DbgPrint("Hello World\n");
	//InitScheduler();	
	return;
}

#pragma LOCKEDCODE
__declspec (naked) interrupt()
{	
	_asm
	{
		sub     rsp, 8
		push rbp
		sub	rsp, 158h
		lea rbp, [rsp + 80h]
		mov     byte ptr[rbp - 55h], 0		
		mov qword ptr[rbp - 50h], rax
		mov qword ptr[rbp - 48h], rcx
		mov     qword ptr[rbp - 40h], rdx
		mov     qword ptr[rbp - 38h], r8
		mov     qword ptr[rbp - 30h], r9
		mov     qword ptr[rbp - 28h], r10
		mov     qword ptr[rbp - 20h], r11

		cld
		stmxcsr dword ptr[rbp - 54h]
		ldmxcsr dword ptr gs : [180h]
		movaps  xmmword ptr[rbp - 10h], xmm0
		movaps  xmmword ptr[rbp], xmm1
		movaps  xmmword ptr[rbp + 10h], xmm2
		movaps  xmmword ptr[rbp + 20h], xmm3
		movaps  xmmword ptr[rbp + 30h], xmm4
		movaps  xmmword ptr[rbp + 40h], xmm5
		inc     dword ptr gs : [4880h]
		mov     ecx, 0eh
		mov     rax, cr8
		mov		cr8, rcx
		mov     byte ptr[rbp - 57h], al
		push    rcx
		mov     rcx, qword ptr[pHalPerformEndOfInterrupt]
		call    qword ptr[rcx]

		sti
		call Dispatch
		cli

		movzx   ecx, byte ptr[rbp - 57h]
		mov     cr8, rcx

		ldmxcsr dword ptr[rbp - 54h]
		movaps  xmm0, xmmword ptr[rbp - 10h]
		movaps  xmm1, xmmword ptr[rbp]
		movaps  xmm2, xmmword ptr[rbp + 10h]
		movaps  xmm3, xmmword ptr[rbp + 20h]
		movaps  xmm4, xmmword ptr[rbp + 30h]
		movaps  xmm5, xmmword ptr[rbp + 40h]
		mov     r11, qword ptr[rbp - 20h]
		mov     r10, qword ptr[rbp - 28h]
		mov     r9, qword ptr[rbp - 30h]
		mov     r8, qword ptr[rbp - 38h]
		mov     rdx, qword ptr[rbp - 40h]
		mov     rcx, qword ptr[rbp - 48h]
		mov     rax, qword ptr[rbp - 50h]
		mov rsp, rbp
		mov rbp, qword ptr [rbp + 0d8h]
		add rsp, 0e8h
		
		iretq
	}
}

[Octocontrabass]

I use the local APIC as the high precise timer to trigger Interrupt periodically to do something (for now, I just print "Hello World").

Why are you doing this instead of using the available Windows APIs?

The problem is:　The interrupt can be periodically triggered and can print "Hello World" normally with low CPU usage . But if the CPU usage is high (running AIDA64 CPU test), the PC will automatically reboot, and WinDbg on my host has no error information or dump files.

It sounds like you're causing a triple-fault. Try running your code inside an emulator or virtual machine that has a debugger to figure out why it happens.

[wyz7155]

I use the local APIC as the high precise timer to trigger Interrupt periodically to do something (for now, I just print "Hello World").

Why are you doing this instead of using the available Windows APIs?

The problem is:　The interrupt can be periodically triggered and can print "Hello World" normally with low CPU usage . But if the CPU usage is high (running AIDA64 CPU test), the PC will automatically reboot, and WinDbg on my host has no error information or dump files.

It sounds like you're causing a triple-fault. Try running your code inside an emulator or virtual machine that has a debugger to figure out why it happens.

Because Windows High-Resolution API can't meet our demands on accuracy, we need the accuracy that is about 100us.
And could you please tell the probable reason that cause this triple fault.

[Octocontrabass]

Because Windows High-Resolution API can't meet our demands on accuracy, we need the accuracy that is about 100us.

You need a real-time OS, like RTLinux.

And could you please tell the probable reason that cause this triple fault.

I have no idea what causes the triple fault. You'll have to try debugging it yourself.

[embryo2]

The interrupt can be periodically triggered and can print "Hello World" normally with low CPU usage . But if the CPU usage is high (running AIDA64 CPU test), the PC will automatically reboot

Generally - there are differences. I don't know your AIDA64, but I see that when PC is idle your program works and when PC is busy your program crashes. What's going on when PC is busy? It executes the interrupt's code and returns to the program that actually does something instead of a stub that most probably just halts the processor. So, when your code returns from the interrupt the program expects it's state is untouched and keeps working. But at some point it reads the part of the state that actually was modified by your interrupt code. And while being idle the stub has not touched the changed part of the state. It means you should look carefully at your code and decide where your efforts were so effective that an independent program can crash because of it. Usually it's all about registers that were not properly saved/restored.

[wyz7155]

The interrupt can be periodically triggered and can print "Hello World" normally with low CPU usage . But if the CPU usage is high (running AIDA64 CPU test), the PC will automatically reboot

Generally - there are differences. I don't know your AIDA64, but I see that when PC is idle your program works and when PC is busy your program crashes. What's going on when PC is busy? It executes the interrupt's code and returns to the program that actually does something instead of a stub that most probably just halts the processor. So, when your code returns from the interrupt the program expects it's state is untouched and keeps working. But at some point it reads the part of the state that actually was modified by your interrupt code. And while being idle the stub has not touched the changed part of the state. It means you should look carefully at your code and decide where your efforts were so effective that an independent program can crash because of it. Usually it's all about registers that were not properly saved/restored.

Thank you sir, I've solved this problem with your help.