How should I interpret local WACK DPI and Blocked executables findings for a packaged Win32 app?

Question

How should I interpret local WACK DPI and Blocked executables findings for a packaged Win32 app?

Takuma Yamada 0

I tested a full-trust x64 MSIX desktop app on Windows 11 Pro 25H2 (build 26200.9818) with WACK 10.0.28000.2957. Both the one-file and one-folder builds produced the same results: 22 PASS, optional TEST88 (Blocked executables) FAIL, and TEST92 (DPIAwarenessValidation) WARNING.

DPI: The executable declares PerMonitorV2, and GetProcessDpiAwareness returned 2. WACK reported that it could not process the installed executable and classified the app as not DPI aware. In a separate diagnostic comparison, the same probe and installed path yielded different results across package contexts: ordinary read access succeeded in both, but CreateActCtx succeeded in one context and returned access denied in the other. An identical file copy worked in both contexts. The original WACK process was not traced.

Blocked executables: The app starts its own executable for required Python multiprocessing workers. The report also flags API references and short strings in bundled dependencies. Static analysis identifies conditional launch paths in Qt and OpenGL, but the available observations do not establish whether those paths executed.

Can retained WACK logs distinguish failure to read the executable’s manifest from a missing DPI declaration?
How should a developer document self-spawn and conditional launch references in bundled libraries when reviewing TEST88?
Given that WACK is no longer maintained, is there a supported way to clarify these findings using existing evidence?

0 comments

2 answers

Your answer

Answer 1

Hi @Takuma Yamada ,

Based on a local reproduction, a TEST92 warning is not evidence that the PerMonitorV2 declaration is missing when the same report also says WACK could not process the executable. TEST88 also flags static references, so a FAIL there does not by itself show that a launch path ran.

To check this, I built small test apps from source, packaged them as full-trust x64 MSIX packages, installed them, and ran only TEST88 and TEST92 on Windows 11 build 26300.9457 with WACK 10.0.26100.8249. These are not your binaries, and the OS and WACK versions differ from yours, so please treat this as an independent reproduction rather than a diagnosis of your report.

Test package	Runtime observation	TEST88	TEST92
`PerMonitorV2` embedded in the manifest	PerMonitorV2 context	PASS	WARNING, binary could not be processed
No DPI declaration	Unaware	PASS	Same WARNING and same message
Native exe importing `WinExec` in a function that is never called	ETW shows no child process	FAIL	WARNING
Native exe containing only `cmd` and `powershell.exe` strings	No child process	PASS	WARNING
PyInstaller + PySide6 app, one-folder and one-file	Workers relaunch the same packaged exe (same path, hash and package identity)	FAIL	WARNING

I also saw the pattern you described. From a process without package identity, CreateActCtxW on the installed exe under WindowsApps failed with error 5, while reading the file and its RT_MANIFEST resource succeeded. The same call succeeded from two different full-trust package processes and on a byte-identical copy. I did not trace WACK's own native calls, so this does not prove that WACK hit the same error. It only shows that manifest activation on an installed exe can fail even when the file can be read.

On the first question, the retained XML and HTML can separate the two cases only if they still contain the processing message. In my runs, both files kept the "could not process" line next to the final DPI warning, and the detailed WACK trace recorded E_FAIL (0x80004005) for that check. Because the PerMonitorV2 package and the package with no DPI declaration ended with the identical warning, the final classification alone cannot tell them apart.

If your retained logs only have the final line, the stronger evidence is the manifest extracted from the exact installed exe, for example with mt.exe -inputresource:"<installed path>\YourApp.exe";#1 -out:installed.manifest, plus its hash compared with the package payload. The extracted dpiAwareness element can then be checked against Application manifests, which notes that dpiAwareness overrides dpiAware and that PerMonitorV2 is recognized starting with Windows 10 version 1703. For the runtime side, PROCESS_DPI_AWARENESS only defines values 0, 1 and 2, so GetProcessDpiAwareness returns 2 for both PerMonitor and PerMonitorV2. To tell them apart, GetThreadDpiAwarenessContext can be compared with DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 through AreDpiAwarenessContextsEqual, since that page notes contexts cannot be compared bitwise.

As for TEST88, Windows Desktop Bridge app tests lists Blocked executables as an optional, informational check aimed at Windows S mode. It says flagged files that are part of your app can be ignored, while calls that launch executables outside the app should be removed. Since a never-called import still failed in my test, I would record each finding with its evidence level: the binary and hash, the API or string, whether a runtime trace observed a child process, and if so, the resolved image path and whether it sits inside the package. The multiprocessing self-spawn fits the "part of your application" case once the trace shows the child resolves to the same packaged exe. Qt and OpenGL references with no observed child are best recorded as static or conditional references, without claiming they executed and without claiming they can never execute, because one run does not cover every code path. The one-file build also extracts DLLs at runtime, which matches the self-extracting pattern described under Archive files usage on the same page, so the one-folder build may be the safer choice if S mode matters.

