CreateFile fails unless I disable/enable my device

  driver, umdf, wdk, winapi, windows

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.

The test’s 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!IopParseDevice calls nt!SeAccessCheck, and when that returns FALSE, 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

LEAVE A COMMENT