It can, but not everything is tracked by default.

Memory Validator can be configured to track as little or as much as you wish,

For example, if you are only interested in the handles returned from GetDC() and passed into ReleaseDC() you can configure that.

Or if you want to know about every handle allocated and deallocated, every memory allocation and deallocation, all COM objects, all memory errors etc, you can do that too.

However, bear in mind that the more data items being tracked, the more the performance will be affected.

See also the questions on Performance.

Yes, delay loaded functions can be hooked and are done so by default.
 

•Set whether delay loaded DLLs are hooked via the Hooked DLLs page of the global settings dialog
 

•Set whether delay loaded functions are hooked on the Collect settings page.

Absolutely. There is a help section on working with NT Services.

Yes, thread local storage is used in the stub part of the program that is injected into the target program.

Memory Validator needs to use thread local storage so that it can keep track of per-thread related data whilst instrumenting your application.

Windows NT provides each application with at least 64 thread local storage slots.

How many TLS slots are used?

Memory Validator uses 1 of these slots, leaving at least 63 available for your program to use at the same time as Memory Validator.

Memory Validator supports applications linked with the /LARGEADDRESSAWARE switch (Microsoft linkers and compatible).

When run on a computer with the /3GB switch added to the boot.ini command line, these applications can access 3GB of application addressable memory rather than 2GB.

Only certain Operating Systems support this boot.ini feature:

•Windows Server 2003 family

•Windows XP Professional Edition

•Windows 2000 Datacenter Server

•Windows 2000 Advanced Server

•Windows NT 4.0 Enterprise Edition

 
Read more about the /3GB switch and Large Address Aware applications.