Supported release API for a full-file SHA-256 bound to a process creation FileObject?

[Oranya-Berlin]

Hello System Informer maintainers,

I am evaluating the supported observation interface of release v4.0.26241.138 (commit 99a0d28) for an integrity audit of processes owned by a local application. This is a capability/contract question, not a request to bypass any client, signing, privilege or sandbox checks.

The requirement is to associate each owned process, including very short-lived children, with the exact executable file object used at creation and the full-file SHA-256 of those bytes. The object must be captured before user-mode execution. A later hash could be acceptable if the object lifetime and byte stability are guaranteed. Reopening a pathname, or substituting an Authenticode hash for the full-file hash, would not meet this requirement. Missing evidence must remain unknown.

From the pinned release sources I found:

• informer_process.c assigns CreateInfo->FileObject to KPHM_PROCESS_CREATE; the message also has target and parent process start keys, but no hash.
• hash.c implements KphQueryHashInformationFileObject, while the user message KphMsgQueryHashInformationFile accepts a file handle and requires Maximum client state.
• KphHashAlgorithmSha256 is separate from Sha256Authenticode. KPHM_IMAGE_VERIFY carries ImageInformation->ImageHash, whose public BDCB_IMAGE_INFORMATION documentation describes an Authenticode hash; this is distinct from ImageLoad.
• Rate-limit statistics include Allowed/Dropped/CasMiss. I have not established how every allocation failure, queue failure or disconnect becomes visible to a consumer.

Could you point to a supported API and version-specific documentation answering these questions?

1. Can a legitimate signed client obtain the full-file SHA-256 of the exact executable FileObject supplied at process creation, without reopening the pathname? How is the event's opaque FileObject pointer safely bound to a supported hash request or returned hash result?
2. What object lifetime, timing, byte-stability and cache-validity guarantees apply, including when a process exits before consumption? Which exact bytes are included in the SHA-256?
3. Can the consumer detect every lost or incomplete process/hash record, including message allocation failures, async queue failures and partial initialization? What sequence/epoch or recovery contract covers reconnects and reboot boundaries?
4. Which shipped signed binaries, Windows versions, configuration and supported client-signing requirements provide this interface? We would preserve existing signing/security settings, and would not enable SeDebugPrivilege or use developer/test-signing fallbacks as a workaround.
5. Is there a documented resource limit and supported unload/cleanup procedure for a bounded observation session?

I checked the official release ZIP checksum and native Authenticode status. The extracted amd64 SYS and ksi.dll Git blobs match bin-signed/amd64 at the release commit. I understand that this binds artifacts and does not by itself establish the semantic guarantees above. No driver has been loaded for this evaluation.

If this contract is outside the supported scope, a precise statement of which guarantees are unavailable would also be helpful. Thank you.

[jxy-s]

KSystemInformer is an internal component of System Informer, not a public or supported API. Its message interface, structures, and behavior can change between any builds without notice, and there are no documented guarantees around object lifetime, hash semantics, event delivery, or resource limits. The driver only services verified System Informer clients, and we don’t support or provide a path for third-party clients. Nothing in the source constitutes a supported contract.

If you need process-creation integrity evidence for your own application, documented Windows mechanisms are the right foundation (e.g. PsSetCreateProcessNotifyRoutineEx in your own signed driver, ETW, WDAC/CI auditing).