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
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
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
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
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
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
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
