I have a UMDF video driver based upon the IddCx sample. I have a command-line test that calls
CreateFile on a video adapter device instance to get a handle to it for IOCTL purposes. The test fails on the
CreateFile call with Access Denied
I discovered that if I simply disable and re-enable the adapter in Device Manager, and then re-run the same test, it succeeds. The test will continue to succeed until I restart Windows, or uninstall/reinstall the device.
CreateFile call itself doesn’t trigger any calls to my driver (more on that below), so I can’t easily debug it from the bottom up.
Toggling the adapter device’s enabled state changes SOMETHING such that the exact same
CreateFile call succeeds. I decided to trace the
CreateFile call until it fails… here’s what I’ve found:
--- User Mode --- mytest!CreateFile ntdll!NtCreateFile --- Kernel Mode --- nt!IopCreateFile nt!ObOpenObjectByNameEx nt!ObpLookupObjectName nt!IopParseDevice nt!SeAccessCheck [returns Access Denied]
nt!SeAccessCheck, and when that returns
nt!IopParseDevice sets last error to Access Denied and returns failure.
Now, here’s the interesting part (that I need help with):
The parameters passed into
nt!SeAccessCheck are slightly different, depending upon whether I run my test before or after I disable+enable my device. Notably, the provided SecurityDescriptor parameter’s
SECURITY_DESCRIPTOR_CONTROL member changes:
(after Windows restart or adding new adapter device) 0x9814 (SE_SELF_RELATIVE | SE_SACL_PRESENT | SE_DACL_PRESENT | SE_DACL_PROTECTED | SE_SACL_AUTO_INHERITED) (after disable/enable adapter) 0x8014 (SE_SELF_RELATIVE | SE_SACL_PRESENT | SE_DACL_PRESENT)
I don’t know enough about Windows security to understand what these two flags signify in the larger context. Can anyone shed light on what might be going on?
Source: Windows Questions