This is the fifth post of the “Pushing the Limits of Windows” series in Mark’s blog, where he focuses on the upper bound on the number and size of resources that Windows manages, such as physical memory, virtual memory, processes and threads:
- Pushing the Limits of Windows: Physical Memory
- Pushing the Limits of Windows: Virtual Memory
- Pushing the Limits of Windows: Paged and Nonpaged Pool
- Pushing the Limits of Windows: Processes and Threads
In this post, he goes inside the implementation of handles to find and explain their limits. Handles are data structures that represent open instances of basic operating system objects applications interact with, such as files, registry keys, synchronization primitives, and shared memory. There are two limits related to the number of handles a process can create: the maximum number of handles the system sets for a process and the amount of memory available to store the handles and the objects the application is referencing with its handles.
In most cases the limits on handles are far beyond what typical applications or a system ever use. However, applications not designed with the limits in mind may push them in ways their developers don’t anticipate. A more common class of problems arise because the lifetime of these resources must be managed by applications and, just like for virtual memory, resource lifetime management management is challenging even for the best developers. An application that fails to release unneeded resources causes a leak of the resource that can ultimately cause a limit to be hit, resulting in bizarre and difficult to diagnose behaviors for the application, other applications or the system in general.
Read the article here – http://blogs.technet.com/markrussinovich/archive/2009/09/29/3283844.aspx
