Module query 

The GetFileInformationByHandleEx entry.

Entry 5 of the audited catalogue, and the most-called namespace operation across all three audited consumers.

Why it is here despite being trivial to marshal

This entry needs almost no marshaling work: its inputs are a handle, a scalar class, and a buffer size, with no pointer into caller memory anywhere. That invites the conclusion that it does not belong in a catalogue at all. Membership is decided by whether a blocking namespace call needs performing off the caller’s thread, not by whether it is awkward to marshal – the latter test would select for our implementation convenience rather than for consumer need. On the former test this is the call whose lack of an overlapped form is why an unassociated handle had to become a first-class destination at all.

This returns bytes, and does not parse them

The audited classes have two result shapes – fixed-size out-parameters and variable-length batches – and both collapse to one owned buffer here, because this crate returns bytes plus the unaltered outcome. Per-class parsing stays with the consumer that already owns it.

Two constraints on that buffer are not negotiable:

• It must be 8-byte aligned. A Vec<u8> guarantees byte alignment and nothing more, and a misaligned batch is not a subtle problem: the very first query fails with ERROR_NOACCESS. AlignedBuffer states the alignment rather than arriving at it by luck.
• The call reports no written length. A batch is walked by its own next-entry offsets, so the whole buffer comes back and the consumer bounds its own reads, rather than this entry inventing a byte count it cannot know.

Only two classes touch the enumeration cursor

Measured on Windows 11 Enterprise 10.0.28000, aarch64-pc-windows-msvc, against a real directory with a deliberately small buffer:

Question	Measured
Does a duplicated handle share the enumeration cursor?	Yes – a clean continuation
Control: do two separate opens share it?	No – the second restarts
Does closing the duplicate disturb the source?	No
Does an interleaved FileBasicInfo, FileIdInfo, or non-Ex query disturb it?	No

So the contract is narrower than “handle-taking entries are hazardous”: only the two directory-enumeration classes mutate the shared cursor, and every other query is a pure read that composes freely with an enumeration in progress, on the same handle or on a duplicate. What follows is specific – a duplicate is not an independent enumeration, and an independent traversal needs a fresh open.

This is single-shot, and is not a streaming engine

An entry covering the two directory classes otherwise looks like a second implementation of a shipped streaming enumerator. It is not. This entry is single-shot: one call, one batch, and the client sequences the next, which is the one-entry-per-Win32-call rule applied literally. A consumer wanting streaming enumeration – with the cursor, refill loop, quanta, and backpressure owned for it – wants windows-file-enumeration-sys and should not rebuild that loop out of single-shot calls.

All five audited classes stay reachable here regardless, because restricting them would narrow the entry for a no-consumer reason.

No ambient context is needed

Access was checked at the open. That is exactly why the enumeration crate applies impersonation only around CreateFileW, and it makes this the clearest case that a request and a context are paired at submission rather than fused.

Structs

FileInformationClass

Which information the query asks for.

QueryFileInformation

An owned, marshalable parameter set for GetFileInformationByHandleEx.