Re: Read of memory location 0x7ffe0000 in windows NT
After some investigation, it seems that reading the memory location 0x7ffe 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 0xffdf (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
Re: Read of memory location 0x7ffe0000 in windows NT
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 0x7ffe 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.
Re: 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 0x7ffe 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
Re: Read of memory location 0x7ffe0000 in windows NT
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 0x7ffe 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
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 0x7ffe 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 $0x7ffe,%edx mov (%edx),%eax mov %eax,0xfffc(%ebp) popa mov 0xfffc(%ebp),%eax Any idea anyone ? Thanks for your help. Laurent Pinchart
Re: Read of memory location 0x7ffe0000 in windows NT
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 0x7ffe 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
Re: Read of memory location 0x7ffe0000 in windows NT
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 0x7ffe 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? The DLL which does that is drvmgt.dll, from SafeDisc copy protection. It came with a driver (secdrv.sys) which returns, among other things, KeTickCount.LowPart to userland, and that value seems to be compared at a later time with *(LPDWORD)0x7ffe. I can't tell if the behaviour is the same with -winver win98, as the program crashes quite early with that option when trying to execute ring 0 code. Anyway I expect that -winver win95 and -winver win98 won't try to read *(LPDWORD)0x7ffe because drvmgt.dll and secdrv.sys seem to be used to detect if a debugger is running (by inspecting the IDT and the debug register DB1 and DB7), and that detection if performed from userspace under windows 95 and 98. Laurent Pinchart
