I set up a debugging environment with Xen as the hypervisor. This needed a little magic with pipes and symlinks on the HV side of things. When I tried to connect the debugger to the COM1 port it failed with 0n5 (access denied), I guessed this was a failed createfile. So to debug this quickly I ran procmon and watched for create failures. nothing. In fact I didn’t see any ligitamate failure.
Then I ran windbg windbg and put a bp on kernalbase!CreateFile. Sure enough the create to \.\Com1 was failing with 0xc0000022.
So why didn’t I see this create in procmon?
Because it’s a CreateFile call targeting a COM port, not a file system.
Process Monitor loads a file system filter driver and thus only reports
CreateFile calls targeting file systems.
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntdev…
I set up a debugging environment with Xen as the hypervisor. This needed a
little magic with pipes and symlinks on the HV side of things. When I tried
to connect the debugger to the COM1 port it failed with 0n5 (access denied),
I guessed this was a failed createfile. So to debug this quickly I ran
procmon and watched for create failures. nothing. In fact I didn’t see any
ligitamate failure.
Then I ran windbg windbg and put a bp on kernalbase!CreateFile. Sure enough
the create to \.\Com1 was failing with 0xc0000022.
So why didn’t I see this create in procmon?
ah, I thought it caught all creates by modifying the jump table. thanks scott,
Greg