> For me, it looks more like NTFS issue - the second CreateProcess
calls CreateFile to open the EXE using the new name, NTFS probably
parses the new name to the file ID, and then searches for the existing FCB with this file ID.
Well, I would say that both you and me are correct.
NTFS sets FCB and SectionObjectPointers to the file object
during NtOpenFile call (aka IRM_MJ_CREATE). That’s right.
But the part responsible for looking for an existing image
section is MM.
You can confirm my description using kernel debugger, steps used
to create a process are the following:
In CreateProcessW
(preparation, like finding exact EXE name etc.)
NtOpenFile
NtCreateSection
NtCreateProcess
(continue with creating thread, environment etc.)
During NtCreateSection:
NtCreateSection calls MmCreateSection internally
In MmCreateSection, you can find call to MiFindImageSectionObject
in case that SEC_IMAGE is specified. And MiFindImageSectionObject
takes CONTROL_AREA from the file object as a key for searching for
an existing section.
I’d say it’s a group of issues, “features”, that when combined,
lead to the scenario that I described in my original post.
L.
In fact, I have pointed out this behavior previously. What you get back for the process name is the name at the time the section is first created. Since a subsequent open will reference the same section (via SOP as Ladislav points out,) you will see the same name.
This problem is hardly unique - note that if you work with CIFS, it does not guarantee that the file name returned is the file name at the moment of execution - merely that it was the file name used at the time the file was first opened.
I suspect you will find there are peculiar behaviors as well in the presence of transactions (e.g., the fact that the sections can be moved around when the transaction commits means the name for the process might “update” in the middle because the sections are switched out.)
A point I have made often over the years is that names in Windows file systems are horribly unreliable. Hard links, open by ID, destructive rename/link operations, etc. all make this horribly complicated. NTFS behavior (e.g., the fact that two files with the same ID are the same file) is wonderful, but doesn’t work when you have to work over the network (where CIFS “makes up” a file ID.)
Tony
OSR
Looking forward to seeing you in Vancouver, BC at the next File Systems class, October 20-23, 2009.