Read of memory location 0x7ffe0000 in windows NT
Hi everybody, I've stumbled accross some code which reads a dword at memory location 0x7ffe000, which causes the program to crash and the wine debugger to start. After some investigation, it seems that reading the memory location 0x7ffe0000 should return KeTickCount.LowPart to the user process. Has anyone ever heard about that ? I was wondering if it was a native windows NT behaviour, or if it was done by a special kernel-space exception handler installed by the program. The assembly code which does the trick is pusha mov $0x7ffe0000,%edx mov (%edx),%eax mov %eax,0xfffffffc(%ebp) popa mov 0xfffffffc(%ebp),%eax Any idea anyone ? Thanks for your help. Laurent Pinchart
On Tue, Apr 02, 2002 at 12:11:09AM +0200, Laurent Pinchart wrote:
Hi everybody,
I've stumbled accross some code which reads a dword at memory location 0x7ffe000, which causes the program to crash and the wine debugger to start.
After some investigation, it seems that reading the memory location 0x7ffe0000 should return KeTickCount.LowPart to the user process. Has anyone ever heard about that ? I was wondering if it was a native windows NT behaviour, or if it was done by a special kernel-space exception handler installed by the program.
It's a native NT thing; a page of memory at that address is shared between user and kernel space. The definition in the w2k ddk.
Hi everybody,
I've stumbled accross some code which reads a dword at memory location 0x7ffe000, which causes the program to crash and the wine debugger to start.
After some investigation, it seems that reading the memory location 0x7ffe0000 should return KeTickCount.LowPart to the user process. Has anyone ever heard about that ? I was wondering if it was a native windows NT behaviour, or if it was done by a special kernel-space exception handler installed by the program.
It's a native NT thing; a page of memory at that address is shared between user and kernel space. The definition in the w2k ddk.
I found it, thank you very much. BTW does anyone know where I can find information about KeTickCount ? I'd like to understand the meaning and purpose of the 3 fields (LowPart, High1Time, High2Time). There's nothing about it in the MSDN. Laurent Pinchart
I've stumbled accross some code which reads a dword at memory location 0x7ffe000, which causes the program to crash and the wine debugger to start.
After some investigation, it seems that reading the memory location 0x7ffe0000 should return KeTickCount.LowPart to the user process. Has anyone ever heard about that ? I was wondering if it was a native windows NT behaviour, or if it was done by a special kernel-space exception handler installed by the program.
It's a native NT thing; a page of memory at that address is shared between user and kernel space. The definition in the w2k ddk.
I found it, thank you very much.
Could anyone tell me where I should look to implement that shared page in wine ? In the page fault exception handler ? Any information will be welcome.
BTW does anyone know where I can find information about KeTickCount ? I'd like to understand the meaning and purpose of the 3 fields (LowPart, High1Time, High2Time). There's nothing about it in the MSDN.
It looks like KeTickCount.LowPart is a 10ms counter. Anyone can confirm ? Laurent Pinchart
After some investigation, it seems that reading the memory location 0x7ffe0000 should return KeTickCount.LowPart to the user process. Has anyone ever heard about that ? I was wondering if it was a native windows NT behaviour, or if it was done by a special kernel-space exception handler installed by the program.
It's a native NT thing; a page of memory at that address is shared between user and kernel space. The definition in the w2k ddk.
I downloaded the w2k ddk, and SharedUserData seems to be located at 0xffdf0000 (line 5099 of ntddk.h). Did Microsoft move the page around between NT4 and NT5, or is there something I don't understand ? Laurent Pinchart
On Tue, Apr 02, 2002 at 12:11:09AM +0200, Laurent Pinchart wrote:
Hi everybody,
I've stumbled accross some code which reads a dword at memory location 0x7ffe000, which causes the program to crash and the wine debugger to start.
After some investigation, it seems that reading the memory location 0x7ffe0000 should return KeTickCount.LowPart to the user process. Has anyone ever heard about that ? I was wondering if it was a native windows NT behaviour, or if it was done by a special kernel-space exception handler installed by the program.
What program uses that code? Does it change the behaviour if run with -winver win98 or similar? Ciao, Marcus
participants (3)
-
David Welch -
Laurent Pinchart -
Marcus Meissner