What I have shared here, the reproduction results and how to read the findings against the documentation, is the extent of what I can support on this forum. For a deeper investigation of your own package or of WACK's internal behavior, Windows Developer Support is the more suitable channel, since engineers there can work directly with your binaries and logs.

I hope that the test results and documentation I’ve shared can be of some help and provide a little more clarity around the behavior you’re investigating. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guidance so that others in the community facing a similar issue can find it more easily and help each other.

Thank you.

Answer 2

Treat TEST92 as an inconclusive analyzer result—not proof that the executable lacks DPI metadata—and classify TEST88 entries by whether they launch packaged app components or external executables; final clarification comes from Partner Center certification because local WACK is deprecated.

TEST92: what the retained logs can establish

Inspect both the saved HTML and XML reports. WACK produces both formats, and the XML is generally better for locating per-test diagnostics and file-level messages.^1^

The artifacts can distinguish the cases only if they contain an explicit processing diagnostic:

Manifest successfully inspected, declaration absent or unrecognized: supports a genuine DPI declaration finding.
Executable could not be processed, opened, or parsed: establishes analyzer failure, but does not establish that the declaration is missing.
Only the final “not DPI aware” classification appears: insufficient to distinguish those cases retrospectively.

Search the XML for the executable name, TEST92, DPIAwarenessValidation, manifest, process, access, and HRESULT or Win32 error values. Preserve the complete report directory rather than only screenshots.

Your existing results support two narrower conclusions:

GetProcessDpiAwareness == 2 confirms per-monitor awareness, but that enumeration has no separate PerMonitorV2 value; therefore it cannot independently prove V2.^2^
CreateActCtx returning access denied in one package context—while ordinary reads and an identical copied file succeed—shows that activation-context processing is context-sensitive in that experiment. Because the original WACK process was not traced, it does not prove that WACK encountered the same denial.

Retain independent evidence that the installed executable itself contains the declaration, including:

The installed package full name, version, architecture, and executable path.
A manifest extraction from that exact installed binary, not the build-tree copy.
The extracted dpiAwareness element and its namespace.
The binary hash, correlated with the packaged payload.
Runtime DPI-context observations.

For supported Windows versions, dpiAwareness overrides dpiAware, and PerMonitorV2 is recognized beginning with Windows 10 version 1703. Microsoft recommends embedding the application manifest in the executable; a sidecar manifest should conventionally match the executable name.^3^

If API-based evidence is needed, use a DPI-awareness-context API rather than relying only on the legacy three-value process enumeration. SetProcessDpiAwarenessContext can select PerMonitorV2, but it must run before DPI-dependent APIs or UI creation.^4^

TEST88: classify findings rather than treating every string as execution

TEST88 is an optional Desktop Bridge test intended to identify compatibility risks for Windows S mode. Optional results are informational and do not determine Store onboarding pass/fail.^5^

Build a review table for every reported entry:

Finding	Classification	Evidence to retain	Action
Main executable starts itself as a Python multiprocessing worker	Packaged application component	Parent/child image paths, command line, package-relative resolution, worker purpose	Document as required in-package self-spawn
Launch of an executable shipped inside the same package	Packaged component	Package inventory, hashes, runtime trace	May be treated as part of the application
Launch of `cmd`, PowerShell, script hosts, or another external executable	External dependency	Runtime trace and resolved path	Remove or redesign if reachable
Qt/OpenGL import or launch API reference	Static/conditional reference	Owning binary, symbol/import, reachability analysis	Document separately; do not claim execution
Short matching string in a dependency	Static string match	File, offset/string, dependency version	Record as an analyzer match, not process-launch evidence

Microsoft’s corrective guidance is explicit: remove calls that launch executables not part of the app; if the flagged executable is part of the application, the warning may be ignored.^5^

For Qt/OpenGL paths, state only what the evidence establishes:

the dependency contains a launch-related import, string, or conditional code path;
whether the path is reachable under your configuration;
whether runtime tracing observed a child process;
if observed, the resolved child image and whether it belongs to the package.

Do not characterize an unobserved conditional reference as an executed launch. Conversely, document the Python self-spawn explicitly because it is known required behavior.

Supported clarification path

Local WACK is deprecated and no longer maintained; it remains available only for optional pre-submission checks. Official certification runs automatically after submission to Partner Center.^6^

Submit the release MSIX with concise Notes for certification containing:

TEST92’s exact processing message;
extracted PerMonitorV2 manifest evidence from the installed binary;
binary/package hashes;
the package-context CreateActCtx comparison, clearly labelled as a separate reproduction;
the TEST88 classification table;
confirmation that Python workers resolve to the packaged executable;
runtime evidence distinguishing observed launches from static library references.

Partner Center’s certification report is the authoritative outcome. If certification fails or its report treats either finding as blocking, respond to the certification-report communication and attach the preserved evidence; Microsoft’s MSIX guidance identifies that route for clarification.^7^

References