基于IddCx示例的UMDF视频驱动：CreateFile调用需禁用再启用设备才能成功的问题求助

Let’s break down exactly what’s happening here, starting with the security descriptor flags you’ve observed, then why the disable/enable cycle flips them, and how to fix the access denied issue for good.

First: Unpacking the Security Descriptor Flags #

Let’s start by defining what each flag in your SECURITY_DESCRIPTOR_CONTROL values means, since that’s the root of your access issue:

• SE_SELF_RELATIVE: This just means the security descriptor (SD) is stored in a self-relative format (all pointers are offsets from the start of the SD). This is standard for kernel-mode objects and doesn’t affect access checks—you’ll see this in both states.
• SE_SACL_PRESENT: The SD includes a System Access Control List (SACL), used for auditing access attempts. This is present in both states and isn’t the cause of your error.
• SE_DACL_PRESENT: The SD has a Discretionary Access Control List (DACL)—this is the critical component that controls who can access the device object.

Now the key differences between the two states:

1. Initial state (post-reboot/fresh install): 0x9814
   • SE_DACL_PROTECTED: This flag tells Windows the DACL must not inherit permissions from parent objects. When set, any inherited permissions from the device’s parent node in the device tree are ignored.
   • SE_SACL_AUTO_INHERITED: Indicates the SACL was automatically inherited from a parent object (though since SE_DACL_PROTECTED is set, this doesn’t impact the DACL).
2. After disable/enable: 0x8014
   • Both SE_DACL_PROTECTED and SE_SACL_AUTO_INHERITED are removed. Now the DACL inherits permissions from the device’s parent node.

Why This Causes "Access Denied" #

Here’s the core issue:
When the device is first installed or after a reboot, Windows assigns a default SD to IddCx devices that includes SE_DACL_PROTECTED. This blocks permission inheritance, and the default DACL likely doesn’t explicitly grant your admin test program the necessary access rights (even though you’re running as admin).

When you disable and re-enable the device, the device stack is reinitialized, and Windows skips applying that restrictive default SD. Instead, the device inherits permissions from its parent node in the device tree—and parent nodes for display devices typically grant full access to built-in administrators. That’s why your CreateFile call works after the cycle.

The fact that this happens with the official Microsoft IndirectDisplay sample confirms this isn’t a bug in your code—it’s a quirk of how Windows initializes security descriptors for IddCx devices on first boot/install.

Why the Cycle Toggles the State #

This odd behavior likely stems from two different initialization paths in the IddCx class driver or Windows PnP subsystem:

• On first boot/fresh install: PnP uses a "full initialization" path that applies the restrictive default SD with SE_DACL_PROTECTED.
• On disable/enable: PnP uses a "fast reinitialization" path that doesn’t reapply that default SD, allowing inheritance.
• Repeating the cycle might flip between these paths due to internal PnP state tracking—though this is less important than fixing the underlying access issue.

Fixes to Resolve the Access Denied Issue #

You have two reliable ways to bypass this Windows behavior:

1. Explicitly Set the Device’s SDDL in Your UMDF Driver

In your driver code, use WdfDeviceAssignSDDLString to set a custom security descriptor that explicitly grants admins full access. Do this early in device initialization, before calling WdfDeviceCreate:

NTSTATUS status;
WDF_OBJECT_ATTRIBUTES deviceAttributes;
WDF_OBJECT_ATTRIBUTES_INIT(&deviceAttributes);

// Grant full access to built-in administrators
deviceAttributes.SddlString = L"D:P(A;;GA;;;BA)";

status = WdfDeviceCreate(WdfDriver, &deviceAttributes, &deviceInit, &device);
if (!NT_SUCCESS(status)) {
    // Handle error
}

This ensures your device uses a consistent SD regardless of initialization path, so CreateFile will always work for admins.

2. Define Security in Your INF File

If your driver is installed via an INF, add a Security section to specify the SD directly in the installation package:

[MyDevice.Install]
CopyFiles=DriverFiles

[MyDevice.Security]
Security=MyDeviceSecurity

[MyDeviceSecurity]
Descriptor=D:P(A;;GA;;;BA)

This applies your custom SD during installation, overriding Windows’ default restrictive SD for IddCx devices.

3. Verify Permissions (For Debugging)

To confirm this is the issue, use tools like Process Explorer or icacls to check the device’s permissions in both states:

• Initial state: You’ll see the DACL has no inherited permissions, and admin access is missing.
• After disable/enable: You’ll see inherited permissions from the parent node, including full access for admins.

Final Notes #

This is a classic example of Windows PnP security behavior being opaque for specialized device classes like IddCx. By explicitly controlling the device’s security descriptor—either in code or INF—you eliminate the dependency on Windows’ inconsistent initialization paths.

内容的提问来源于stack exchange，提问作者Scott Smith