Bugzilla

For ease of debugging, I modified the GPU process to use the RDD sandbox policy so that I could quickly observe this issue.

In addition to the information that I included in Comment 3, there is this:
At one point during delayload resolution, the loader checks to see whether the library we're trying to load is a KnownDLL. As part of that check, the loader ends up calling `NtOpenSection` in search of a section named `ntmarta.dll` with a non-null `RootDirectory` handle. Here's the handle information that I dumped from the `RootDirectory`:

```
  Type         	Directory
  Attributes   	0x10
  GrantedAccess	0x3:
         None
         Query,Traverse
  HandleCount  	262
  PointerCount 	8499676
  Name         	\KnownDlls
```

This call to `NtOpenSection` fails with `STATUS_ACCESS_DENIED`. Amusingly enough, an object named `ntmarta.dll` doesn't actually exist, so if `NtOpenSection` had returned a different error code indicating as such, we wouldn't have failed. But since we do fail with an unexpected error code, it is propagated up the stack and the delayload resolver sets `SetEntriesInAclW` to point to a stub that returns the error code that we're seeing here.


I'm going to move this over to sandboxing, since at this point it's clear that we need to fix how the RDD sandbox deals with delayloads. TL;DR we need these `NtOpenSection` calls in search of \KnownDlls\* to work, or at least fail without `STATUS_ACCESS_DENIED`

Bob, thoughts?

For ease of debugging, I modified the GPU process to use the RDD sandbox policy so that I could quickly observe this issue.

In addition to the information that I included in Comment 3, there is this:

At one point during delayload resolution, the loader checks to see whether the library we're trying to load is a KnownDLL. As part of that check, the loader ends up calling `NtOpenSection` in search of a section named `ntmarta.dll` with a non-null `RootDirectory` handle. Here's the handle information that I dumped from the `RootDirectory`:

```
  Type         	Directory
  Attributes   	0x10
  GrantedAccess	0x3:
         None
         Query,Traverse
  HandleCount  	262
  PointerCount 	8499676
  Name         	\KnownDlls
```

This call to `NtOpenSection` fails with `STATUS_ACCESS_DENIED`. Amusingly enough, an object named `ntmarta.dll` doesn't actually exist, so if `NtOpenSection` had returned a different error code indicating as such, we wouldn't have failed. But since we do fail with an unexpected error code, it is propagated up the stack and the delayload resolver sets `SetEntriesInAclW` to point to a stub that returns the error code that we're seeing here.


I'm going to move this over to sandboxing, since at this point it's clear that we need to fix how the RDD sandbox deals with delayloads. TL;DR we need these `NtOpenSection` calls in search of sections named `\KnownDlls\*` to work, or at least fail without `STATUS_ACCESS_DENIED`

Bob, thoughts?