Long time ago friend asked me how to fake time and tickcount 100% sure without hooks. I came up with this code which hook KUSER_SHARED_DATA by replacing it's PDE/PTE for targeted process. It was laying on my hdd long long time, thus I've decided to publish it

http://deroko.phearless.org/timestop.zip

It makes no sense. Use IDP(or NOACCESS) for tracking the counters.
http://www.woodmann.com/forum/showthread.php?14848-User-mode-System-Call-Hooking&p=92981&viewfull=1#post92981 ("http://www.woodmann.com/forum/showthread.php?14848-User-mode-System-Call-Hooking&p=92981&viewfull=1#post92981")

Sweet, now go and write full emulator for every instruction accessing this memory to properly fake values which are read. It's not about logging when it's read, BUT faking what is read.

Emulator is not necessary, displace the segment. see IDP.

Ok finally found your IDP. What you are doing here also relies on exception. My point is that when exception happens, you need to emulate instruction (from context) to fake proper data and skip over instruction (that's emulator thing), unless of course you want to break. My implementation doesn't require any exception delivery, no code injections for VEH/SEH/hook KiUserExceptionDisaptcher etc... and it effectively stops timing, and does exactly what I wanted, and what I needed.

Edit:
Comment is based on the code you demonstrated previously, in reply to hooking of wow64. Where Segment limit is set a little bit low to catch access to kshared memory.

Regarding IDP, after going in details over it, it assumes that memory access will cause access violation to pointer which means you have to fix this pointer in such way that it will cause ACCESS_VIOLATION so you can catch exception. Code is good, and idea is good, but is completely different from my approach, and what my code was intended to do. Point of IDP is to catch break when accessing certain memory, and then through single step, and segment modification to go to different base, and eventually fake it. Point of my code was/is to break GetTickCount as way of generating randomness for memory allocation, or to freeze time for certain application, thus minimizing possibility of random memory allocation across execution during reversing.