Difference between a stream context and a stream handle context

trying to understand the difference, is the stream context shared across processes which load/use the same object, like say kernel32.dll? I have seen silter manager free stream contexts way way after the process itself has been destroyed, why is that?

  • A Stream Context is associated with the Stream (which is to say that c:\foo has a different context from c:\foo:bar). It stays around for the life of the file system’s data structures for the stream. There is a 1 to 1 correspondence between the Stream Context and FileObject->FsContext.
  • A Stream Handle Context is associated with a single Open/Create of the stream. Which is to say that if the same or different thread in the same or different process has the same stream open twice then there will be two Stream Handle Contexts. There is a 1 to 1 correspondence between the Stream Handle Context and FileObject->FsContext2. You can think of the Stream Handle Context being associated with a HANDLE (although the pedantic will point out that duplicated and inherited handles confuse things and stop that being 100% true).
  • Both types of context can and often do outlive the application issuing an Close on the handle. This is because the file system and other subsystems will conspire to keep the context alive - for instance to allow caching of the contents after the application has done with it.
3 Likes