Understanding Application Control event tags
Windows Defender Application Control (WDAC) events include many fields, which provide helpful troubleshooting information to figure out exactly what an event means. This article describes the values and meanings for a few useful event tags.
Represents the type of signature which verified the image.
|0||Unsigned or verification hasn't been attempted|
|2||Cached signature; presence of a CI EA means the file was previously verified|
|3||Cached catalog verified via Catalog Database or searching catalog directly|
|4||Uncached catalog verified via Catalog Database or searching catalog directly|
|5||Successfully verified using an EA that informs CI that catalog to try first|
|6||AppX / MSIX package catalog verified|
|7||File was verified|
Requested and Validated Signing Level
Represents the signature level at which the code was verified.
|0||Signing level hasn't yet been checked|
|1||File is unsigned or has no signature that passes the active policies|
|2||Trusted by Windows Defender Application Control policy|
|3||Developer signed code|
|5||Microsoft Store signed app PPL (Protected Process Light)|
|7||Signed by an Antimalware vendor whose product is using AMPPL|
|11||Only used for signing of the .NET NGEN compiler|
|14||Windows Trusted Computing Base signed|
Represents why verification failed, or if it succeeded.
|0||Successfully verified signature|
|1||File has an invalid hash|
|2||File contains shared writable sections|
|3||File isn't signed|
|6||File is signed using a weak hashing algorithm, which doesn't meet the minimum policy|
|7||Invalid root certificate|
|8||Signature was unable to be validated; generic error|
|9||Signing time not trusted|
|10||The file must be signed using page hashes for this scenario|
|11||Page hash mismatch|
|12||Not valid for a PPL (Protected Process Light)|
|13||Not valid for a PP (Protected Process)|
|14||The signature is missing the required ARM processor EKU|
|15||Failed WHQL check|
|16||Default policy signing level not met|
|17||Custom policy signing level not met; returned when signature doesn't validate against an SBCP-defined set of certs|
|18||Custom signing level not met; returned if signature fails to match
|19||Binary is revoked based on its file hash|
|20||SHA1 cert hash's timestamp is missing or after valid cutoff as defined by Weak Crypto Policy|
|21||Failed to pass Windows Defender Application Control policy|
|22||Not Isolated User Mode (IUM)) signed; indicates an attempt to load a non-trustlet binary into a trustlet|
|23||Invalid image hash|
|24||Flight root not allowed; indicates trying to run flight-signed code on production OS|
|25||Anti-cheat policy violation|
|26||Explicitly denied by WADC policy|
|27||The signing chain appears to be tampered/invalid|
|28||Resource page hash mismatch|
Policy activation event Options
The Application Control policy rule option values can be derived from the "Options" field in the Details section for successful policy activation events. To parse the values, first convert the hex value to binary. To derive and parse these values, follow the below workflow.
- Access Event Viewer.
- Access the Code integrity 3099 event.
- Access the details pane.
- Identify the hex code listed in the "Options" field.
- Convert the hex code to binary.
For a simple solution for converting hex to binary, follow these steps:
- Open the Calculator app.
- Select the menu icon.
- Select Programmer mode.
- Select HEX.
- Enter your hex code. For example,
- Switch to the Bit Toggling Keyboard.
This view provides the hex code in binary form, with each bit address shown separately. The bit addresses start at 0 in the bottom right. Each bit address correlates to a specific event policy-rule option. If the bit address holds a value of 1, the setting is in the policy.
Next, use the bit addresses and their values from the following table to determine the state of each policy rule-option. For example, if the bit address of 16 holds a value of 1, then the Enabled: Audit Mode (Default) option is in the policy. This setting means that the policy is in audit mode.
|Bit Address||Policy Rule Option|
Microsoft Root CAs trusted by Windows
The rule means trust anything signed by a certificate that chains to this root CA.
|Root ID||Root Name|
|3||Microsoft Authenticode(tm) Root Authority|
|4||Microsoft Product Root 1997|
|5||Microsoft Product Root 2001|
|6||Microsoft Product Root 2010|
|7||Microsoft Standard Root 2011|
|8||Microsoft Code Verification Root 2006|
|9||Microsoft Test Root 1999|
|10||Microsoft Test Root 2010|
|11||Microsoft DMD Test Root 2005|
|12||Microsoft DMDRoot 2005|
|13||Microsoft DMD Preview Root 2005|
|14||Microsoft Flight Root 2014|
|15||Microsoft Third Party Marketplace Root|
|16||Microsoft ECC Testing Root CA 2017|
|17||Microsoft ECC Development Root CA 2018|
|18||Microsoft ECC Product Root CA 2018|
|19||Microsoft ECC Devices Root CA 2017|
For well-known roots, the TBS hashes for the certificates are baked into the code for Windows Defender Application Control. For example, they don’t need to be listed as TBS hashes in the policy file.
Represents values that are used to communicate system information. They are of four types: success values, information values, warning values, and error values. See NTSATUS for information about common usage details.
Submit and view feedback for