处理意外的DPI感知

如何解决处理意外的DPI感知

我有一项服务，该服务使用CreateProcessAsUser在用户会话中启动可执行文件，并在STARTUPINFO参数中指定了桌面。效果很好。

我的可执行文件未显示，也未调用任何与DPI相关的API。

当我通过双击或通过cmd.exe手动启动可执行文件时，任务管理器正确地将DPI意识显示为“ Unaware”。

但是，当我的可执行文件由服务启动时，任务管理器将DPI意识显示为“每个监视器”-实际上，它的行为也是如此。

Setting the default DPI awareness for a process说：

有两种主要方法可以指定进程的默认DPI意识：

1. 通过应用清单设置
2. 通过API调用以编程方式

我都不做这些事。

我确认使用mt.exe不会显示.exe。我在以下位置设置函数断点：

• user32.dll！SetProcessDpiAwarenessContext
• user32.dll！SetThreadDpiAwarenessContext
• shcore.dll！SetProcessDpiAwareness

没有断点；但是，从服务启动后，我只能在进入main后才能附加调试器-并且似乎已经设置了DPI意识。

还有其他地方可以设置DPI意识吗？

这是一个混合rust / C应用程序-没有（例如）.NET依赖项引用。

---

编辑：

使用JIT调试器，我可以在mainCRTStartup处中断，然后看到DPI意识此时已经是“ PerMonitor”。呼叫SetProcessDpiAwarenessContext(DPI_AWAREnesS_CONTEXT_UNAWARE)或SetProcessDpiAwareness(PROCESS_DPI_UNAWARE)无效。

---

编辑：

使用CreateProcessAsUser从我的服务启动时；可执行文件具有以下环境变量：

__ COMPAT_LAYER = HighDpiAware

传递给CreateProcessAsUser的环境是通过调用以下方法创建的：

CreateEnvironmentBlock和我的用户句柄。其余环境符合预期。这是哪里来的？当我在资源管理器中检查可执行文件的属性时，没有在可执行文件上设置任何兼容性选项...

解决方法

我的服务以SYSTEM身份运行。在这种情况下，当我调用# ... Setup your network,load the input # ... # Set proper requires_grad -> We train the input,not the parameters input.requires_grad = True for p in network.parameters(): p.requires_grad = False # Setup the optimizer # Previously we should have SomeOptimizer(net.parameters()) optim = SomeOptimizer([input]) output_that_you_want = ... actual_output = net(input) some_loss = SomeLossFunction(output_that_you_want,actual_output) # ... # Back-prop and optim.step() as usual 时，可执行文件也将以SYSTEM身份运行。我将CreateProcessAsUser参数传递给nullptr。 MSDN这样说：

指向新进程的环境块的指针。如果此参数为NULL，则新进程将使用调用进程的环境。

但是，当我检查可执行文件的环境时，会看到：

__ COMPAT_LAYER = HighDpiAware

这将强制每个监视器的DPI意识。这很神秘，因为确实-在注册表中为S-1-5-18（SYSTEM）中的可执行文件设置了AppCompatFlag，但是我不知道此值的来源或来源。

未在我的服务上设置该变量（该变量也作为SYSTEM运行）-大概服务没有获得AppCompat环境？但是，为什么我的子进程尽管继承了父进程的环境，却为什么拥有它呢？我想这些兼容性标志必须经过特殊处理。

无论如何，我的问题的答案是：从lpEnvironment环境变量中删除HighDpiAware。