The name EPROFILE is hypothesised, Microsoft’s name
not being known even from symbol files. That is some measure of the structure’s
being internal to the kernel. Against that, however, is that the structure does
model a formal object that exists precisely so that a handle can be obtained from
user mode. As for any handle, it can be useful to inspect the corresponding object
when doing kernel-mode debugging. Indeed, any user-mode program that knows the handle
can obtain the kernel-mode address of the object via NtQuerySystemInformation without needing
unusual privilege and can even read from the address with the help of a kernel-mode
driver (which sounds more demanding than it often is).

Layout

Though the EPROFILE is too internal to be described
even in symbol files, it is almost as stable as many a documented structure, presumably
as a side-effect of its very tightly constrained use. After version 3.51 allowed
for specification of the profile source and of which processors will have their
execution profiled, the only formal change is for Windows 7 to support more than
32 or 64 processors by way of processor groups. That the size then increases for
64-bit Windows 8 is simply from allowing for more processor groups.

Version

Size (x86)

Size (x64)

3.10 to 3.50

0x28

3.51 to 6.0

0x30

0x50

6.1

0x38

0x70

6.2 to 10.0

0x38

0xF0

The layout below does not attempt any C-language definition of members as if
such things can be inferred from type information in symbol files. Types in a fixed-pitch
font as if for programming are ventured only where the member is copied from a function
argument such that Microsoft’s choice of formal type is known and plausibly
(but not certainly) passes into the structure.